Developing Medical Device Software to IEC 62304

Ken Hall

Until recently, safety regulations for medical device software, at least formally, were not exceptionally rigorous across the board. In addition, software was not formally classified as a medical product by the Medical Devices Directive. This has now changed. A new regime is in force governing all medical device software development for all classes of device.

Previous software safety standards were best suited to medical devices with low levels of risk, as opposed to products where software failure could be extremely serious and result in death. As more electronic products have become dependent on embedded software, the focus has shifted to the reliability of software systems within the devices and the associated risks at all levels of usage. As a result, the new EN/IEC 62304 standard has emerged as a global benchmark for management of the software development lifecycle.

Risk analysis for hardware and software design

Medical product designers have used risk management techniques to help reduce the risks associated with device hardware. BS/EN/ISO 14971 has traditionally been adopted as the base standard for risk management for medical devices. The 2007 version of this standard is considerably extended from its previous version, and the techniques described are now intended to be applied to both software and hardware systems.

The approach that should be taken is to consider the risks posed by the medical device as a whole, before the software/hardware split has been decided. Hardware risk analysis can then run alongside software risk analysis to define the required safety systems for the device.

A harmonised standard

IEC 62304 is a harmonised standard for software design in medical products adopted by the European Union and the United States. Because the standard is “harmonised,” medical device manufacturers adopting it will satisfy the essential requirements contained in Medical Devices Directive 93/42/EEC (MDD) with amendment M5 (2007/47/EC) as related to software development. This is the least onerous route to ensuring compliance with the MDD. US FDA will also accept ANSI/AAMI/IEC 62304:2006 as evidence that medical device software has been designed to an acceptable standard. This standard is identical to the EN/ISO variant in all essential details.

Designing to IEC 62304 ensures that quality software is produced by means of a defined and controlled process of software development. This process must contain a set of requirements based on the safety class of the software that is being developed.

Software safety classification

Initially the IEC 62304 standard expects the manufacturer to assign a safety class to the software system as a whole. This class-ification is based on the potential to create a hazard that could result in an injury to the user, the patient or other people.

The software is classified into three simple classes, as follows:

Defining “serious injury,” “nonserious injury,” “injury” and “damage to health” is important to apply this classification effectively. It may at first appear to be obvious what constitutes an injury; however, this can be a far more complex question when the context of the device is taken into account. Unfortunately the standard only defines “serious injury,” and this is as follows:

Serious Injury

Injury or illness that directly or indirectly

a) is life threatening,

b) results in permanent impairment of a body function or permanent damage to a body structure, or

c) necessitates medical or surgical intervention to prevent permanent impairment of a body function or permanent damage to a body structure.

Note: Permanent impairment means an irreversible impairment or damage to a body structure or function excluding trivial impairment or damage.

It is relatively simple to apply a negative to the above to derive a nonserious injury definition. However, the definition of injury for use with the Class A software safety classification may be debatable. This is complex because of the lack of definition of injury or damage to health. For example, there may be a grey area involving the normal side effects of treatment of a condition as opposed to the device itself causing injury.

Procedures for carrying out this initial analysis and defining the class to be applied have been developed. In some cases, the notified body being used can affect this decision. Some will recommend that Class B is the minimum standard to be applied for any medical product, as the Class A safety classification does not insist on a sufficiently rigorous software development process.

There are major differences in the development process in terms of cost and time between a Class A and Class B code. It is therefore essential that medical device developers get this right at the outset. The safety classification also has a great impact on the documentation and process that is required.

Software items and units

Once the initial safety classification has been carried out for the system, it is possible to break the system down into software items and software units. These are defined as follows:

In practice, the software items can be any subsection of a system or its constituent parts. An architectural diagram is required to show the software items and software units. It is possible to then downgrade the safety classification of parts of the software system provided that these can be segregated. The note on section 5.3.5 of the standard gives an example of this segregation:

“An example of segregation is to have software items execute on different processors. The effectiveness of the segregation can be ensured by having no shared resources between the processors.”

In practice, this means that a safety-critical software system can be split into items, each one running on different processors and each with a different safety classification. Again, it is important to get this split correct at the outset to ensure that the system is safe and high quality, but also produced within the appropriate cost and time guidelines. Systems are available to analyse medical product software architecture and to define these items. Such processes can greatly reduce timescales and costs for the development of medical devices.
 

Impact of safety classification

The safety classification has a tremendous impact on the code development process. It is therefore in the interests of medical device manufacturers to get this right the first time to avoid expensive, time-consuming rework late in a project.

A brief summary of the effects of safety classification on the documentation and process is shown in table I. In practice any company developing medical device software will carry out verification, integration and system testing on all software classes. However, the difference is that formal detailed documentation does not need to be generated for Class A code. Cross-referencing and verification of requirements also does not need to be formally proven. This can save a great deal of time and money in software development.

SOUP

Software of unknown provenance, or SOUP, is any code (tools or source code) that does not have formal documentation or was developed by a third party and has no evidence as to the controls on the development process. This code by definition is deemed to be capable of producing faults. It is important to carry out a software risk analysis on any SOUP code being proposed for the software under development and produce a rationale as to why this code should be used.

The use of SOUP is affected by the code safety classification. If the code is deemed to be Class A, then SOUP code can be used without further justification. As the class increases, the risks increase and the rationale becomes harder to justify. In practice this means that only simple function, well known and diversely applied SOUP code can be used for Class C applications.

A technology solutions provider specialising in electronics design and production services has developed processes to identify and justify the use of SOUP in medical device software. Its own experience with this has proved that such processes can drastically reduce development time-scales and costs. This is a route that medical device developers should incorporate into their design procedures.

Conclusion

IEC 62304 is a well considered, logical standard for developing safety critical and high reliability software for medical devices. Now that this standard has been adopted it would be very difficult for a medical device software developer to justify any equivalent approach that meets the requirements of the MDD, without effectively complying with this standard. This is good news for the safety of patients, but also for the manufacturers themselves, as the standard establishes a more level playing field. There is no longer any opportunity for uncontrolled rudimentary software development processes, and this raises quality across the board.

In addition, as IEC 62304 is a harmonised standard that has been adopted internationally, it tends to equalise quality expectations between Europe and the United States.

For medical device manufacturers, it is important that they select software designers who have well-established risk management systems, as they will already have the foundations in place to meet IEC 62304. Additionally, my professional experience has proved how valuable processes can be to analyse medical product software architecture and usage. Such processes can greatly reduce timescales and costs for the development of medical devices. 

Ken Hall is Technical Director at Triteq Ltd.