As medical devices become more software driven, it’s crucial that we get the safety and reliability right. That’s where IEC 62304 comes into play.
In this blog, I’ll break down what IEC 62304 actually is, why it matters for anyone developing medical device software, and who should be paying attention. I’ve also pulled together a practical checklist to help with compliance, flagged some common mistakes to avoid, and included a few tips to help you stay prepared for audits.
What is IEC 62304 compliance in medical device software?
IEC 62304 provides a framework for the entire software development life cycle, including:
- Software development planning
- Requirements analysis
- Software architectural and detailed design
- Implementation and testing
- Maintenance
- Problem resolution
It also requires risk management integration throughout the process, aligning closely with ISO 14971. As a medical device manufacturer, you’ll likely have ISO 13485 and applicable regulations, such as the EU or UK MDR. So, you won’t need to re-create or duplicate processes, merely integrate them together.
IEC 62304 applies to:
- Embedded software in hardware medical devices (e.g., pacemakers, infusion pumps)
- Standalone software that meets the definition of a medical device (e.g., diagnostic imaging, clinical decision support)
- Mobile health apps which are medical devices
- Software as a Medical Device (SaMD)
- AI as Medical Device (AIMD)
Software is categorized into safety classes (A, B, or C) based on its potential to cause harm, with Class C posing the highest risk. The required rigor increases with the risk class.
The Key Compliance Checklist Points
What Should a Compliant Development Process Include?
To comply with IEC 62304, your development process should include:
| ✔ | Process Area | Activity / Task |
|---|---|---|
| ☐ | Software Development Planning | Software development plan |
| ☐ | Keep software development plan updated | |
| ☐ | Reference plan to system design and development | |
| ☐ | Plan software development standards, methods, and tools | |
| ☐ | Plan software integration and integration testing | |
| ☐ | Plan software verification | |
| ☐ | Plan software risk management | |
| ☐ | Documentation planning | |
| ☐ | Software configuration management planning | |
| ☐ | Control supporting items | |
| ☐ | Control configuration items before verification | |
| ☐ | Identify and avoid common software defects | |
| ☐ | Evaluate software tools and environment | |
| ☐ | Software Requirements Analysis | Define and document software requirements from system requirements |
| ☐ | Ensure completeness and clarity of requirements | |
| ☐ | Include risk control measures in requirements | |
| ☐ | Re-evaluate medical device risk analysis | |
| ☐ | Update software requirements as needed | |
| ☐ | Verify software requirements | |
| ☐ | Software Architectural Design | Transform requirements into architecture |
| ☐ | Design architecture for interfaces of software items | |
| ☐ | Specify SOUP functional/performance requirements | |
| ☐ | Specify required system hardware/software for SOUP | |
| ☐ | Identify segregation necessary for risk control | |
| ☐ | Verify software architecture | |
| ☐ | Software Detailed Design | Subdivide software into software units |
| ☐ | Develop detailed design for each unit | |
| ☐ | Develop interface design | |
| ☐ | Verify detailed design | |
| ☐ | Software Unit Implementation & Testing | Implement each software unit |
| ☐ | Establish software unit verification process | |
| ☐ | Define acceptance criteria for software units | |
| ☐ | Define additional acceptance criteria | |
| ☐ | Perform software unit verification | |
| ☐ | Software Integration & Integration Testing | Integrate software units |
| ☐ | Verify software integration | |
| ☐ | Develop software integration tests | |
| ☐ | Define integration test content | |
| ☐ | Evaluate integration test procedures | |
| ☐ | Conduct regression testing | |
| ☐ | Document integration test results | |
| ☐ | Use software problem resolution process | |
| ☐ | Software System Testing | Define and execute tests for each software requirement |
| ☐ | Use software problem resolution process | |
| ☐ | Retest after changes | |
| ☐ | Evaluate software system testing | |
| ☐ | Record system test results | |
| ☐ | Software Release Activities | Confirm software verification is complete |
| ☐ | Document known residual anomalies | |
| ☐ | Evaluate residual anomalies | |
| ☐ | Document released software versions | |
| ☐ | Document software build/release process | |
| ☐ | Ensure all tasks and activities are complete | |
| ☐ | Archive software release documentation | |
| ☐ | Assure reliable delivery of released software | |
| ☐ | Software Maintenance | Establish software maintenance plan |
| ☐ | Problem and Modification Analysis | Document and evaluate user/market feedback |
| ☐ | Monitor and assess feedback | |
| ☐ | Evaluate problem report impacts on safety | |
| ☐ | Use problem resolution process | |
| ☐ | Analyze change requests | |
| ☐ | Approve change requests | |
| ☐ | Communicate changes to users and regulators | |
| ☐ | Modification Implementation | Use defined process to implement modifications |
| ☐ | Re-release modified software | |
| ☐ | Software Risk Management | Identify software items that could contribute to hazardous situations |
| ☐ | Identify potential causes | |
| ☐ | Evaluate published SOUP anomaly lists | |
| ☐ | Document potential causes | |
| ☐ | Define software risk control measures | |
| ☐ | Implement risk control measures in software | |
| ☐ | Verify risk control measures | |
| ☐ | Document traceability | |
| ☐ | Analyze changes for safety impact | |
| ☐ | Assess impact on existing risk control measures | |
| ☐ | Perform additional risk management activities as needed | |
| ☐ | Software Configuration Management | Identify configuration items |
| ☐ | Identify SOUP | |
| ☐ | Identify system configuration documentation | |
| ☐ | Approve and implement changes | |
| ☐ | Verify changes | |
| ☐ | Ensure traceability of changes | |
| ☐ | Maintain configuration status records | |
| ☐ | Software Problem Resolution | Prepare and document problem reports |
| ☐ | Investigate problems | |
| ☐ | Inform relevant stakeholders | |
| ☐ | Use change control process | |
| ☐ | Maintain problem records | |
| ☐ | Analyze problems for recurring trends | |
| ☐ | Verify problem resolution effectiveness | |
| ☐ | Ensure test documentation includes problem resolutions |
These activities must be tailored to the software safety class – either A,B or C.
What are the most common IEC 62304 mistakes and how can I avoid them?
- 🚫 Start the process early on!
- One of the biggest traps teams fall into is leaving documentation until the end. This almost always leads to gaps in traceability and accuracy
- 🚫 Underestimating software safety classification
- It’s easy to assume your software is low-risk, but misclassifying something as Class A when it should be B or C can lead to missing key controls, and that’s a fast track to failing an audit.
- Note – the software safety class is different to the classification of the medical device itself.
- 🚫 Lack of integration
- IEC 62304 requires risks to be assessed and mitigated at the software level, so if your device has hardware too, you need to ensure both are covered. IEC 62304 echoes the risk based approach which is present throughout the EU MDR, and it all beings at the design and development phase, so it is important to ensure a robust design and development processes aligned with IEC 62304.
- 🚫 Problem resolution procedures
- Failing to track and resolve software issues according to the standard can trigger compliance issues.
What Are Common Audit Failures?
- 🔍 Missing or incomplete documentation
- Always ensure there are records created in line with processes and procedures.
- 🔍 Poor traceability between requirements and test results
- Traceability is key which is why its best to start documenting from the beginning.
- 🔍 Lack of documented risk controls or verification results
- Risk Management is a key part of the product life cycle, so must be done throughout the process – from the conception to post production. Validation and Verification must also be documented throughout the lifecyle, and anytime changes are made.
- 🔍 Nonexistent or poorly defined maintenance plans
- Medical Device Software have full life cycles , so maintenance is very important as the software grows, develops and is updated.
Frequently Asked Questions About IEC 62304 Compliance
What is IEC 62304 compliance in medical device software?
IEC 62304 sets out the lifecycle processes required to design, develop, test, release, and maintain safe medical device software. It ensures risks are managed, documentation is traceable, and systems meet regulatory standards under MDR and IVDR.
Who needs to follow IEC 62304?
Manufacturers of embedded device software, standalone medical software, mobile health apps, Software as a Medical Device (SaMD), and AI as a Medical Device (AIaMD) must comply with IEC 62304.
What are the IEC 62304 software safety classes?
IEC 62304 defines three safety classes:
Class A – No risk of harm.
Class B – Possible non-serious injury.
Class C – Potential for serious injury or death.
The higher the risk class, the more rigorous the development and documentation requirements.
What are the most common mistakes in IEC 62304 compliance?
Typical mistakes include delaying documentation until the end, misclassifying safety levels, failing to integrate risk management, and not maintaining a proper problem resolution process.
How can I prepare for an IEC 62304 audit?
Start by ensuring full traceability between requirements, design, testing, and risk controls. Keep documentation up to date, maintain a clear software maintenance plan, and demonstrate that all verification and validation activities have been completed.
How does IEC 62304 relate to ISO 14971 and ISO 13485?
IEC 62304 integrates with ISO 14971 for risk management and complements ISO 13485 quality management. Together, these frameworks create a compliant foundation for medical device development and regulatory approval.
Zara Malik
Zara works closely with a wide range of clients, supporting them and the wider team at LFH
in bringing medical devices and in vitro diagnostics (IVDs) to market. Her role spans internal
operations and project management, responding to a variety of client queries on quality and
regulatory matters, supporting the development of Quality Management Systems, Technical
Documentation, and assisting with Risk Management activities; ensuring compliance
throughout the product lifecycle.
With over 10 years of experience in the industry, Zara began her career in the laboratory of
an IVD company, where she quickly developed an interest in regulatory affairs. She went on
to specialise in risk management and internal auditing at a large medical device
organisation, before expanding her expertise into Technical Documentation and Post-Market
Surveillance during the implementation of the EU MDR and IVDR. Zara then joined a start-
up, gaining hands-on experience with Software as a Medical Device (SaMD) and AI/ML-
based medical technologies. She now brings this broad and evolving expertise to LFH
Regulatory, supporting clients across a range of complex and emerging regulatory
challenges.
