Anil Kumar

Notably, many of the medical device faults stem from product upgrades. An analysis of 3140 medical device recalls conducted between 1992 and 1998 by US FDA, reveals that 242 of them (7.7% of the total) are attributable to software failures. Of the software recalls, 192 (or 79% of the total) were caused by software defects introduced after software upgrades.

Reacting to an ongoing inability to manage product upgrades, US FDA recently took punitive action against Baxter Healthcare and their infusion pumps forcing a recall. On April 27, 2010 US FDA had warned users about faulty components in defibrillators manufactured by Cardiac Science Corp. Unable to remedy the problems with software patches, Cardiac Science was forced to replace 24,000 defibrillators. As a result, Cardiac Science’s shares were hit and they reported a net loss of US$18.5 million. They were eventually acquired by Opto Circuits.

These recalls have resulted in a change in focus by many medical device providers. Many companies are now changing their approach to improve their software processes as well as to adopt IEC 62304, a standard for design of medical products recently endorsed by the European Union and the United States. IEC 62304 introduces a risk-based compliance structure—Class A through C where the failure of Class C software could result in death or serious injury—that ensures that medical applications comply with the standards suitable for their risk assessment. This standard outlines requirements for each stage of the development lifecycle and defines the minimum activities and tasks to be performed to provide confidence that the software has been developed in a manner that is likely to produce highly reliable and safe software products.

IEC 62304 focuses on the software development process, defining the majority of the software development and verification activities. This process includes activities such as software development planning, requirement analysis, architectural design, software design, unit implementation and verification, software integration and integration testing, system testing and finally software release.

The IEC 62304 software risk-management process is intended to provide additional requirements for risk control for software, including software that has been identified during the risk analysis as potentially contributing to a hazardous situation, or software that is used to control medical device risk.

According to the standard, the manufacturer should identify the software items that could contribute to a hazardous situation and their potential causes. These potential causes should then be documented in the risk management file, which should contain the sequence of events that were identified that could result in a hazardous situation.

For each potential documented cause, a risk control measure must be defined and documented. IEC 62304 requires this risk control measure to then be implemented, verified and documented. Traceability must be shown between the hazardous situation, software items, software cause, risk control measures and verification of risk control measures. In this way, risk management plays a major role in software maintenance process.

Understandably, IEC 62304 begins with the software development planning of the medical device. Here, required tasks directly relate to the safety classification of the device under development. Devices capable of delivering death or serious injury in case of failure (Level C) undergo more rigorous compliance and are required to include activities over and above those required for other levels.

As you can see from the table, the device safety classification plays a major role in determining the activities to be included for software development. A Class A device requires minimal activities to accomplish the software design whereas Class C devices require all activities to be carried out.

All medical device software must undergo requirement management and traceability analysis throughout the software development lifecycle. An established verifiable requirement is essential for defining what is to be built, determining that the medical device software exhibits acceptable behaviour, and demonstrating that the completed medical device software is ready for use.

IEC 63204 demands that all software requirements be identified in such a way as this makes it possible to demonstrate traceability between the requirement and software system testing. As well, this enables developers to trace the risk control measures to the software requirements.

Why does requirements traceability matter?

Requirements traceability is widely accepted as a development best practice to ensure that all requirements are implemented and that all development artefacts can be traced back to one or more requirements.

The traditional view of software development shows each phase flowing into the next, perhaps with feedback to earlier phases, and a surrounding framework of configuration management and process. Traceability is assumed to be part of the relationships between phases; however, the mechanism by which trace links are recorded is seldom stated.

In reality, however, while each individual phase may be conducted efficiently thanks to investment in up-to-date tool technology, these tools seldom contribute automatically to any traceability between the development tiers. As a result, the links between them become increasingly poorly maintained over the duration of projects. The net result is absent or superficial cross checking between requirements and implementation and consequent inadequacies in the resulting system.

To gain true automated traceability requires a Requirements Traceability Matrix (RTM) since the RTM sits at the heart of every project and is a key deliverable within many development standards.

Project managers can view and create project requirements, and track them back to their original sources as enhancement requests. Developers can review requirements (and use cases if present) while they are designing software. Testers can get a jumpstart on testing activities by viewing project requirements directly from their test management environment. Administrators can include requirements when creating project baselines. Executives can receive “dashboard” views of projects states, gaining at-a-glance information on progress. 

