IEC-62304 Risk Management For Medical Devices

Introduction:

In the realm of medical device development, the synergy between cutting-edge software and patient well-being has become increasingly vital. Enter IEC 62304, a globally recognized standard specifically tailored to the complex domain of medical device software. Beyond its comprehensive guidelines for the software life cycle, IEC 62304 also incorporates a sophisticated framework for risk management that addresses the unique challenges posed by software in healthcare technology. In this article, we delve into the intricate world of IEC 62304 risk management for medical devices, exploring how it safeguards patient safety, enhances software quality, and ensures compliance with stringent regulatory requirements. Join us on a journey through the intricacies of managing risks in the realm of medical device software, where innovation meets safety.

What Is IEC-62304? 

Harmonized by the European Union and the United States, IEC 62304 is an international standard for medical device software lifecycle processes, defining requirements for the lifecycle of the development of medical software and software within medical devices.

IEC 62304 is an international standard that specifies requirements for the software life cycle processes used in the development of medical device software. The full title of the standard is “IEC 62304: Medical device software – Software life cycle processes.” It is a critical document for manufacturers of medical devices that incorporate software, as it provides guidelines and requirements for the development, maintenance, and risk management of software used in medical devices.

The International Electrotechnical Commission (IEC) initially published IEC 62304 in 2006 as a standard governing the software life cycle processes for medical devices. In recognition of the evolving landscape of medical device software and the need for enhanced risk management, an important amendment was introduced in 2015. This amendment, known as version 1.1, brought about significant changes to the standard. Officially designated as IEC 62304:2006+AMD1:2015, this revised version introduced a risk-based approach to the safety classification of medical device software and provided clear guidance on addressing legacy software, ensuring that it remains relevant and effective in the ever-changing field of medical technology.

Understanding IEC-62304:

IEC 62304 has nine parts: 

• Part 1: Scope – The scope of IEC 62304 is limited to defining the lifecycle requirements for medical device software. 

• Part 2: Normative References – IEC 62304 references ISO 14971 (Medical devices – Application of risk management to medical devices) as an indispensable document for its application. 

• Part 3: Terms and Definitions – In this part, several terms and definitions are explained for the purposes of IEC 62304, such as:
  • Anomaly: any condition that deviates from the expected based on requirements specifications, design documents, standards, etc., or from someone’s perceptions or expectations. 
  • Change Request: a documented specification of a change to be made to a medical device software product. 
  • Harm: a physical injury, damage, or both to the health of people or damage to property or the environment. 
  • Hazard: a potential source of harm. 
  • Medical Device: any instrument, apparatus, implement, machine, appliance, implant, in vitro reagent or calibrator, software, material, or another similar or related article, intended by the manufacturer to be used, alone or in combination, for human beings. 
  • Medical Device Software: a software system that has been developed for the purpose of being incorporated into the medical device being developed or that is intended for use as a medical device. 
  • Risk: the combination of the probability of occurrence of harm and the severity of that harm.

• Part 4: General Requirements – Lays down general requirements for the manufacturers of medical devices, such as the ability to provide medical device software that consistently meets customer requirements and applicable regulatory requirements. 

• Part 5: Software Development Process – This part of IEC 62304 describes software development as follows:
  • Software Development Planning: the scope of the software project.
  • Software Requirements Analysis: the decomposition of the software into individual software requirements. 
  • Software Architectural Design: the high-level design of the software.
  • Software Detailed Design: it defines how the software will function from the software engineer’s point of view. 
  • Software Unit Implementation and Verification: the coding of software units.
  • Software Integration and Integration Testing: the integration of multiple software units.
  • Software System Testing: tests the software against the previously specified requirements. 
  • Software Release: the deployment of the finished software. 

• Part 6: Software Maintenance Process – An abridged form of the main software development process intended to quickly release patches for software bugs and security risks.

• Part 7: Software Risk Management Process – This part deals with the risk assessment of software failures as well as the management of software safety features which serve as risk controls for hardware failures, user errors, and other system failures.

• Part 8: Software Configuration Management Process – Specifies a source code control system/development environment and describes how to manage builds and releases.

• Part 9: Software Problem Resolution Process – Deals with the evaluation of bugs and related activities to resolve issues.

Safety Classes:

Under IEC 62304, which is the international standard for medical device software life cycle processes, medical device software is categorized into one of three safety classes based on the potential consequences of software failure. These safety classes help determine the level of rigor required in various aspects of software development and risk management. The three safety classes are:

1. Class A: This is the lowest safety class and is assigned to medical device software where a failure is unlikely to directly result in harm to patients or users. Class A software is typically associated with devices where software failure is not expected to cause injury or damage to health. However, this does not mean that no safety considerations are necessary; rather, they are less stringent compared to higher safety classes.
2. Class B: Class B is assigned to medical device software where a failure could result in non-serious injury or damage to health. Software in this class may be associated with devices that have a significant impact on patient safety, but the consequences of failure are not life-threatening or catastrophic. Therefore, stricter software development and risk management processes are required for Class B software compared to Class A.
3. Class C: This is the highest safety class and is assigned to medical device software where a failure could result in serious injury or death. Software in this class is associated with devices where failure poses a substantial risk to patient safety, and the consequences of failure are severe. As a result, Class C software demands the most rigorous software development, validation, and risk management processes.

