IEC 62304: Medical Device Software LifeCycle Processes

Summary illustration of IEC 62304

When manufacturers build software that either functions as a medical device (SaMD) or that is to be incorporated into a medical device (SiMD), the stakes are high and therefore clear and high standards are needed. IEC 62304 is the international standard for medical device software development and other medical device software life cycle processes. Every caution is needed to ensure the safety of patients and the efficacy of medical device software used in patient care. IEC 62304 is one of the standards that provides guard rails that enhance the quality of medical device software reaching patients.

The Underlying Principles: The underlying principles of IEC 62304 are rigorous planning, thorough documentation, testing and verification of everything, and finally, traceability — a transparent mechanism to verify compliance of all parts of the standard.

What is Medical Device Software?: IEC 62304 defines Medical Device Software as “software system that has been developed for the purpose of being incorporated into the medical device being developed of that is intended for use as a medical device.” This definition includes the familiar terms, Software as a Medical Device (SaMD), as well as Software in a Medical device. Of note, it does not appear to explicitly include software that is used in the manufacture of a medical device. Nonetheless, these principles could be applied and would be useful in such a setting as well.

Historical Pedigree

IEC 62304 was published by the International Electrotechnical Commission (IEC) in 2006, and was amended in 2015 to apply a risk-based approach to the safety classification of medical device software and to provide clarity on how to deal with legacy software. As such, the amended version is named version 1.1 also designated as IEC 62304:2006+AMD1:2015.

Safety Classification

In IEC 62304, the process specifications are based on the the medical device software’s Safety Class: A, B, or C.

• Class A: No injury or damage to health possible
• Class B: Injury possible, but not serious
• Class C: Death or serious injury possible

A risk-based approach as illustrated in the IEC schematic below is used to determine device classification

Risk-Based Approach to Medical Device Software Safety Classification (See IEC 62304 v1.1)

The higher the Safety classification of the medical device software, the more stringent the process requirements on such a medical device software. Class C Medical Software are required to comply with all the specifications in the standard, while Class B devices are exempt from some, and Class A are exempt from even more. Table below shows which of the requirements from Clause 5 of the standard apply to the various safety classes. Clause 5 outlines the Software Development Process.

Requirement of Clause 5 (Software Development Process) items to the three Safety Classes

IEC 62304 Contents

1. Scope
2. Normative References
3. Terms and Definitions
4. General Requirements
5. Software Development Process
6. Software Maintenance Process
7. Software Risk Management Process
8. Software Configuration Management Process
9. Software Problem Resolution Process

Some Terms & Definitions from Clause 3

• 3.24: SOFTWARE DEVELOPMENT LIFE CYCLE MODEL: “Conceptual structure spanning the life of the software from definition of its requirements to its release, which: identified the process, activities, and tasks involved in development of medical device software; describes the sequence of and dependency between activities and tasks, and; identifies the milestones at which the completeness of specified deliverables is verified.”
• 3:25: SOFTWARE ITEM: “Any identifiable part of a computer program, i.e. source code, object code, control code, control data, or a collection of these items.”
• 3.27: SOFTWARE SYSTEM: “Integrated collection of software items organized to accomplish a specific function or set of functions.”
• 3.28: SOFTWARE UNIT: “Software item that is not subdivided into other items”
• 3.29: SOUP (Software of Unknown Provenance): “Software item that is already developed and generally available and that has not been developed for the purpose of being incorporated into the medical device (also known as “off-the-shelf software) or software item previously developed for which adequate records of the development processes are not available”
• 3.36: LEGACY SOFTWARE: “Medical device software which was legally placed on the market and is still marketed today but for which there is insufficient objective evidence that it was developed in compliance with the current version of this standard”

Clause 4: General Requirements

Clause 4, General requirements, specifies the need for a Quality Management System, Risk Management, Software Safety Classification, and handling of Legacy Software.

Quality Management System: ISO 13485 is the international standard for quality management system for medical device manufacturers. Compliance with other national regulation for QMS are allowed. For example, in the U.S., the Food and drug Administration (FDA) currently utilizes 21 CFR 820. However, there are imminent plan to transition to ISO 13485.

Risk Management: IEC 62304 requires manufacturer to be in compliance with the standard for risk management ISO 14971:2019.

Legacy Software: IEC 62304 Sub-clause 4.4 outlines steps manufacturer must take if choosing to incorporate legacy software into the medical device. These steps include risk management activities, gap analysis, gap closure, and rationale for use of legacy software.

Clause 5: Software Development Process

Clause 5 is the core of the standard and consists of the following sub-clauses:

