Page 152 - Safety Risk Management for Medical Devices

Software Risk Management 131

Table B.1 of IEC TR80002-1 [26] offers examples of Causes of software faults
that could introduce Hazards. The Causes are grouped by functional areas and guiding
questions are provided to help the analyst uncover missing or inadequate safety
requirements. Table B.2 of Ref. [26] identifies examples of software failure Causes
that can have broad impact on the System operation. Examples: divide by zero or
errant pointers. With these kinds of errors, failures that originate in nonsafety-critical
software items can impact safety-critical software items. Table B.2 [26] offers sugges-
tions for verification methods to trap such failure Causes. For these types of software
failures, requirements-based testing is not very effective.
An analytical tool that can be used to identify software-related Hazards is the
Software Failure Modes and Effects Analysis (SFMEA). Section 15.2 describes the
usage of this tool.
Estimating the risk of a Hazard involves estimating the likelihood of occurrence of
the Hazard. In the case of software-caused Hazards, there is no consensus on a
method to estimate the probability of occurrence of software failures. The Standard
[9] advocates for the identification of Hazards that could potentially be caused by
software, and implementing Risk Control measures, instead of trying to estimate the
risk of software failures.
To get some sense of the relative risks from software-caused Hazards, the Standard
[9] suggests relying on the severity of Harms alone. However, IEC 62304 [9]
acknowledges that it may be possible to quantitatively estimate the probability of
occurrence of software failures for legacy software, based on the usage of legacy
software and examination of postproduction data.
Medical device software could be classified into two categories: new software or
legacy software. Legacy software is software that has been in use in the field and for
which postproduction history data may be available. New software is software that has
not been released for use in the field yet and has no postproduction history. This
creates two distinct pathways for software risk management:

Case 1. where the probability of software failure can be estimated—legacy software
Case 2. where the probability of software failure cannot be estimated—new soft-
ware, or legacy software for which postproduction data is unavailable, or
is of questionable quality

In Case 1, software risk management process is very similar to hardware risk man-
agement. In Case 2, however, the process for software risk management is different
because without knowledge of the probability of occurrence of software failure, it is
not possible to estimate the risk of a software-induced Hazard. In such cases, the
Standard [3,7] recommends to assume P(software failure) 5 1 and instead focus on the
rigors of design and development process, and implementation of Risk Controls.