Software Hazard Identification

Custom Software is critical and is an integral part of many complex medical devices. Some of these medical devices are high-risk medical devices as the failure can result in non-serious injury or serious injury or in some cases, even death for the persons using them. Because of this, the software contained in high-risk medical devices must be safe. To enforce this safety aspect, the regulatory requirements ISO 14971 and IEC 62304 that govern software development in medical devices establish the overall mechanism for risk management in the design and development of software for medical devices.

The main stages of software risk management consist of Risk Analysis, Risk evaluation, and Risk control.

Risk Analysis

Based on the Intended use and characteristics related to the safety of medical devices, identify the software hazards(potential source of harm). Based on the identified harm, estimate the risk, which is nothing but the probability of harm multiplied by the severity of harm.

Risk Evaluation

Determine the acceptability of the above-estimated risk using inputs from the cross-functional team, including doctors.

Risk Control

Implement software changes like new safety changes to mitigate and reduce the above-identified risks, particularly unacceptable risks, to make them acceptable risks.

In the above mechanism, identification of software hazards is one of the important vital steps. The software hazard can be identified using a top-down (fault tree analysis — FTA) approach, a bottom-up approach (failure modes and effects analysis — FMEA), or other methods.

Here, we will examine how the software FMEA can be performed to identify the software hazards with the Blood Glucose Meter (Medical Device) example.

A blood glucose meter usually consists of hardware interfaces like buttons, a display, a test strip port, and a microcontroller. Based on the hardware interface, the software subsystems / Modules that are required are:

• Button software subsystem: Contains functions to identify the button presses and releases and posts them to the Message software subsystem.
• Display software subsystem: Contains functions to display the glucose reading and other information to the user.
• Test strip sensor software subsystem: Contains functions to sense the presence of test strips and blood and posts them to the Message software subsystem.
• Timer software subsystem: Contains functions to provide timer indication, which can be used to time the button press duration, etc.
• Message software subsystem: Contains functions like Message_Post(), Message_Get() to manage storage and retrieval of messages like button press detected, test strip detected, blood sample detected, blood glucose results available, etc.
• Controller software subsystem: Contains functions to retrieve the pending messages from the Message software subsystem and perform required operations like determination of blood glucose and send them to the Display software subsystem.

With the above software subsystem identified now, we will look at the steps for performing software FMEA for the function Message_Post() in the Message software subsystem (Any spreadsheet tool can be used for its convenience in handling tables).

The function Message_Post()is listed in a separate row aligned with the Software subsystem name with its own unique identifier (unique identifier facilitates tracing in other places and other documents).

Then, the function Message_Post() is further analyzed to identify the Software Failure cause, Fault Result, and Potential Hazards. In this example, the Software Failure cause is determined as “Message queue full” due to the fact the message buffer is full with unprocessed messages. The resultant Software Fault Result is determined as “Fails to queue messages” due to the fact no memory is available in the message buffer for new messages. The resultant Potential Hazard is determined as “Perceived Device Lockup,” as the device will not respond to button presses or test strip insertions.

This process shall be repeated for each function in all the software subsystems, thereby facilitating a clear and simple way of identifying all the software hazards. With the identified software hazards, the next step in risk management can proceed.