Skip to content

IEC 62304: Medical Device Software

IEC 62304:2006+AMD1:2015 defines the software lifecycle processes required for medical device software. It is the internationally recognized standard that FDA, EU MDR, and other regulatory bodies reference when evaluating whether your software development process is adequate.

If you're building software that runs on or connects to a medical device — from a blood glucose monitor to an MRI system — IEC 62304 compliance is not optional.

Software Safety Classification

IEC 62304 assigns every software system (or software item) to one of three safety classes based on the severity of harm that could result from a software failure:

Safety Class Hazard Severity Example Devices Documentation Rigor
Class A No injury or damage to health Data logging, report generation Minimal
Class B Non-serious injury Patient monitoring alerts, dosage calculators Moderate
Class C Death or serious injury Infusion pump control, ventilator software, implant firmware Maximum

Classification drives everything

The safety class determines which IEC 62304 clauses apply. Class C requires every deliverable; Class A requires only requirements and verification planning. Getting the classification wrong — in either direction — creates audit risk.

Required Deliverables by Safety Class

The following table shows which IEC 62304 deliverables are required (●), recommended (○), or not required (—) for each safety class:

IEC 62304 Deliverable Clause Class A Class B Class C
Software Development Plan 5.1 ● ● ●
Software Requirements Specification 5.2 ● ● ●
Software Architecture 5.3 — ● ●
Software Detailed Design 5.4 — — ●
Software Unit Implementation & Verification 5.5 — — ●
Software Integration & Integration Testing 5.6 — ● ●
Software System Testing 5.7 ● ● ●
Software Release 5.8 ● ● ●
Software Maintenance Plan 6.1 ● ● ●
Risk Management File (ISO 14971) 7.1 ● ● ●
Traceability Matrix 5.7.4 ● ● ●

Artifact Mapping: IEC 62304 → V-Model Extension

This is the core reference table. For each IEC 62304 deliverable, the corresponding V-Model Extension command and output artifact are listed:

IEC 62304 Clause Required Deliverable V-Model Command Output Artifact ID Schema
5.2 Software Requirements Analysis Software Requirements Specification (SRS) requirements requirements.md REQ-NNN
5.3 Software Architecture Software architecture document architecture-design architecture-design.md ARCH-NNN
5.4 Software Detailed Design Software unit detailed design module-design module-design.md MOD-NNN
5.5 Software Unit Verification Unit test cases and results unit-test unit-test.md UTP-NNN-X / UTS-NNN-X#
5.6 Software Integration Testing Integration test cases and results integration-test integration-test.md ITP-NNN-X / ITS-NNN-X#
5.7.1 Verification Strategy Verification plan for each requirement acceptance acceptance-plan.md ATP-NNN-X / SCN-NNN-X#
5.7.4 Software Requirements Verification Traceability of requirements to tests trace traceability-matrix.md Multi-matrix
7.1 Risk Management Process Risk analysis and evaluation (ISO 14971) hazard-analysis hazard-analysis.md HAZ-NNN

System-level design

IEC 62304 Clause 5.3 requires a software architecture. For complex devices, you may also need system-level design documentation. Use the system-design command to generate IEEE 1016:2009–aligned system design views (SYS-NNN), and system-test for corresponding ISO 29119-4 test procedures.

Class C Workflow: Blood Glucose Monitor

Here's how a team building Class C medical device software (e.g., a blood glucose monitor) would use the V-Model Extension to generate all required IEC 62304 deliverables:

Step 1 — Configure the domain

# v-model-config.yml
domain: iec_62304
safety_class: C
device_name: "BG-Monitor Pro"

Step 2 — Generate requirements

specify run speckit.v-model.requirements specs/bg-monitor/

This produces requirements.md with IEEE 29148–validated requirements, each assigned a persistent REQ-NNN identifier. The 8-criteria validation ensures every requirement is unambiguous, testable, atomic, complete, consistent, traceable, feasible, and necessary.

Step 3 — Generate architecture and module designs

specify run speckit.v-model.architecture-design specs/bg-monitor/
specify run speckit.v-model.module-design specs/bg-monitor/

These produce architecture-design.md (IEEE 42010 views, ARCH-NNN) and module-design.md (pseudocode, state machines, error handling, MOD-NNN).

Step 4 — Generate test artifacts at every level

specify run speckit.v-model.acceptance specs/bg-monitor/
specify run speckit.v-model.integration-test specs/bg-monitor/
specify run speckit.v-model.unit-test specs/bg-monitor/

Step 5 — Run hazard analysis

specify run speckit.v-model.hazard-analysis specs/bg-monitor/

This produces an FMEA register (HAZ-NNN) aligned with ISO 14971 risk management, including severity × likelihood matrices and mitigation traceability back to REQ-NNN and SYS-NNN.

Step 6 — Generate the traceability matrix

specify run speckit.v-model.trace specs/bg-monitor/

This produces the multi-level traceability matrix with:

  • Matrix A: Requirements → Acceptance Tests
  • Matrix C: Architecture → Integration Tests
  • Matrix D: Module Design → Unit Tests
  • Matrix H: Hazards → Mitigations → Verification (auto-included when hazard-analysis.md exists)
  • Coverage Audit: Exact percentages with gap/orphan flagging

Step 7 — Verify compliance

Look for OVERALL STATUS: ✅ COMPLIANT in the Coverage Audit section. Any gaps or orphans appear in the Exception Report with specific IDs.

Tips for FDA Submissions

FDA 510(k) and PMA considerations

  • Software Level of Concern: FDA maps to IEC 62304 safety classes. A Class C device typically requires a Major Level of Concern submission.
  • Software Documentation: The traceability matrix generated by trace satisfies FDA's expectation for bidirectional traceability in the Software Description section.
  • Hazard Analysis: The FMEA register from hazard-analysis maps directly to FDA's risk analysis requirements under 21 CFR Part 820.30(g).
  • Predicate comparison: When preparing a 510(k), use the requirements command to structure your software requirements in a format that makes predicate device comparison straightforward.
  • Cybersecurity: For connected devices, supplement V-Model artifacts with FDA's Premarket Cybersecurity Guidance documentation.

IEC 62304 + ISO 14971 Integration

IEC 62304 explicitly references ISO 14971 (Medical Device Risk Management) for hazard analysis. The V-Model Extension's hazard-analysis command generates an FMEA that satisfies both:

ISO 14971 Requirement V-Model Extension Coverage
Hazard identification HAZ-NNN identifiers linked to system components
Risk estimation (severity × probability) Severity × Likelihood matrix with standardized scales
Risk evaluation against acceptability criteria Risk matrix with pre-defined thresholds
Risk control measures Mitigation actions traced to REQ-NNN / SYS-NNN
Residual risk evaluation Post-mitigation risk levels documented per hazard
Verification of risk control effectiveness Matrix H traces mitigations through to test verification

Cross-References