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. For medical device software developers, IEC 62304 provides a structured approach to software development, risk management, and documentation so teams can reduce software-related hazards and support patient safety throughout the product lifecycle.
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 the IEC 62304 Medical Device Software Standard?
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 a Medical Device or SaMD). For a quick definition of the standard and its software safety classes, see Greenlight Guru's IEC 62304 glossary
IEC 62304:2006 and IEC 62304:2006+A1:2015
The current recognized version of the standard is IEC 62304:2006+A1:2015, which builds on IEC 62304:2006 and defines life cycle requirements for medical device software. These life cycle requirements are often implemented alongside ISO 13485:2016 for quality management and ISO 14971:2019 for risk management, especially when software is part of a broader device quality system.
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 think about software, you need to consider risks from software failure, configuration changes, verification activities, operating systems, data protection, and cybersecurity. For connected devices and SaMD, cybersecurity in medical devices should be treated as part of the broader software risk management process, not as a separate activity performed at the end of development. Teams that need a deeper framework for linking software hazards to system-level risks can also review Greenlight Guru’s software risk management resource.
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.
This software safety classification affects the depth of documentation, testing, risk control, and maintenance activities required for the software. Higher-risk software generally requires more rigorous documentation across the software development process, including traceability between requirements, risks, tests, and software problem resolution activities. For a deeper explanation of Class A, Class B, and Class C expectations, read Greenlight Guru’s guide to IEC 62304 software safety classes.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.
If you are developing medical device software for the U.S. market, you will need to address FDA expectations for device software functions in addition to IEC 62304. FDA’s current guidance uses a risk-based documentation approach with Basic and Enhanced Documentation Levels for premarket submissions. A practical approach is to use IEC 62304.
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.
Document Software Development Tools and Workflows
IEC 62304 compliance should account for the software development tools your team uses to write, review, test, and release code. That may include issue tracking systems, version control platforms, static analyzers, automated test frameworks, and other tools used to support software validation, verification, and complexity management. The key is to maintain objective evidence that connects these tools and outputs back to your quality records. For teams using Jira and GitHub, Greenlight Guru’s guide to keeping compliance inside the development stack explains how software teams can connect engineering workflows to compliant quality records.
Need a faster way to assess your IEC 62304 readiness? Use Greenlight Guru’s IEC 62304 checklist or gap assessment to identify missing documentation, traceability gaps, software risk management issues, and maintenance process gaps before they slow down your next audit or submission.
Compliance with IEC 62304 requires verification and testing activities to be carried out by the manufacturer. At a general level, you need a testing protocol that shows how design outputs meet design inputs. A requirements traceability matrix can help connect software requirements, hazards, risk controls, test cases, test results, and unresolved issues. Teams may also use software development tools such as static analyzers or automated test frameworks to support verification evidence, especially when software complexity increases.
For software, your requirement specifications need to be verified in the testing process. Because software changes over time, IEC 62304 also expects teams to define a maintenance process and maintain evidence that updates do not introduce unacceptable risk. A software maintenance plan should address updates, defect fixes, technical corrections, regression testing, cybersecurity updates, and software problem resolution after release.
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. For software teams, the software DHF should show how requirements, risks, tests, code changes, and release evidence connect across the full IEC 62304 lifecycle.
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. A purpose-built Quality Management System helps teams manage software requirements, design controls, risk management, verification evidence, software problem resolution, and maintenance activities in one connected system.
Greenlight Guru helps simplify IEC 62304 compliance by giving teams a clear view of their quality system. Users can understand relationships between requirements, risks, tests, documents, and postmarket activities, making it easier to maintain full traceability throughout the medical device software lifecycle.
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
For SaMD and software-enabled device teams, Greenlight Guru also supports connected development workflows that link software work, test evidence, design changes, and DHF documentation.
IEC 62304 Compliance Checklist
Before you move into submission or audit preparation, use this IEC 62304 checklist to confirm whether your software documentation covers the essentials:
- Software development plan and software architecture documentation
- Software safety classification and supporting rationale
- Software requirements and design specifications
- Requirements traceability matrix linking requirements, risks, tests, and mitigations
- Software risk management activities aligned with ISO 14971:2019
- Verification, validation, and test evidence
- Software development tools, static analyzers, and automated test outputs where applicable
- Configuration management and release records
- Software maintenance plan and maintenance process
- Software problem resolution process for postmarket issues
- Cybersecurity in Medical Devices considerations for connected or SaMD products
- Software DHF evidence that connects development, risk, testing, and release activities
If you are unsure where your documentation stands, start with Greenlight Guru’s IEC 62304 gap assessment to identify your highest-priority compliance gaps.
Free download:
3-in-1 SaMD Gap Assessment Tool
3-in-1 SaMD Gap Assessment Tool
