When developing software for medical devices, safety is not merely a goal — it is a legal and ethical obligation. Among the many standards that govern this domain, IEC 62304 stands out as the central international standard for the lifecycle of medical device software. A fundamental part of IEC 62304 conformance is systematic testing for functional safety. But what does that mean in practice?
As engineers and software developers we are trained to think in terms of structure, reliability and traceability. This mindset aligns closely with the philosophy of IEC 62304.
Understanding Functional Safety
Functional safety ensures that a system responds correctly to its inputs, particularly in failure situations. In the medical domain this means: the software must not endanger patients or users, even in the event of foreseeable failures.
For example, a software-controlled infusion pump administering medication must handle sensor faults, communication failures and user errors in a way that prevents hazardous events. This is where functional safety comes in.
IEC 62304 and Safety Classification
IEC 62304 defines three software safety classes:
- Class A: No injury or health hazard possible
- Class B: Non-serious injury possible
- Class C: Death or serious injury possible
Depending on the classification, the scope of testing and verification activities increases substantially. For Class C software, comprehensive test strategies must be implemented — including unit tests, integration tests and system verification with traceability to risk controls.
The Role of Testing
Testing in the context of IEC 62304 is not just about finding defects — it is about demonstrating that the software meets its safety requirements under all foreseeable conditions. Testing must therefore be:
- Systematic: following a documented and traceable process
- Risk-based: tests are prioritised according to potential severity of harm
- Bidirectionally traceable: every test case is linked to a requirement and vice versa
Typical testing activities include:
- Static analysis for early detection of potential defects
- Unit tests to verify logic at the function level
- Integration tests to confirm communication between modules
- System tests with fault injection and boundary cases
- Verification of risk controls, particularly in the area of hardware-software interaction
Traceability
Precision and rigorous documentation are well-known strengths of good engineering teams — and here they pay off. IEC 62304 demands traceability across the entire software lifecycle. Every requirement must be linked to:
- Its origin in the risk management process (typically per ISO 14971)
- The corresponding architectural or design element
- The test cases that verify it
Tools such as Polarion, Codebeamer or open-source alternatives like ReqView and Robot Framework can support this rigour.
Integration with ISO 14971 and IEC 60601
Testing for functional safety cannot happen in isolation. It must be aligned with related standards, including:
- ISO 14971 for risk management
- IEC 60601 for electrical safety and essential performance
For example, a Class C software system might include a software-based failsafe that activates when a hardware sensor reports inconsistent data. This behaviour must be verified both in software (simulated sensor fault) and in system testing (actual fault injection).
Closing Thoughts
Testing for functional safety to IEC 62304 is not just a regulatory checkbox — it is a mindset. It requires a deep understanding of both the software architecture and the clinical risks involved.
A focus on process discipline, risk management and technical integrity provides a solid foundation for developing safe and reliable medical software.
In the end, good testing is not about covering every line of code — it is about being able to sleep soundly knowing that the software will not harm anyone.