About This Guide

This guide walks you through filling in the RTMify template for IEC 62304:2006+A1:2015, the medical device software lifecycle standard. IEC 62304 defines the processes for developing, validating, and maintaining software in medical devices. It operates in concert with ISO 13485 (quality management system) and ISO 14971 (risk management).

IEC 62304 classifies software into three safety classes (A, B, C) based on potential harm severity. Your software's class determines which lifecycle activities are mandatory. This template covers the core software lifecycle phases: requirements (§5.2), architectural design (§5.3), integration testing (§5.5), and system testing/release (§5.7).

For IEC 62304 workbooks, run RTMify Trace with the medical profile. That enables the medical design-input, design-output, and configuration-item checks that sit on top of the generic requirement, test, and risk matrix.

By the end of this guide, you'll have a complete traceability matrix linking User Needs through software requirements, tests, and risk controls. This RTM is a key artifact in your Design History File (DHF) and demonstrates regulatory compliance with IEC 62304 §5.5 bidirectional traceability.

What IEC 62304 Requires for Software Lifecycle

Software Safety Classification (§5.3, Table 1)

Medical device software is classified into three categories based on failure mode severity:

  • Class A — No injury possible (e.g., informational display, log file analysis). Minimal rigor: §5.1–5.2 only (planning, requirements).
  • Class B — Non-serious injury possible (e.g., dosage calculation with automatic verification, patient monitoring with alert). Moderate rigor: §5.1–5.5 (planning through integration testing).
  • Class C — Death or serious injury possible (e.g., critical drug infusion, arrhythmia detection, pacemaker control). Full rigor: all of §5.1–5.7, including §5.5.5 rigorous traceability and §5.7 comprehensive system testing.

Your software safety class is determined through risk analysis per ISO 14971 and must be documented in the Notes column of each software requirement. A single device may contain mixed classes: for example, an ECG monitor might have Class C requirements (arrhythmia detection) and Class B requirements (data storage).

Software Requirements (§5.2)

§5.2 mandates derivation of software requirements from system requirements and risk control measures. Each requirement must be:

  • Traceable — to a User Need (system requirement) or risk control
  • Verifiable — testable or reviewable by objective means
  • Prioritized — safety-critical vs. optional
  • Classified — safety class A, B, or C per risk assessment

RTMify captures this through the Requirements tab: each SWE-nnn requirement traces upward to a User Need (UN-nnn), is linked to a Test Group (TG-nnn) for verification, and includes software safety class in Notes.

Software Architectural Design (§5.3)

§5.3 requires software architecture that separates safety-critical functionality from non-critical code. While detailed architecture diagrams are outside RTMify scope, you should document in the Requirements Notes which software components are safety-critical. For example, note that SWE-002 (arrhythmia detection) is implemented in a hardened arrhythmia_module with independent verification, whereas UI display (non-critical) runs in a separate user_interface module.

Software Integration and Testing (§5.5)

§5.5 mandates integration testing and bidirectional traceability (§5.5.5). Every software requirement must be linked to verification activities (tests or analysis). For Class C, §5.5.5 requires full forward and backward traceability: every requirement traces to a test, and every test traces back to a requirement.

RTMify's Test Group mechanism enforces this: create test records linked to each requirement via Test Group ID. For Class C, ensure no orphaned requirements or tests.

Software System Testing and Release (§5.7)

§5.7 requires system testing demonstrating that the integrated software meets all requirements. Validation activities (clinical trials, usability testing, real-world deployment) also fall here. RTMify's Tests tab should include both verification (functional testing against spec) and validation (real-world testing against clinical/operational needs).

SOUP (Software of Unknown Provenance, §5.1.3)

SOUP items are pre-developed software (COTS libraries, open-source packages, vendor tools) used without modification. Per §5.1.3, you must identify SOUP, assess use context and failure modes, and document risk mitigation. Create Risks table entries for each SOUP component. For example, if you use an open-source ECG processing library, assess the risk of calculation errors and specify verification tests (T-001, T-002) that prove correctness independent of the library's internal implementation.

Step-by-Step Walkthrough

1 Define User Needs (System Requirements)