• 5.1: Software development planing: This sub-clause specifies the requirement for planning the activities, inputs, and outputs of the software development process. It specifies the need to include detailed plans for processes, deliverables, testing, traceability, documentation, risk management, software configuration change management, and problem resolution.
• 5.2: Software requirements analysis: This sub-clause specifies how software requirements analysis is to be conducted; including specification of software requirements from system requirements, functionality and capability requirements, interface and compatibility specifications, cybersecurity requirements, data structures requirements, installation and maintenance requirements, verification requirements, testing and acceptability criteria requirements, and updates and regression testing requirements.
• 5.3: Software architectural design: This sub-clause specifies the requirement related to software architectural design — including the need to transform software requirements into an architecture; the need to develop architecture for the interactions (interfaces or connections) between software items, software systems, and external components such as hardware accessories; the need to specify functional, capability, software, and hardware requirements of SOUP; and proper segmentation of architectural components to enable robust risk managements of components with distinct risk profiles (e.g. cybersecurity considerations, database integrity, etc).
• 5.4: Software detailed design: This sub-clause specifies that the manufacturer will subdivide the software into software units and document and verify a detailed design of each software unit and interfaces. This is to be done with sufficient detail to enable correct implementation of the medical device software.
• 5.5: Software unit implementation: This can be thought of as the software coding phase or building phase, where the prior sub-clauses were serving to establish the blueprint of what is to be coded or built. This sub-clause must include verification for the various software units and must specify verification acceptance criteria.
• 5.6: Software integration and integration testing: This part can be thought of as the gluing phase, including verification that the glue works and that the joined units are properly joined and are working well together. Importantly regression testing must be done. Furthermore amongst other things testing must be rigorously documented, repeatable, verifiable, and must assess both intended use and foreseeable misuse scenarios.
• 5.7: Software system testing: The software systems should be tested. Clear acceptance criteria must be specified. Testing must be robust and rigorously documented.
• 5.8: Software release for utilization at a system level: Specifies requirements for software release, including verification, documentation, anomaly detection, versioning, and reliable delivery.

Clause 6: Software Maintenance Process:

This clause specifies the need for a software maintenance plan and software maintenance processes. This includes details on problem reporting, feedback evaluation, problem resolution process, change request analysis and approval, communication with users and regulators, risk-management of maintenance processes, and software re-release after maintenance activities.

Clause 7: Software Risk Management Process

This clause is based on ISO 14971 risk management for medical device software. See figures below from ISO 14971:2019. See figures below. Of note, this is more recent than IEC 62304 version 1.1, which was released in 2015. Some hazards specifically named in IEC 62304 include SOUP and associated risks.

Risk Management Process: From ISO 14971

And the overall risk management process is below:

Overall Risk Management Process: From ISO 14971:2019

Clause 8: Software Configuration Management Process

This clause mandates documentation and implementation of configuration items, their change control, traceability, and verification. Including change verification, traceability, and overall configuration status accounting.

Clause 9: Software Problem Resolution Process

This clause specifies need for a process for problem resolution. It includes identification of the problem, reporting, problem investigation and analysis, resolution, change control, communication with affected parties, problem resolution, verification of problem resolution, and documentation.

AUTHOR BIO: Dr. Stephen G. Odaibo is CEO & Founder of RETINA-AI Health, Inc. He is a Physician, Retina Specialist, Mathematician, Computer Scientist, and Full Stack AI Engineer. In 2021 he was issued a U.S. Patent for inventing an AI system that automatically detects diseases from ophthalmic images. In 2017 he received UAB College of Arts & Sciences’ highest honor, the Distinguished Alumni Achievement Award. And in 2005 he won the Barrie Hurwitz Award for Excellence in Neurology at Duke Univ School of Medicine where he topped the class in Neurology and in Pediatrics. He is author of the books “Quantum Mechanics & The MRI Machine” and “The Form of Finite Groups: A Course on Finite Group Theory.” Dr. Odaibo Chaired the “Artificial Intelligence & Tech in Medicine Symposium” at the 2019 National Medical Association Meeting. Through RETINA-AI, he and his exceptionally talented team are building AI solutions to address the world’s most pressing healthcare problems. He resides in Houston Texas with his family.

REFERENCES:

1. Medical device software — Software life cycle processes: IEC 62304:2006+AMD1:2015
2. Medical devices — Application of risk management to medical devices: ISO 14971:2019
3. Medical devices — Guidance on the application of ISO 14971: ISO 24971: 2020
4. Implementation of risk management principles and activities within a Quality Management System — GHTF (IMDRF) Study Group 3 (May 20th, 2005)
5. GHTF SG3/N18:2010 Quality management system — Medical Devices Guidance on corrective action and preventive action (CAPA) and related QMS processes