The RTM provides further traceability between the software architecture and software detailed design, where the software architecture is refined into software units. The RTM helps verify that software units don’t contradict with the software architecture.IEC 62304 subclause 5.1.1 section C specifically calls for traceability to be established between system requirements, software requirements, software system test and risk-control measures implemented in software. The RTM plays a major role here by linking the various tiers of the software development life cycle. The RTM provides traceability between high- and low-level requirements to the software architecture. It also helps verify whether there is any deviation in the design from the requirement, including those related to risk control per IEC 62304 subclause 5.3.6.

Coding starts during the unit implementation where each software unit is implemented according to the design requirement. The RTM traces the units implemented with the software units along with the various static verification activities carried out during code verification and it also maps the verification plan with the dynamic analysis (done on either host or target system) carried out during unit testing, integration and system testing.

Using the RTM, project managers can estimate the impact of requirement changes (impact analysis) and how it affects the system. We can see from the diagram that, when RTM becomes the centre of the development process, it impacts on all stages of design from high-level requirements through to target-based deployment.

Integrating requirements management with other tools saves time and avoids rework. Requirements are integrated with defect tracking, visual development and testing tools to jumpstart activities and provide each role on the team with a direct window into end user needs.

IEC 62304 and Maintainability

The responsibility of the manufacturer doesn’t end with the release of the software product. IEC 62304 includes a focus on product maintenance as well.

Since many incidents in the medical device industry are related to service or maintenance of medical device systems including inappropriate software updates and upgrades, the software maintenance process is considered to be as important as the software development process. The IEC 62304 standard hopes to curb the high percentage of medical device software defects introduced after product release (i.e., during software maintenance).

A healthy software maintenance process is very similar to a solid software development process, with the addition of problem and modification analysis and modification implementation activities. The maintenance process requires that the manufacturer monitor the feedback of the released product from both within the organisation and from the user. This feedback must be documented and analysed to determine whether a problem exists. When a problem is found, a problem report should be created.

According to IEC 62304 risk-management guidelines, problem reports are evaluated to determine how the issue affects the safety of the released product and to decide whether any upgrade or patch is required. The manufacturer also must verify that the upgrade or patch does not cause a hazard or create a risk in the software that didn’t have any.

A good RTM with automated requirement traceability enables a manufacturer to adopt the existing software development process to implement modifications. A thorough regression analysis ensures that modifications have not introduces any new hazard and adversely affected the risk control measure built into the existing device.

As part of the medical device, the software maintenance process needs to ensure that, the safety-related problem reports are addressed and reported to appropriate regulatory authority and affected users. The software products should be re-validated and re-released after modification with formal controls that ensures the rectification of the problem and the avoidance of further problems.

As per IEC 62304, risk management is an integral part of the entire software development lifecycle for medical device. Because of the endemic problems with software updates directly contributing to safety risk, most of the process and activities involved in the standard speak about the risk management, right from software development planning, requirement management, architectural design, coding and verification through maintenance.

This standard requires the use of risk management process that is compliant with ISO 14971. Risk management as defined in ISO 14971 deals specifically with a framework for effective management of the risk associated with the use of medical devices.

Conclusion:
The advent of IEC 62304 brings companies involved in systems and software development for the medical industry into the same process as their counterparts in industries such as aerospace and rail. All now face the efforts required to achieve compliance with a demanding standard.

The need for such compliance has mandated business evolution in which processes and project plans are documented, requirements captured, implementation and verification carried out with respect to the requirements, and all artefacts fully controlled in a configuration management system.

Adopting IEC 62304 as a process for medical device software development requires conformance to the processes, activities and tasks defined by the standard. The device safety classification assigned by the manufacturer plays a major role in determining the effort required to develop the software. Fundamentally, IEC 62304 demands that requirement traceability be met at all stages of the software development process, with traceability to risk control measures as well.

Qualified, well-integrated tools ensure that developers can automate the process more easily and efficiently. While this involves upfront costs and potential change of current practises, compliance to IEC 62304 produces higher quality. A safe product avoids expensive recalls and ensures that the same development process can underpin the maintenance and upgrade process. The manufacture’s ROI comes quickly along with improved credibility and reputation.

Anil Kumar is a Technical Consultant with LDRA in India, specialising in the development, integration and certification of mission- and safety-critical systems.