Capture system-level design inputs from your ISO 13485 design input process (§7.3.2) and risk control measures from ISO 14971. These become the foundation for software requirements traceability per IEC 62304 §5.2. Sources include:

  • System-level design inputs (patient monitoring, medication delivery, diagnostic criteria)
  • Risk controls identified in ISO 14971 FMEA (e.g., "Software shall detect arrhythmia within 3 seconds" to mitigate risk of missed critical event)
  • Regulatory/operational requirements (IEC 62304 §6.1 on maintenance, field updates)
  • Customer/clinical needs (review stored data, interface design)

Use ID format UN-nnn. Be specific and measurable: "Software shall alert clinician within 5 seconds" is better than "shall alert promptly".

User Needs / System Requirements Example
ID Description Source Priority
UN-001 Software shall calculate and display patient heart rate from ECG signal System Requirement (ISO 13485 §7.3.3) High
UN-002 Software shall detect and alert on arrhythmia events within 5 seconds Risk Control (ISO 14971) High
UN-003 Clinician shall be able to review 24 hours of stored ECG waveform data Customer Medium
UN-004 Software shall be updatable in the field without specialized tools Regulation (IEC 62304 §6.1) Medium
Tips: Every User Need should trace forward to at least one software requirement (SWE-nnn). Unlinked User Needs indicate incomplete design and will fail RTMify Trace. Use the Source column to record whether this is an ISO 13485 design input, ISO 14971 risk control, regulatory requirement, or customer need. This helps auditors understand traceability to your quality system.

2 Write Software Requirements (§5.2 Requirements Analysis)

Document software requirements per §5.2, deriving each from a User Need or risk control. Record software safety class (A, B, or C) in the Notes column. Each requirement must be verifiable.

  • Requirement ID (SWE-nnn) — Software requirement identifier
  • Description — Functional specification, measurable and testable (use SHALL)
  • Traces — Parent User Need (UN-nnn) or Risk ID
  • Priority — Safety-critical (High) or optional (Medium/Low)
  • Test Group — Link to verification activities (TG-nnn)
  • Status — Approved, In Review, Draft
  • Notes — Software safety class (Class A/B/C), risk mitigation reference
Software Requirements Example (with Safety Classification)
ID Description Traces Priority Test Group Status Notes
SWE-001 The ECG processing module SHALL compute heart rate from R-R intervals with accuracy ±2 BPM UN-001 High TG-001 Approved Class C — safety-critical calculation
SWE-002 The arrhythmia detection module SHALL identify ventricular fibrillation within 3 seconds of onset UN-002 High TG-002 Approved Class C — risk control measure per 14971
SWE-003 The data storage module SHALL retain 24 hours of continuous ECG at 500 Hz sample rate UN-003 Medium TG-003 Approved Class B — data integrity
SWE-004 The update mechanism SHALL verify firmware image integrity via SHA-256 before installation UN-004 Medium TG-004 Approved Class B — maintenance safety
Tips: Use SHALL (mandatory requirement) for software-critical functions. Assign software safety class based on ISO 14971 risk assessment: Class C for functions that could cause death/serious injury (e.g., drug dosage, arrhythmia detection), Class B for non-serious injury risk, Class A for no injury. Record class in Notes per §5.3. Every requirement must have a Test Group for verification per §5.5. For Class C, ensure §5.5.5 bidirectional traceability is complete. See Requirements for traceability depth guidance.

3 Define Software Tests (§5.5 Integration Testing & §5.7 System Testing)

Document verification and validation activities per §5.5 (integration testing) and §5.7 (system testing and release). Link each test to a requirement via Test Group. Methods include:

  • Test — Functional testing, bench testing, database stress testing, integration testing
  • Analysis — Engineering analysis (algorithm correctness, statistical analysis, signal processing)
  • Inspection — Code review, design review, documentation review
  • Demonstration — Clinical validation, usability study, field trial, operational scenario walk-through
