The list is based on the list of questions in Appendix B of the IEC TR 80002-1-2009. The intended use and safety-related characteristics of the medical device are judged. The safety characteristics of the product are known. Further risk analysis lays the foundation.
| Item | Question | Determine safety features | Potential hazard | Harm No. | |
| The following questions are based on Appendix B of the IEC TR 80002-1-2009 | |||||
| B.1 Alarms and alerts: | |||||
| B1.1 | Do specifications identify howthe SYSTEM reacts to multiplealarm conditions? | ||||
| B1.1.1 | Are there multiple levels of alarms? Do higher level alarms override the audio for lower level alarms? | ||||
| B1.1.2 | Should any of the alarms persist until the user can acknowledge the alarm? | ||||
| B.1.2 | Does the protective action create a usability problem, i.e. can the user safely navigate from the protective action? | ||||
| B.1.3 | Is safe mode action appropriate for INTENDED USE? Has the clinical staff reviewed safe mode scenarios? Is safe mode state apparent to the user？ | ||||
| B.1.4 | Has the clinical staff reviewed protective measures for usability? | ||||
| B.1.5 | Are detected errors logged? Is log large enough? Is log storage reliable? How is log cleared? | ||||
| B.1.6 | Has INTENDED USE environment been considered for audible alarm design? | ||||
| B.1.6.1 | Have users been involved in developing requirements for user interface design? | ||||
| B.1.6.2 | How is audio SYSTEM verified per power up or per patient? | ||||
| B.2 Critical power cycle states | |||||
| B.2.1 | What happens to a memory write that was in progress when power was lost? | ||||
| B.2.1.1 | Is the software made aware of impending power loss? | ||||
| B.2.1.2 | Is non-volatile storage verified on power up? | ||||
| B.2.1.3 | Are critical parameters checked before use? | ||||
| B.2.2 | Is reset being used as a RISK CONTROL measure? | ||||
| B.2.2.1 | Will input/output control be compromised during reset cycle? | ||||
| B.2.2.2 | Is user made aware of resets? | ||||
| B.2.3 | Is recovery time a SAFETY issue? | ||||
| B.2.3.1 | Is availability of the MEDICAL DEV ICE a SAFETY issue? | ||||
| B.2.3.2 | How is non-volatile storage impacted by failsafe protective measure? | ||||
| B.2.4 | Are any RISK CONTROL measures compromised during low power modes? | ||||
| B.2.4 | Has software recovery from low power modes been considered as a possible start-up state for VERIFICATION andvalidation activities? | ||||
| B.3 Critical user controls/Usability | |||||
| B.3.1 | Is user notified if adjustment is made to a new value but never selected or confirmed？ | ||||
| B.3.1.1 | Should the parameter being adjusted require a two-step operation for change? | ||||
| B.3.2 | Should user be prompted for confirmation? | ||||
| B.3.2.1 | Does software check data entry for validity? | ||||
| B.3.2.2 | Does it require supervisory user login to confirm highly critical inputs or error overrides? | ||||
| B.3.3 | How many “layers” must user navigate to access SAFETY- related function? | ||||
| B.3.4 | Have all automatic screen switches been evaluated? | ||||
| B.3.5 | How will color blind operator interpret error message? | ||||
| B.3.5.1 | Have users been involved in developing requirements for user interface design? | ||||
| B.4 Display | |||||
| B.4.1 | Is there a technique being used to ensure correct orientation of image? | ||||
| B.4.1.1 | How are images associated with patient? | ||||
| B.4.2 | What frequency content is required for display? | ||||
| B.4.2.1 | Has the clinical staff reviewed that requirement? | ||||
| B.4.2.2 | Has display filter been fullycharacterized, i.e. what is rejected and what is passed, over full range of inputs? | ||||
| B.5 Hardware controls | |||||
| B.5.1 | What is the sampling rate? | ||||
| B.5.1.1 | If PID control, is integral gain limited? Has algorithm been characterized over the full variation of manufactured hardware? | ||||
| B.5.1.2 | If feedback control, what checks are made to the validity of the feedback signal? | ||||
| B.5.1.3 | Have all data types been evaluated for the microprocessor and compiler in use? | ||||
| B.5.2 | Are all assertions continuously verified on a scheduled basis? | ||||
| B.5.2.1 | Could a “common mode” error exist in therapy control software and SAFETY monitor software? | ||||
| B.5.2.2 | Are SAFETY monitors verified per power up or per patient? | ||||
| B.5.3 | Does software detect that bit is stuck (never changes)? | ||||
| B.5.3.1 | Has polling rate been discussed with SYSTEM or hardware engineer? | ||||
| B.5.4 | Does software perform a reasonableness or validity check ofcalibration values i.e. slope or offset? | ||||
| B.5.4.1 | Is user aware of auto-cal or auto- zero? | ||||
| B.5.5 | Are all hardware faults reported to user? | ||||
| B.5.5.1 | Should hardware fault be checked at power-up, before each treatment or session or on a continuous basis such as once per second? | ||||
| B.5.6 | Does software enforce completion of cycle? | ||||
| B.5.7 | Can software detection of incomplete cleaning or disinfection cycle be defeated? | ||||
| B.5.8 | Are all assertions continuously verified on a scheduled basis? | ||||
| B.5.8.1 | Can SAFETY SYSTEMS be defeated, i.e. pump operated without tube in SAFETY clamp? | ||||
| B.5.9 | Have SAFE STATES been defined and analyzed thoroughly including impact of delay of treatment and safe shutdown sequences for the range of target populations (e.g. adults, neonates)? | ||||
| B.5.9.1 | Can software support a "limited functionality” mode and inform user of situation? | ||||
| B.6 Monitoring | |||||
| B.6.1 | Has therapy control and therapy monitor software been developed independently? | ||||
| B.6.1.1 | Has software design eliminated or minimized possibility for racecondition for this decision point? | ||||
| B.6.2 | Is control subsystem aware of monitor subsystem actions？ | ||||
| B.6.2.1 | How are deactivated parameters communicated to user or networked SYSTEMS? | ||||
| B.6.3 | How is the user made aware of“frozen” display? | ||||
| B.6.3.1 | Is video “context” saved before pre- emption? | ||||
| B.6.4 | Is sampling rate appropriate for frequency content of signal? | ||||
| B.6.4.1 | Is the measurement value stored in consistent units throughout software layers? | ||||
| B.7 Interfaces | |||||
| B.7.1 | Does each software function verify passed parameters? | ||||
| B.7.1.1 | Does software language support more robust type checking? | ||||
| B.7.1.2 | Is software designed with consistent units for values throughout the software package? | ||||
| B.7.1.3 | Are arguments modified at higher priority processing layer? | ||||
| B.7.2 | Has software been designed to tolerate any physical network connection condition? | ||||
| B.7.2.1 | Can remote connection degrade SYSTEM performance by repeatedly sending commands Or bogus data? | ||||
| B.7.2.2 | Does the MEDICA L DEVICE check that the network name is not already in use？ | ||||
| B.8 Data | |||||
| B.8.1 | Can there be display of multiple independent identifiers to put the user in the loop of detecting mix-ups? | ||||
| B.8.1.1 | Can critical identifiers be embedded with actual data as a cross-check? | ||||
| B.8.2 | What reports will be used for clinical purposes? | ||||
| B.8.2.1 | What is the SEVERITY of HARM if the data is incorrect? How likely is it that a clinician would notice the problem? | ||||
| B.8.3 | How can data corruption be detected prior to use of the data? | ||||
| B.8.3.1 | Can this be done with each use instead of only at start-up? | ||||
| B.9 Diagnostic | |||||
| B.9.1 | Has the alarm indication hierarchy been thoroughly reviewed and also reviewed with clinical staff? | ||||
| B.9.1.1 | What arithmetic precision is required? | ||||
| B.9.1.2 | How should mathematical formulas be coded to ensure adequate precision? | ||||
| B.9.2 | Are application PROCESSES locked out during diagnostics at appropriate times? | ||||
| B.9.2.1 | Are diagnostics locked out during critical timed cycles? | ||||
| B.10 SECURITY | |||||
| B.10.1 | What data is critical and should not be modifiable by the user or shouldrequire supervisory authorization to do so? | ||||
| B.10.1.1 | Is an audit trail needed? | ||||
| B.10.2 | Should operators be required to login before operation? | ||||
| B.10.2.1 | Can patients inadvertently operate the MEDICAL DEV ICE? | ||||
| B.10.3 | What should be allowed remotely? | ||||
| B.10.3.1 | Should assumed controls at theremote SYSTEMS be relied on and if so why? | ||||
| B.11 Performance | |||||
| B.11.1 | During peak load or when capacitylimits are reached will data or timing be lost or affected in undetectable ways? | ||||
| B.11.1.1 | Will inputs and outputs be queued up in a correct deterministic sequence under peak loads? | ||||
| B.11.1.2 | Have critical functionality and RISK CONTROL measures been tested under these stress conditions? | ||||
| B.11.1.3 | Have RISK CONTROL π1easures been implemented to detect limits? | ||||
| B.11.1.4 | Can interrupts be set to segregate critical time constrained functionality from other functionality? | ||||
