Managing software risk in medical electronics

Risk management is crucial in developing safe, effective medical devices that improve and save lives. Controls can minimize the chance of harm and limit consequences.

The medical device industry relies on the guidance of several industry standards including IEC 60601-1:2020 Edition 3.2 (October 2020) and ISO 14971:2019 to move the industry closer to safer medical devices, while in Europe the advent of the EU’s new Medical Device Regulations (EU MDR) has also focused attention on best practices. A proposed update to ISO/IEC 62304 has run into difficulties, so IEC 62304:2006+AMD1:2015 remains pertinent for the time being. Ongoing development of the IEC 80001 family adds cybersecurity controls into the mix.

However, as well-intentioned as it might be, standards adherence can represent considerable overhead for developers. If the ever-increasing costs and risks associated with software complexity can be contained, best practices required by the standards must be applied as efficiently as possible. Automation is key to achieving that.

GRAPHICS: LDRA

Managing software risk

IEC 60601-1 serves as the primary standard for medical device safety and basic performance. By the standard, software modules are black-box components designed and integrated during the programmable electrical medical device (PEMS) development life cycle, leaving IEC 62304 to prescribe software development processes, activities, and tasks.

IEC 62304 requires the manufacturer to specify a safety classification in accordance with a decision tree (right), ranging from class A – the software system cannot contribute to a hazardous situation – though to class C – the software system can contribute to a hazardous situation, leading to serious harm or injury.

To achieve those classifications, IEC 62304 references the process specified in ISO 14971 to identify hazards, evaluate and control associated risks, and monitor effectiveness of the controls.

Requirements engineering

A fundamental area for process improvement and automation is requirements engineering. Solutions can trace high- and low-level requirements through the software development life cycle to artifacts associated with design, code, validation, and verification. Automated requirements engineering offers a clear opportunity to also trace hazards and risk control measures through to associated requirements.

Static analysis

Static analysis serves as a useful tool to identify and solve a particular class of software problems. For medical device software developers, static analysis can automate code review by automating source code analysis, highlighting potential flaws. It can also check for adherence to generic coding standards such as MISRA C, or a project- or corporate-specific rule set. Adherence to coding standards can improve consistency, reusability, and code quality.

Not all static analysis tools are alike, however, and many differ in their level of depth of analysis. Find tool vendors who own and control their parsing technology, and therefore the responsiveness of their product development.

Dynamic analysis

By compiling and executing part or all of the code through simulation on the host or target platform, dynamic analysis includes unit, integration, and system-level testing. Each mechanism enables execution traces to be captured, allowing code coverage to be illustrated at the source-code level and as graphical representations of control and data flow. Demonstrating the correctness, completeness, and robustness of code this way reduces the risks of medical device use.

GRAPHICS: LDRA

Assurance case development

For regulatory approval, medical device manufacturers must document quality processes and resulting development and verification artifacts to demonstrate device safety and efficacy. Regulators require manufacturers to develop a safety case, presenting a defensible argument that a device is acceptably safe to use in a particular context.

The safety case includes the argument, assumptions, and development and verification artifacts as evidence to support and defend the argument. Integrated requirements engineering and static and dynamic analysis capability – combined with automatic and traceable documentation – support safety case development. It mitigates risk by providing a mechanism to state objectives of the safety case and provide documented evidence that objectives have been met. In support of the safety case, that same mechanism supports documenting identified hazards and their mitigation.

Conclusion

Managing and mitigating risk in medical device software development is a complex challenge. With solid, well-defined processes and the latest requirements engineering and static and dynamic analysis solutions, medical device manufacturers can expedite approvals and reduce overall development and verification costs through automation and high-quality processes.

LDRA (Liverpool Data Research Associates)
https://www.ldra.com

About the author: Jim McElroy is vice president of sales and marketing at LDRA. He can be reached at jim.mcelroy@ldra-usa.com.