Page 162 - Safety Risk Management for Medical Devices
P. 162
Software Risk Management 141
allows the identification of the safety-critical software-items, and thus strategic
application of Risk Controls to the highest risk software-items. It is also permissi-
ble to treat the software as a black box and apply the software Risk Controls to the
entire software-system. If the hardware option is chosen, then appropriate
functionality must be designed and implemented to be able to protect against the
software failure.
After implementation of the external Risk Controls, the effectiveness of the Risk
Controls is evaluated to judge the software contribution to overall device risk. If the soft-
ware is still capable of producing unacceptable levels of risk, then the software develop-
ment process should follow the different levels of rigor that are defined in IEC 62304 [9].
The software safety classification(s) and their rationale must be documented in the
Risk Management File (RMF).
Risk Controls serve to prevent or reduce the probability of the occurrence
of software-induced Hazardous Situations, or to reduce the severity of the
ensuing Harms.
The Standard [9] clarifies that in addition to external hardware and independent soft-
ware means, the external Risk Control could be a healthcare procedure, or even other
means that can help reduce the contribution of software to the creation of Hazards.
15.4 THE BXM METHOD FOR SOFTWARE RISK ANALYSIS
In Section 15.1, two categories of software were identified: new software and legacy
software. Per IEC 62304 [9], there is no consensus on a method to estimate the prob-
ability of occurrence of software failures in new software. Ref. [9] also acknowledges
that for legacy software, it may be possible to quantitatively estimate the probability of
occurrence of software failures, based on the usage of legacy software and examination
of postproduction data. This creates two distinct pathways for software risk
management:
Case 1. where the probability of software failure can be estimated—e.g., for leg-
acy software.
Case 2. where the probability of software failure cannot be estimated—e.g., for
new software, or legacy software for which postproduction data is
unavailable, or is of questionable quality.
In this section, the BXM method for software risk analysis for each case is laid out.
15.4.1 Case 1—Legacy software
If postproduction data of adequate quality exists where the manufacturer can derive
the probability of occurrence of software failures, then the estimation of risk due to
software failures is possible and is similar to hardware risk analysis. That is, after the