When developing medical device software, safety is not just an aspiration—it is a legal and ethical obligation. Among the many standards that govern this domain, IEC 62304 stands out as the key international standard for medical device software lifecycle processes. One essential part of compliance with IEC 62304 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 behind IEC 62304.

Understanding Functional Safety

Functional safety ensures that a system behaves correctly in response to its inputs, particularly under fault conditions. In the medical domain, this translates to: The software must not cause harm to a patient or user, even in the case of predictable failures.

For example, if a software-controlled infusion pump administers medication, the software must handle sensor failures, communication losses, 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 damage to health is possible
  • Class B: Non-serious injury is possible
  • Class C: Death or serious injury is possible

Depending on the classification, the rigor of testing and verification activities increases significantly. For Class C software, comprehensive testing strategies must be implemented, including unit testing, integration testing, and system-level verification with traceability to risk controls.

The Role of Testing

Testing in the context of IEC 62304 is not just about finding bugs—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: Prioritizing tests based on potential harm
  • Bidirectionally traceable: Linking each test case to a requirement and vice versa

Typical test activities include:

  • Static analysis to detect potential defects early
  • Unit tests to verify logic at the function level
  • Integration tests to ensure proper communication between modules
  • System tests with fault injection and edge cases
  • Verification of risk controls, particularly those related to hardware-software interaction

Traceability

We are known for their obsession with documentation and precision—and in this case, that’s a very good thing. IEC 62304 mandates traceability across the software lifecycle. Every requirement should be linked to:

  • Its origin in the risk management process (typically from ISO 14971)
  • The corresponding architecture or design element
  • The test cases that verify it

Tools like Polarion, Codebeamer, or even open-source alternatives like ReqView and Robot Framework can help enforce this rigor.

Integration with ISO 14971 and IEC 60601

Testing for functional safety cannot happen in isolation. It must be harmonized with other standards like:

  • ISO 14971 for risk management
  • IEC 60601 for electrical safety and essential performance

For example, a Class C software might include a software-implemented failsafe that activates when a hardware sensor reports inconsistent data. This behavior must be tested in both software (mocked sensor failure) and in system testing (actual fault injection).

Final Thoughts

Testing for functional safety in line with 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.

We are in a good position to excel here. Our focus on process discipline, risk management, and engineering integrity provides a solid foundation for building safe, reliable medical software.

In the end, good testing is not about covering every line of code—it is about being able to sleep at night, knowing that your software will not harm anyone.