Tests & Verification Example (§5.5–§5.7)
Test Group Test ID Type Method Description
TG-001 T-001 Verification Test Heart rate accuracy test — MIT-BIH arrhythmia database
TG-001 T-002 Verification Analysis R-R interval algorithm analysis — noise immunity
TG-002 T-003 Verification Test VF detection sensitivity/specificity — AHA database
TG-002 T-004 Validation Demonstration Clinical validation — cardiologist review of 100 cases
TG-003 T-005 Verification Test 24-hour continuous recording test at 500 Hz
TG-004 T-006 Verification Test Firmware update integrity test — corrupted image rejection
Tips: Link every Test Group to a software requirement. One requirement may have multiple tests: for example, SWE-001 (heart rate accuracy) is verified by T-001 (bench test with reference ECG) and T-002 (algorithm analysis for noise immunity). For Class C requirements, include both unit-level verification (algorithm analysis) and system-level validation (clinical review). Include clinical validation (Demonstration) for Class C safety-critical requirements; e.g., TG-002 includes T-004 clinical validation demonstrating arrhythmia detection works in real patient data. For SOUP items, create tests proving the SOUP component's correctness in your use case. See Tests & Verification for detailed guidance.

4 Document Risks and SOUP (§5.1.3, ISO 14971 Integration)

Identify failure modes and SOUP items, assess severity and mitigation, track residual risk. Per §5.1.3, SOUP (Software of Unknown Provenance) must be identified, risk-assessed, and mitigated. Link risks to requirements that implement mitigation.

Risks & Mitigations Example
Risk ID Description Severity Occurrence Mitigation Linked Req Residual Severity Residual Occurrence
RSK-101 ECG algorithm miscalculates heart rate due to noise artifact 4 3 Bandpass filter + adaptive threshold, alarm on signal quality < threshold SWE-001 4 1
RSK-102 Arrhythmia detection fails to alert on VF 5 2 Dual-algorithm detection (morphology + rate), redundant alert path SWE-002 5 1
RSK-103 Corrupted firmware update renders device inoperable 4 2 SHA-256 verification, rollback to known-good image on failure SWE-004 4 1
Tips: Use ISO 14971 risk severity/occurrence scale (1–5) to justify software safety class assignments. High-severity failures (death/serious injury) drive Class C requirements and rigorous testing. Mitigation is built into design: for example, "Arrhythmia detection fails to alert" is mitigated by SWE-002 (dual-algorithm detection) and verified by T-003/T-004. For SOUP items, create a Risk entry documenting the library, version, known limitations, and verification tests proving correctness in your context. Track residual risk post-mitigation; auditors expect risk to be reduced to acceptable levels. See Risk Management for FMEA and SOUP assessment guidance.

5 Check Traceability and Generate RTM (§5.5.5 Bidirectional Traceability)

Run RTMify Trace to validate bidirectional traceability per §5.5.5. Every row should show OK status. The trace checks:

Use rtmify-trace --profile medical your-workbook.xlsx for IEC 62304 validation. The medical profile adds Design Input → Requirement → Design Output / Configuration Item continuity checks that are expected in software lifecycle and DHF reviews.

  • MISSING_USER_NEED — Software requirement with no parent User Need link (traceability upward broken)
  • NO_TEST_LINKED — Requirement with no Test Group (verification per §5.5 missing)
  • ORPHAN_TEST — Test Group with no Requirement (scope creep or obsolete test)
  • INCOMPLETE_RISK — Risk with no mitigation or residual risk still unacceptable
  • ORPHAN_USER_NEED — User Need with no linked software requirement (design input not addressed)

Fix all issues before design completion. A clean RTM demonstrates compliance with §5.5.5 bidirectional traceability and is mandatory evidence in your Design History File (DHF).

Pro tip: Export your RTM as a traceability report and include it in your DHF. For Class C software, auditors require evidence of §5.5.5 full forward/backward traceability. RTMify's status checks help ensure compliance. See Status Codes for full error definitions and remediation steps.

What This Template Covers vs. Doesn't Cover

Covered

  • ✓ Software Requirements (§5.2) — Derivation of software requirements from system requirements and risk control measures, with software safety classification (Class A, B, C)
  • ✓ Software Architectural Design (§5.3 context) — Safety-critical component identification and separation from non-critical code, documented in requirement Notes
  • ✓ Software Integration and Testing (§5.5) — Integration testing strategy and bidirectional traceability per §5.5.5; every requirement linked to verification activity
  • ✓ Software System Testing and Release (§5.7) — System testing, validation (clinical/operational), and release readiness; verification vs. validation distinction
  • ✓ SOUP Identification and Risk Assessment (§5.1.3) — Pre-developed software identification, risk assessment, and mitigation documentation
  • ✓ ISO 14971 Risk Control Traceability — Linkage between risk controls and requirements, residual risk tracking post-mitigation

