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 for 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 the 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 other 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 in 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 the 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: 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 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, for use error, and for 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.
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.
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 forwards and backwards direction provides by a capable requirements management tool allows medical devices manufacturers to accelerate product development and improve the overall quality of medical devices.
One requirements 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.