软件风险管理安全特征问题清单IECTR80002-1

软件风险管理安全特征问题清单IECTR80002-1
RISK MANAGEMENT REPORTVersion ：
RISK MANAGEMENT REPORTVersion ：A/0
Appendix 2 List of Safety Characteristics of XXXXXX
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
1/ 7
Item
Question
Determine safety features
Potential hazard
Harm No.
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 us navigate to access SAFETY- related function?
er
B.3.4
Have all automatic screen switches been evaluated?
B.3.5
How will color blind operator interpret error message?
Item
Question
Determine safety features
Potential hazard
Harm No.
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” err exist in therapy control software and SAFETY monitor software?
or
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
Item
Question
Determine safety features
Potential hazard
Harm No.
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 m”od e 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 ”sa ved 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?
Item
Question
Determine safety features
Potential hazard
Harm No.
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 Diagnos
tic
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?
Item
Question
Determine safety features
Potential hazard
Harm No.
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 π 1easuresb een implemented to detect limits?
B.11.1.4
Can interrupts be set to segregate critical time constrained functionality from other functionality?。