Page 150 - Safety Risk Management for Medical Devices

Software Risk Management 129

The analysis of software at the software architectural level enables us to plan
architectural-level Risk Controls, such as introducing protective Risk Control measures
that are external to the software. Beyond introduction of architectural Risk Control
measures, applying the methods that are prescribed in IEC 62304 [9] provides process-
based Risk Control measures that can reduce the probability of software failures.
IEC 62304 [9] B.7 says “Software risk management is a part of the overall medical
device risk management and cannot be adequately addressed in isolation.” Since soft-
ware is not a Hazard by itself, it doesn’t have risk. Risks of software failures can only
be estimated in the context of the System. Software risk in a System is the aggregation of
the risks of all the Hazards that are caused by software failures.
Software safety must be approached within a multidisciplinary context including:
System design, software engineering, mechanical and electrical design, and usability
engineering.
Before delving deeper into software risk management, certain key terms need to
be defined.

Software Defect: An error in design/implementation of the software.
Software Fault: A software condition that causes the software not to perform as
intended.
Software Failure: A software condition that causes the System not to perform
according to its specification (System here means the medical device).

The following clarifications should facilitate a deeper understanding of the above terms:
• A software defect does not necessarily cause a software fault
• A software fault does not necessarily cause a software failure
• A software failure does not necessarily create a System Hazard
• Software could fault in the absence of software defects (e.g., due to bad soft-
ware requirements)
• Software could fail in the absence of software faults (e.g., due to bad System
requirements)

Software defects are systemic, not random in nature. Software testing can catch a
proportion of software defects. But software of even moderate complexity cannot be
completely tested. Therefore we have to accept the fact that some software defects
will probably remain in the software.
Fig. 15.2 shows the chain of software events that could lead into a System Hazard.
The dotted arrows imply that there may be intervening events between software failure
and System Hazards.
In the context of software risk management, in this book we will only consider risks
due to software failures. In other words, the progression depicted by the dark arrows in