FDA’s introduction to its rules for medical device regulation states: “Medical devices are classified into Class I, II, and III. Regulatory control increases from Class I to Class III. The device classification regulation defines the regulatory requirements for a general device type. Most Class I devices are exempt from Premarket Notification 510(k); most Class II devices require Premarket Notification 510(k); and most Class III devices require Premarket Approval.”1

Given that such a definition encompasses a large majority of medical products other than drugs, it is small wonder that medical device software now permeates a huge range of diagnostic and delivery systems. The reliability of the embedded software used in these devices and the risk associated with it has become a vital concern.

In response to that, the functional safety standard IEC 62304, “Medical device software – Software life cycle processes,” has emerged as an internationally recognized mechanism for the demonstration of compliance with the relevant local legal requirements. In practice, for all but the most trivial applications, compliance with IEC 62304 can only be demonstrated efficiently with a comprehensive suite of automated tools.2,3

Fig. 1 Overview of software development processes and activities.

Part 1 of this article examines the development of detailed requirements and associated design of medical devices specified by IEC 62304, culminating in a detailed software design in accordance with clause 5.4 of the standard and shown in context in Figure 1.

Released in 2006, the IEC 62304 standard provides a framework of software development life cycle processes with activities and tasks necessary for the safe design and maintenance of medical device software. The processes, activities, and tasks described in clause 5 establish a common framework for medical device software life cycle processes that can be understood and shared within and between teams working on a project (see Figure 1).

IEC 62304 applies to the development and maintenance of medical device software when:

  • Software is itself a medical device.

  • Software is used as a component, part, or accessory of a medical device.

  • Software is used in the production of a medical device.

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

There are three software safety classifications, as follows:

  • Class A: No injury or damage to health is possible.

  • Class B: Nonserious injury is possible.

  • Class C: Death or serious injury is possible.

Table 1. Summary of which software safety classes are assigned to each requirement, highlighting clause 5.4.2 as an example.

The classification assigned to a project has a tremendous impact on the code development process from planning, developing, testing, and verification through to release and beyond. It is therefore in the interest of medical device manufacturers to get it right the first time and avoid expensive and time-consuming rework.

In practice, any company developing medical device software will carry out verification, integration, and system testing on all software regardless of the safety classification, but the depth to which each of those activities is performed varies considerably. Table 1 is based on table A1 of the standard and gives an overview of what is involved.

For example, subclass 5.4.2 of the standard states that “The MANUFACTURER shall develop and document a detailed design for each SOFTWARE UNIT of the SOFTWARE ITEM.” Reference to the table shows that it applies only to Class C code and that it is not required for classes B and C.

IEC 62304 is essentially an amalgam of existing best practices in medical device software engineering, and the functional safety principles recommended by the more generic functional safety standard IEC 61508, which has been used as a basis for industry specific interpretations in a host of sectors as diverse as the rail industry, the process industries, and earth moving equipment manufacture.4

A process-wide, proven tool suite such as the LDRA tool suite, has been shown to help ensure compliance to such software safety standards (in addition to security standards) by automating both the analysis of the code from a software quality perspective as well as the required validation and verification work. Equally important, the tool suite enables life cycle transparency and traceability into and throughout the development and verification activities, facilitating audits from both internal and external entities. It is therefore a logical choice for working in accordance with IEC 62304.

Fig. 2 Mapping the capabilities of a comprehensive tool suite to the guidelines of IEC 62304 with the LDRA tool suite.

The V diagram in Figure 2 illustrates how the LDRA tool suite can help through the software development process described by IEC 62304. The tools also provide critical assistance through the software maintenance process (clause 6) and the risk management process (clause 7). Clause 5 of IEC 62304 details the software development process through eight stages ending in release. Notice that the elements of Clause 5 map to those in Figure 1 and Table 1.

5.1 Software Development Planning

Following the steps listed in Table 1 — and the V diagram in Figure 2 — the first objective is to plan the tasks needed for development of the software in order to reduce risks as well as to communicate procedures and goals to members of the development team. This helps ensure that system quality requirements for the medical device software are understood and met by all team members and can be verified within the project.

Development planning applies to all classes of devices. It involves the creation of the plan with reference to the system design and the definition of system requirements, and the selection and definition of the development standards, methods, and tools to be used. There should be a defined procedure for integration and integration testing. A format for documentation should be specified along with plans for configuration management and verification.