IEC- 62304: Definition, Compliance, and Certifications Optimization
Introduction:
Software has become an integral part of most medical devices. As such, medical device manufacturers must be able to demonstrate the safety and effectiveness of medical devices containing software. Titled “medical device software — software lifecycle processes,” IEC-62304 is an international standard that specifies life cycle requirements for the development of medical software and software within medical devices, helping medical device manufacturers meet all regulatory requirements and release products that won’t put patients at risk.
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.
“Readers of the standard are encouraged to use IEC 61508 as a source for good software methods, techniques, and tools while recognizing that other approaches, both present, and future, can provide equally good results,” states Annex C of IEC 62304. The US FDA and many other agencies responsible for protecting public health around the world accept IEC 62304 compliance as evidence that medical device software has been designed according to the required regulations.
In the European Union, medical device manufacturers that comply with IEC 62304 automatically satisfy the requirements contained in Medical Devices Directive 93/42/EEC (MDD) with amendment M5 (2007/47/EC) as related to software development.
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:
IEC 62304 requires the manufacturers of medical devices to assign a safety class to the software system as a whole based on the potential to create a hazard that could result in an injury:
- Class A: No injury or damage to health is possible.
- Class B: Non-serious injury is possible.
- Class C: Death or serious injury is possible.
If a subpart of the system has a classification, then all inherited parts have the same classification. If a subpart has a higher classification (such as class B over Class A), then everything is treated as class B unless the rationale why is documented.
Level of Concern:
Medical devices are also classified on the level of concern. The highlights of these levels are:
- Minor – The level of concern is minor if the failures or latest design flaws are unlikely to cause any injuries to the patient or operator.
- Moderate – The level of concern is moderate if a failure or the latest design flaws could directly result in minor injuries to the patient or operator.
- Major – The level of concern is major if a failure or the latest design flaws could directly result in death or serious injury to the patient or operator.
This level is determined by the list of questions provided by the FDA in the aforementioned guidance document that manufacturers can use. If the answer to all questions is “no,” the level of concern is likely to be minor. If some are answered with “yes,” it will be moderate or major, depending on which list the yes answer comes from.
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 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:
- 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.
- 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.
- 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.
