If you’re developing a medical device that uses software, or developing SaMD (Software as a Medical Device), then it’s important to understand and follow the applicable regulatory requirements.
Manufacturers should engage with the IEC 62304 standard from early in the development process. A common issue is that there can be a disconnect between brilliant developers and the medical device terminology and regulations. This can happen when they get caught up with designing a great new piece of software, but don’t engage with the regulatory requirements at an early stage.
IEC 62304 has been widely adopted by regulators across the world, so familiarity is imperative when compliance will ultimately be required. Here’s how you can follow the IEC 62304 requirements for your medical device software or SaMD:
What is IEC 62304?
IEC 62304 is an international standard for medical device software that defines the framework for processes that occur across the lifecycle of the device and software. Requirements from this standard apply whenever software is an integral component of the device, is used in the production of the device, or if it is the device (Software as Medical Device).
The IEC 62304 standard is harmonized internationally and is recognized by the FDA, Health Canada, the European Commission and other regulatory authorities worldwide. It provides guidance for the planning, development and post-market surveillance activities for medical device software.
Risk control measures form a key part of the IEC 62304 standard. When you consider software, you need to consider any potential risk factors related to software failure, software reconfiguration and validation, and, of course, data protection and cybersecurity.
What are the medical device software classification rules?
IEC 62304 identifies three classification categories for medical device software:
- Class A: No injury or damage to health is possible.
- Class B: Injury is possible, but not serious.
- Class C: Death or serious injury is possible.
Pulling directly from the IEC 62304 standard, here is how medical device software is classified:
If you are developing medical device software to be sold on the US market, you will need to comply with the corresponding FDA requirements. A good general rule of thumb is to work toward satisfying IEC 62304 requirements first, then apply the necessary FDA requirements.
FDA classifies medical device software by “level of concern.” Their guidance on the premarket submission for medical device software highlights the three different levels of concern as follows:
How is the level of concern determined? FDA provides a list of questions 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.
Another common classification question is, who decides whether certain software should be classified as a medical device? The IEC 62304 standard ultimately places the burden on the manufacturer to make that determination. This can be done by following the applicable guidelines, supporting whichever decision is made with evidence as to why the software should be classified as such.
An important note about classification is that it impacts the entire software code development process in terms of what is required for compliance. This makes it critical to get right the first time around.
How to comply with IEC 62304 requirements
The first step of IEC 62304 compliance is to carefully plan the tasks needed for successful software development of the medical device. This should involve reducing risks, creating a system design, and defining procedures. You will need detailed documentation to prove that the applicable IEC 62304 requirements have been met.
Compliance with IEC 62304 requires verification and testing activities to be carried out by the manufacturer. At a general level, you need to establish a testing protocol that shows how design outputs meet design inputs.
For software, your requirement specifications need to be verified in the testing process. Given that software requires updates over time, you will need to document ongoing testing to prove that you’re maintaining compliance with IEC 62304.
A traceability matrix is a useful tool that links together with your product design requirements, design specifications, and testing requirements. You can also use it to tie together identified hazards with the implementation and testing of the risk mitigations.
Greenlight Guru Visualize is the only medical device-specific QMS solution that allows manufacturers to demonstrate full traceability throughout their quality system. Since a quality system is a regulatory requirement for medical device manufacturers, it’s important to have one that is designed to meet your team's functional needs.
Greenlight Guru Visualize
With Visualize, you can connect your quality system data in a single, network view and achieve closed-loop traceability with zero hassle.
Achieve ongoing IEC 62304 compliance with a medical device QMS solution
Traceability of your medical device software design, manufacturing, and post-market activities is a key compliance requirement of IEC 62304. You need a robust, industry-specific QMS that will allow you to easily view and manage all relevant data throughout the life cycle of your medical device software.
Greenlight Guru makes compliance with IEC 62304 as simple as possible by giving users a birds eye view of their quality system to fully understand the relationships between all of its components and easily achieve full traceability.
No more missing documents or outdated testing activities - this cloud-based software keeps all quality system data secure, accessible, and always up-to-date. Get your free demo of Greenlight Guru now →
Looking for a design control solution to help you bring safer medical devices to market faster with less risk? Click here to take a quick tour of Greenlight Guru's Medical Device QMS software