What IEC 62304 requires for traceability
IEC 62304:2006+AMD1:2015 defines the software lifecycle requirements for medical device software. It is almost always used alongside ISO 13485 (quality management) and ISO 14971 (risk management). Together they form the triad for medical device software development. Regulatory bodies including FDA and notified bodies under EU MDR assess compliance against all three.
§5.2 Software Requirements Analysis requires that software requirements be established, including requirements derived from the risk management process (ISO 14971) and from the intended use. Requirements must be documented with enough detail to permit design, implementation, and testing. Ambiguous requirements (those that cannot be objectively tested) are a finding.
§5.3 Software Architectural Design requires that the architecture be documented and that software items be identified. For Class B and C software, the architecture must demonstrate that software items are appropriately segregated with respect to risk control.
§5.5 Software Unit Implementation and Verification requires that each software unit be tested. For Class C, the standard requires additional rigor in unit acceptance criteria.
§5.7 Software System Testing requires testing at the system level, with documented test procedures and results linked to requirements. Every requirement must be tested. The traceability from requirement to test is a mandatory life cycle output.
§8.1 Software Safety Classification drives the entire framework: Class A (no injury possible), Class B (non-serious injury possible), Class C (serious injury or death possible). Classification is done per software item, not per product. A Class C item in an otherwise Class B product must meet Class C requirements.
How the template covers IEC 62304
| Tab | IEC 62304 coverage |
|---|---|
| User Needs | §5.2: intended use, user needs, risk management inputs |
| Requirements | §5.2: software requirements with safety class annotation |
| Tests | §5.7: system test procedures linked to requirements |
| Risks | ISO 14971 integration: hazards, harms, risk controls per requirement |
The RTMify Status column catches the gap that most frequently causes IEC 62304 audits to stall: untested requirements. In a Class C context, an untested requirement is not a minor finding; it is a potential major nonconformity that can block your technical file approval.
What it doesn’t cover: IEC 62304 also requires a Software Development Plan (§4.1), anomaly resolution records (§9), configuration management (§8), and problem resolution records. The template covers requirements and testing traceability.
Common IEC 62304 audit gaps
- Safety class not assigned per software item. Products often classify the overall product without classifying individual software items. A device might be “Class B overall” but contain specific items handling alarms or drug delivery that are clearly Class C. Under-classification is a serious finding.
- Requirements from risk management not in the SRS. ISO 14971 risk controls often generate requirements (e.g., “the system shall alarm if sensor reading is below threshold”). These must appear in the software requirements document and trace to tests. Auditors specifically look for this linkage.
- No architectural segregation evidence for Class C items. If a Class C software item shares memory, execution context, or I/O with a Class A item, you need evidence of segregation or you need to reclassify the Class A item.
- Test cases not linked to requirements. Having a test suite is not enough. The IEC 62304 §5.7 requirement is for requirements-based testing: each test must reference what it tests.
- SOUP items undocumented. Every third-party library or operating system is a SOUP item (§8.1.2). Auditors routinely ask for the SOUP list, the version, the functional assessment, and the anomaly list review. Many teams maintain this as an undocumented list.
IEC 62304 specific guidance
Software safety class in the Requirements tab: Add a SoftwareClass column (A / B / C) to every requirement row. This makes it possible to filter requirements by class and verify that testing depth is appropriate. Class C requirements need the most rigorous test documentation.
SOUP tracking: Add SOUP items to the User Needs tab with Type: SOUP in a type column, with the library name, version, source, and anomaly evaluation in the notes field. This keeps all your lifecycle artifacts in one file.
Risk control linkage: The ISO 14971 risk management process generates risk control measures. Each measure that is implemented in software must appear as a requirement in §5.2. In the Risks tab, add a column for the corresponding requirement ID. This creates the bidirectional link auditors need: ISO 14971 hazard → risk control measure → software requirement → test.
Regression testing: IEC 62304 §5.8 (change management) requires that changes be tested and that regression testing be performed. When you update a requirement, the RTMify Status column will flag tests that may need re-evaluation. Use this as your regression checklist trigger.
FDA relationship: For US FDA submissions (510(k), De Novo, PMA), the FDA expects IEC 62304 compliance for any SaMD (Software as a Medical Device) or software in a device. The Software Documentation guidance (2023) aligns closely with IEC 62304. Your RTM is part of the Software Description Document expected in the submission.