NOT Covered (separate IEC 62304 documentation)

  • ◦ Software Development Planning (§4.0) — RTMify supports design execution; your development plan (SOP for requirements review, change control, traceability management) is a separate document. Reference your plan in RTMify Source fields where applicable.
  • ◦ Detailed Architectural Design (§5.3 full documentation) — RTMify captures requirement-level safety classification. Detailed architecture diagrams, module interfaces, and design rationale are maintained in your design documentation (separate from RTMify).
  • ◦ Detailed Unit Implementation (§5.5.3–5.5.5, code-level) — RTMify traces to test groups; source code implementation details, unit test records, and code traceability are managed in your code repository and development environment. Your Software Test Report links RTMify's test groups to detailed test procedures and code coverage metrics.
  • ◦ Code Review and Inspection Records (§5.5.2) — Code review results and inspection checklists are maintained separately in your development QMS. Link them to RTMify test entries (Inspection method) for visibility.
  • ◦ SOUP Anomaly Tracking (§5.1.3) — SOUP defect logs still live in your defect system, but RTMify Live now supports a dedicated SOUP register with version, known anomalies, anomaly evaluation, and trace links rather than burying that evidence in Risk Notes.
  • ◦ Software Maintenance (§6.0) — Post-release maintenance, problem reports, and corrective action are handled by your QMS configuration management and problem resolution process (separate from design-phase RTMify).
  • ◦ Design History File (DHF) Assembly — RTMify generates the traceability matrix portion of your DHF. You assemble the complete DHF with design inputs, outputs, verification records, validation records, and design change controls per ISO 13485 §8.5.

Frequently Asked Questions

What is the difference between Class A, B, and C software? +

IEC 62304 classifies medical device software based on severity of potential harm. Class A: No injury is possible (e.g., informational display not used for diagnosis). Class B: Non-serious injury possible (e.g., calculation with automatic verification). Class C: Death or serious injury possible (e.g., critical monitoring or dosage calculation). Classification determines which IEC 62304 activities are mandatory. Class A requires only §5.1–5.2 (planning and requirements). Class B adds §5.3–5.5 (architecture and integration testing). Class C requires full §5.5 and additional emphasis on traceability per §5.5.5 and rigorous testing per §5.7. Your software safety class is determined through FMEA/risk analysis per ISO 14971 and should be recorded in the Notes column of your Requirements.

How do I handle Software of Unknown Provenance (SOUP) components? +

SOUP items are pre-developed software (COTS, open-source, vendor libraries) used in your device without modification. Per §5.1.3, you must identify them, assess their use and potential failure modes, document known anomalies, and record your anomaly evaluation and verification strategy. In RTMify Live, use the dedicated SOUP workbook or SOUP API so each component has a version, safety class, known anomalies, anomaly evaluation, and direct requirement/test links. Risks still document the system-level hazard and mitigation story; the SOUP register becomes the controlled software inventory.

Do I need a separate RTMify template if I am already using one for ISO 13485? +

No. Use a single RTMify template with one User Needs tab, one Requirements tab, one Tests tab, and one Risks tab. The template structure is universal. IEC 62304 is the software-specific portion of ISO 13485 quality management system. Your User Needs can include both ISO 13485 design inputs (§7.3.2) and IEC 62304 requirements (§5.1–5.7). Requirements can mix business logic (ISO 13485) with safety-critical software requirements (IEC 62304). Tests mix functional verification with validation per both standards. Your single RTM serves as evidence for both audits. In the Notes column, flag software safety class (Class A/B/C) and reference the applicable IEC 62304 section (e.g., "Class C, §5.5.5 traceability required").

What if my software safety class changes mid-project? +

This is a change control event. Per ISO 13485 §8.5.6 (design and development changes), document the rationale: new risk assessment, feature scope change, clinical use evolution, etc. Update the affected Requirements with the new software safety class in the Notes column. Verify that your tests and risk mitigations are sufficient for the new class. If upgrading from Class A→B or B→C, you may need additional verification activities (e.g., adding §5.5 integration tests). Create a Change Record linking the Requirements that changed, the risk assessment justifying the new class, and any new tests required. Submit this change record to your QMS change control board before finalizing the design. RTMify Trace will show the updated class assignments; ensure all new verification activities are linked.