The assignment of a safety class is based on the potential harm caused by software failure and the role of the software in the overall medical device. It guides the level of documentation, testing, and other activities required to ensure the safety and effectiveness of the software. Manufacturers must carefully assess the safety class of their software and follow the appropriate processes outlined in IEC 62304 to meet the standards and regulatory requirements specific to their class of software. 

Level of Concern:

IEC 62304, the international standard for medical device software life cycle processes, uses a concept known as the “level of concern” to help determine the appropriate level of rigor required for certain aspects of software development and risk management. The level of concern is based on the potential impact of software failure on patient safety and is used to tailor the standard’s requirements to the specific circumstances of the software.

The level of concern is categorized into three levels:

1. Level of Concern 1: Minor – This is the lowest level of concern and is associated with software that has the least potential for harm to patients or users. LoC 1 software typically includes functions that are not directly related to patient safety. For example, software that generates reports or provides non-critical information may fall into this category. The requirements for LoC 1 software are generally less stringent than for higher levels of concern.
2. Level of Concern 2: Moderate – LoC 2 is assigned to software that could impact patient safety but is not likely to cause serious harm or death. This includes software functions that are more closely related to the intended use of the medical device but where the consequences of failure are not life-threatening. Requirements for LoC 2 software are more rigorous than for LoC 1 but less so than for the highest level of concern.
3. Level of Concern 3: Major – This is the highest level of concern and is associated with software that, if it were to fail, could result in serious injury or death to patients. LoC 3 software includes functions critical to patient safety and well-being. Consequently, the requirements for LoC 3 software are the most stringent under IEC 62304, encompassing thorough documentation, verification, validation, and risk management processes.

The assignment of the level of concern is typically determined by the manufacturer during the software development process, based on the potential consequences of software failure. It guides decisions about how rigorously the manufacturer must comply with various aspects of the standard, such as documentation, testing, and risk management. Choosing the appropriate level of concern is a critical step in ensuring that medical device software is developed, validated, and maintained in a manner that aligns with safety requirements and regulatory expectations.

Major Changes in IEC-62304 (2019 Vs 2020):

The first major change is the product scope covered by this new version. In the will of alignment of IEC 82304-1 and IEC 62304, the latter has now an extended product scope with better coverage of the former: Health Software. To be sure that the reader understands that both are aligned, the diagram found in IEC 82304 Annex A has been copied into IEC 62304 Clause 1 “Scope”. We can anticipate that the next version of IEC 82304-1 will see the diagram in Annex A and be moved to Clause 1 accordingly.

Yet, the big difference between IEC 62304 and IEC 82304-1 remains: IEC 62304 covers embedded software, not IEC 82304-1 (replaced by IEC 60601-1 for embedded software).

How to get an IEC-62304 Certification:

The process of qualifying for an IEC-62304 certification has 3 simple steps:

1. Initial Certification – This step requires the conduction of product reviews to analyze the quality management system documentation in accordance with the IEC-62304. Furthermore, an assessment of the lifecycle documentation of the product is also conducted.
2. Certificate Updation – When changes are made to the product, the certificate needs to be updated. A change review is conducted and thus, the number of changes and revisions are updated on the certificate. Also, the bug fixes that are done do not require to be reported if they make no changes to the product. 
3. Re-certification – If you wish to re-certify your product, it would be combined with the ISO-13485 certification. For this, all relevant changes in the software lifecycle are reported and reviewed in accordance with both the standards (IEC-62304 and IEC-13485). 

Supporting IEC-62304 with a Requirements Management Tool

According to IEC 62304, medical device manufacturers should strive to implement a risk-based, structured, and methodical approach to medical device software development and ensure traceability throughout the lifecycle of medical device software to achieve compliance with the standard. 

Medical device manufacturers should take advantage of modern requirements management tools, which help ensure requirements are being met by offering end-to-end traceability and the ability to link functional requirements to test cases, design specs, and other artifacts.

The ability to describe and follow the life of a requirement in both a forward and backward direction provided by a capable requirements management tool allows medical device manufacturers to accelerate product development and improve the overall quality of medical devices. 

One requirement management tool that is particularly capable of meeting the needs of the medical industry is Visure Requirements ALM. This highly collaborative and feature-rich ALM platform provides full traceability and offers high integration with MS Word and Excel, bug tracking, and risk management features, among many others. 

Visure Requirements improves efficiency in an environment of constant competition like the medical industry, reducing costs while helping ensure successful software development by defining requirements, specifications, test and risk, and traceability between them.

Conclusion

IEC-62304 is a standard that helps medical device manufacturers create products that are safe for patients. The standard has been around since 2004 and has been updated a few times. It’s important to follow the guidelines in IEC-62304 to ensure patient safety. However, following the standard can be difficult, especially for smaller companies. That’s where Visure Requirements ALM Platform comes in. Visure Requirements ALM Platform is software that helps companies adhere to IEC-62304 standards. The platform offers features like requirements management, risk management, and change management. Request a free 30-day trial of Visure Requirements ALM Platform today and see how it can help your company adhere to IEC-62304 standards.