Page 165 - Safety Risk Management for Medical Devices

144 Safety Risk Management for Medical Devices

Table 15.7 (Continued)
IEC 62304:2006 Additional software-related documentation entries to the Safety class
Reference risk management file
6.2.1.2, 9.2 Post-production monitoring of complaints, feedback, and A, B, C
documentation of the outcome of any investigation and
evaluation.
7.1.4, 7.2.1 Potential causes of the software contribution to hazardous B, C
situations, and the relevant risk controls
7.3.3 Traceability from each hazardous situation to software B, C
item to software cause to risk control measure to
verification of the risk control measure
8.1.2 If SOUP items are used, document the SOUP title, name A, B, C
of manufacturer and unique SOUP identifier
8.1.3 The configuration items and their version that comprise A, B, C
the software system configuration
9.5 Records of problem reports and their resolution including A, B, C
their verification
Risk Controls for direct software-caused Hazards would fall into one of the above
three categories. Next are examples for each of the above three Risk Control:

1. Inherent safety by design: limiting software authority by hardware; e.g., physical
limit to the maximum torque that a motor could deliver would mean that even
if the software failed and gave a command for too much torque, it would be
physically impossible for the motor to deliver that much torque.
2. Protective measure: algorithmic validity checking of inputs, password checks
3. Information for safety: warning messages, alarms

For indirect software-caused Hazards, certain unique Risk Controls apply. These
are general strategies in software development such as pointer initialization, use of
checksums on critical data, and avoidance of dynamic memory allocation. See
Section 15.10 for many more tips for developing safety-critical software.
It is not practical to try to trace every potential software-caused Hazard to an indi-
rect Cause and its mitigation. For example, a bit flip could have unpredictable effects
anywhere in the software. Multiple software-caused Hazards could have the same
indirect cause and the same Risk Control. The better strategy is to have a general
Risk Control for the indirect Causes that applies throughout the software system, e.g.,
a periodic CRC check of the code space to detect any bit flips.

15.7 LEGACY SOFTWARE

Legacy software is defined as “medical device software which was legally placed on
the market and is still marketed today, but for which there is insufficient objective