Medical Device
IEC 62304 verification coverage: proving Class B and C software
How to show verification coverage under IEC 62304 — safety classification, requirements-based tests, integration evidence, and why the thread must stay live for Class B and C.
IEC 62304 structures the medical-device software lifecycle and assigns safety classes (A, B, C) that drive how much verification rigor you owe. This guide focuses on verification coverage — proving that software requirements and integration/system tests actually cover what the class demands — without rebuilding matrices by hand.
What “coverage” means here
For Class B and C especially, you typically need to show:
- Software requirements derived and complete for the safety class
- Verification (often requirements-based tests) mapped to those requirements
- Integration and system testing appropriate to architecture
- Problem resolution and change impact when software changes
- Alignment with risk control measures from ISO 14971
Coverage is not a percentage vanity metric. It is absence of unexplained gaps on the thread: requirements without tests, tests without requirements, mitigations without verification.
Class-aware practical differences
| Class | Verification pressure (simplified) |
|---|---|
| A | Lower — still need a coherent lifecycle story |
| B | Requirements-based testing and integration evidence expected |
| C | Highest — architecture, detailed design, and rigorous verification/impact |
Your SOP defines the exact artifacts. Tooling should make class visible on items and keep links enforceable.
How a system of record should help
- Author software requirements as governed items with safety class.
- Link tests (and runs) that verify them — import libraries via CSV if you are leaving TestRail (migrate from TestRail).
- Link risk controls that software implements.
- Use suspect links when requirements or architecture change so re-test is a worklist, not a rumor.
- Generate coverage views and RTMs for reviews and submissions (RTM guide).
Common gaps auditors find
- Tests exist but do not link to the software requirement ID under test
- Integration tests undocumented relative to architectural items
- Risk mitigations “verified” only in a spreadsheet
- Changes merged without impact analysis on Class C units
Evaluation questions
- Show coverage for a Class B/C subsystem with gaps highlighted.
- Change a software requirement — which tests become suspect?
- Can we export verification evidence for a design review package?
Related reading
See traceability work as one connected system.
Requirements, architecture, tests, risk, and SBOM on a single thread — audit-ready when you need it.