Embedded software in medical devices directly influences clinical outcomes. A firmware defect in a patient monitoring device may produce incorrect readings that lead to wrong clinical decisions. A communication error in an insulin delivery system may result in incorrect dosing. A bootloader failure in a cardiac monitor may leave the device unable to boot when it is needed. Regulatory bodies - the FDA in the United States, the Notified Bodies in Europe under MDR, and their equivalents globally - require medical device manufacturers to demonstrate systematic control over the software development process that produces these devices. IEC 62304 is the international standard that defines this systematic process.
IEC 62304 Software Safety Classes
IEC 62304 classifies software into three safety classes based on the potential severity of harm resulting from software failures. The safety class determines the development lifecycle requirements that must be satisfied.
| Safety Class | Harm Potential | Key Additional Requirements |
|---|---|---|
| Class A | No injury possible | Basic development process documentation |
| Class B | Non-serious injury possible | Full lifecycle documentation + software architecture document + integration testing |
| Class C | Serious injury or death possible | All Class B requirements + detailed software design document + unit testing with coverage analysis + full traceability |
Software Development Lifecycle Requirements
IEC 62304 requires a defined software development lifecycle covering planning, requirements, architecture, detailed design, unit implementation, testing, release, and maintenance. For embedded teams, the most significant requirements are software requirements specification - every software requirement must be documented, uniquely identified, and traceable to system requirements and test cases; software architecture - the decomposition of the software into software items must be documented with rationale, and the architecture must address concurrent processes, data management, and error handling; software unit implementation - each software unit must be implemented according to the detailed design and in accordance with the adopted coding standard.
Unit Testing Under IEC 62304 Class C
Class C software requires unit testing with a documented testing approach and evidence of coverage. Unlike ISO 26262 which specifies specific coverage metrics (MC/DC at ASIL D), IEC 62304 does not mandate specific coverage criteria - it requires that the manufacturer justify the coverage approach selected. In practice, most Class C programmes target branch coverage as a minimum, with statement coverage supplemented by robustness testing of boundary conditions and invalid input handling. Test cases must be documented with expected results before execution, and actual results must be recorded. Deviation between expected and actual results must trigger a corrective action process.
Traceability Requirements
IEC 62304 requires bidirectional traceability between software requirements and design elements, between design elements and implementation, and between requirements and test cases. In practice, this means maintaining a traceability matrix - typically in a requirements management tool - that links each requirement to the software item that implements it, the test case that verifies it, and the test result that demonstrates it was verified. For embedded firmware teams accustomed to informal development processes, establishing and maintaining this traceability matrix is often the most time-consuming aspect of IEC 62304 compliance adoption.
MISRA-C Alignment with IEC 62304
IEC 62304 requires that a coding standard be adopted and applied to all software unit implementation. MISRA-C:2012 is the most widely adopted coding standard in embedded medical device development, providing a well-defined rule set with established static analysis tool support. The MISRA-C deviation process - requiring formal justification for every rule deviation - aligns naturally with IEC 62304's documentation requirements. Static analysis enforcement using tools such as Helix QAC or PC-lint Plus generates the compliance evidence that demonstrates the coding standard was applied throughout the codebase.
Implementing IEC 62304-Aligned Software with RAPIDSEA
RAPIDSEA's MISRA-C compliant source delivery directly supports IEC 62304 compliance for embedded medical device programmes. Source code availability enables the unit testing, static analysis, and code review that IEC 62304 Class B and Class C require - which are not possible with binary-only library deliveries. The modular architecture aligns naturally with IEC 62304's software item decomposition requirements, with each protocol stack and firmware module representing a clearly bounded software item with a defined interface specification. Royalty-free licensing eliminates per-unit cost uncertainty that can complicate medical device programme budgeting.
Conclusion
EC 62304 establishes a systematic software development process discipline that protects patients from software-induced harm and gives regulatory bodies the evidence they need to assess device safety. For embedded medical device firmware teams, the standard's most significant practical requirements are the documentation of the software lifecycle, unit testing with coverage evidence, and bidirectional traceability between requirements and test results. RAPIDSEA's MISRA-C compliant source delivery and modular architecture support integration into IEC 62304-compliant development programmes.
Ready to discuss IEC 62304 compliance for your medical device firmware? Contact our team to request an evaluation build or book a technical demo.