Managing Software Risk in Medical Electronics

To mitigate or reduce risk, device manufacturers need to put controls in place to minimize the probability of the occurrence of harm and also limit its consequences. This sounds simple. In reality, the effectiveness of controlling risk is also a function of cost, which device manufacturers must consider in their efforts to successfully compete in the market.

With the 3rd edition of IEC 60601-1 now in enforcement in Europe and soon to be in the United States and Canada, there is significant momentum and progress toward improving the overall safety and effectiveness of medical devices. However, for those device manufacturers new to the standard or those that are developing devices certified to the second edition, there are significant changes in place that require dramatically more time and energy for certification.

In the large part, risk management now plays a major role in the overall process for ensuring medical device safety. The scope of IEC 60601-1 risk management is large; in fact, more than 10% of the requirements under this new edition pertain to risk management alone. And risk management is specifically called out in IEC 62304, which specifies the life cycle requirements for the development of medical device software. The medical device industry is relying on the guidance of a collection of industry standards, some of which are specific to medical device development and manufacturing and some that are even more specific to the type of device and its intended use.

Software is a Primary Contributor to Risk

There is no question that medical devices are becoming more complex. The industry and regulatory authorities are driving the requirements for devices to provide more connectivity and mobility, operate at lower power, and ensure increased safety and security. All these pressures, functional requirements, regulatory requirements, and time-to-market windows are forcing device manufacturers to find new ways of developing safe and effective systems faster and at lower cost. Software gives device manufacturers flexibility in adapting to new functional requirements and new hardware platforms. At the same time, however, more complexity in software applications increases risk. As a result, cost-effective development, verification, and risk management of software is essential. Ultimately, device manufacturers that are deploying best practices look to more efficient processes and automation to help mitigate risk and reduce costs.

Standards for Managing Software Risk

For the medical device industry, there are numerous standards now in play that guide the product development cycle. Of course, IEC 60601-1 serves as the primary standard to achieve medical device safety and basic performance. Related to and working in conjunction with this standard, the internationally recognized IEC 62304 standard prescribes the software development processes, activities, and tasks for effective medical device software development. IEC 62304 specifically calls out that the manufacturer shall apply a risk management process complying with ISO 14971. Both IEC 60601-1 and IEC 62304 specify the use of ISO 14971. Under IEC 62304, the manufacturer must specify a safety classification to each software system according to the possible effects on the patient, operator, or others resulting from a hazard to which the software system can contribute.

At the next level of detail, ISO 14971 specifies a process to:

Requirements Engineering

Requirments engineering is one of the fundamental areas for process improvement and automation . Today, there are products available that not only help elicit high- and low-level requirements but trace those requirements throughout the software development life cycle down into the design, code, and verification procedures and artifacts. With respect to IEC 60601-1 and IEC 62304, requirements engineering offers a clear opportunity to identify and document hazards and trace those hazards back to requirements and into the software development and verification process and the resulting artifacts. Similarly, risk control measures can be easily traced into the software design, implementation, and verification process. Requirements engineering, when linked to other activities in the software lifecycle, can reduce risk and save money by automating the process of determining the effects of changes to requirements, code, test cases, and procedures.

Static Analysis

Static analysis, although not a panacea, is widely recognized by device manufacturers and the regulatory authorities as a useful tool for identifying and solving a particular class of software problems. Static analysis checks the syntactic quality of high-level source code and can be used to predict run-time or dynamic behavior without having to execute code. For medical device software developers, static analysis can automate the code-review process by automating the analysis of source code and highlighting potential flaws. This enables inspection early and often, which can save tremendous time, energy, and money associated with the equivalent manual process. In addition, static analysis can be used to ensure that the development team adheres to either a specific industry standard such as MISRA-C:2004 or a corporate standard by quickly analyzing the code for discrepancies between the standard and the code as written. This improves consistency, reusability, and code quality.

However, not all static analysis tools are alike. Many differ in their level of depth of analysis. Some of the lighter-weight tools are capable of quickly skimming large code bases for the “easy to find” problems, whereas others are more rigorous and perform in-depth analysis for more difficult boundary conditions. The recommendation here is to be careful of tool vendors who claim to use common commercial parsing technology. This likely causes the vendor to lose development control and constrains product advancement. If the parser is not sufficient, what choice do they have to move their overall technology forward to address developers’ specific need?

Dynamic Analysis

Dynamic analysis uses compilation and execution to perform analysis on the executable code, either on the host platform in a simulated environment or down on the target platform when it is available. Dynamic analysis enables execution traces to be captured and presented back at the source code levels as well as at higher levels of abstraction, such as control and dataflow graphics where it is easy to understand the behavior of the application at a higher level. When combined with static analysis, dynamic analysis can be used for unit, integration, and system-level testing with execution tracing. Test harnesses, procedure/function stubs, and regression suites can be automatically generated and executed. Combined with the trace history, it is very easy to understand the effectiveness of the generated test cases. With strong static and dynamic analysis, it is possible to analyze the code and automatically generate and execute a high-quality test environment that produces comprehensive code coverage analysis. This ultimately reduces risk associated with the use of the medical device itself.

Assurance Case Development

To gain regulatory approval, medical device manufacturers must document their quality process and the resulting development and verification artifacts to help support the argument that their device is safe and effective. This is particularly true in those areas under scrutiny, such as the infusion pump industry. Regulatory authorities such as FDA are encouraging manufacturers to develop and produce an assurance case – or, more specifically, a safety case – which presents a defensible argument that a device is acceptably safe to use in a particular context. The safety case presents the argument, any assumptions, and the 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 – supports safety case development. It also mitigates risk with the ability to clearly state the objectives of the safety case, document the evidence where the objectives have been met, support the argument linking the evidence to the objectives, and document any assumptions, justifications, and the context. Furthermore, this integrated solution, as part of the argument for the safety case, enables the documentation of the identified hazards and the tracing of those hazards into the engineering control measures to show how the risks have been mitigated.

Managing and mitigating risk in medical device software development is no question a complex problem, and new requirements in the 3rd edition of IEC 60601-1 make this more important than ever. With solid, well-defined processes and the latest in requirements engineering and static and dynamic analysis solutions, medical device manufacturers can expedite their approval process as well as reduce their overall development and verification costs through automation and high-quality processes.

Jim McElroy is vice president of marketing at LDRA Technology andis focused on expanding LDRA business in the embedded software verification market by improving developer productivity and software quality in critical application development. Before joining LDRA, McElroy held executive-level marketing and business development positions with Green Hills Software, Telelogic North America, and I-Logix as well as holding industry-level software development positions at Lockheed Martin and Raytheon. McElroy has a MS in computer science from Fitchburg State College and a BS in computer science from the University of Massachusetts.