IEC 62304
The international standard defining software lifecycle processes for medical device software — the technical backbone of every FDA and CE-marked software submission.
IEC 62304:2006 AMD 1:2015 (Medical device software — Software life cycle processes) is the primary international standard for medical device software development. It defines processes across the software development lifecycle: software development planning, requirements analysis, architectural design, detailed design, unit implementation and verification, integration and integration testing, system testing, and software release. The standard uses a three-class safety classification (Class A: no injury possible; Class B: non-serious injury possible; Class C: serious injury or death possible) that determines the rigor of required documentation and testing. Class C software requires full traceability from system requirements through detailed design through test cases; Class A requires minimal process documentation. The standard explicitly covers software items (standalone SaMD) and software items embedded in or used with hardware medical devices. IEC 62304 Amendment 1 (2015) added coverage for legacy software and SOUP (Software of Unknown Provenance) — third-party libraries and open source components incorporated into medical device software.
The engineering reality of IEC 62304 compliance in modern software development is the impedance mismatch between the standard's document-centric lifecycle model and contemporary DevOps practices. The standard does not prescribe specific methodologies, but it requires artifacts: software development plan, software requirements specification, software architecture document, detailed design documents, unit test specifications and results, integration test specifications and results, and a software release record. For Class C software, these must be traceable end-to-end. Teams using agile or continuous delivery must map sprint artifacts (user stories, acceptance criteria, automated test results) to the standard's required documentation categories. SOUP management is the most commonly underestimated obligation: every open source library, commercial SDK, and cloud service SDK used in a medical device must be identified, evaluated for known anomalies, and documented in a SOUP list with version pinning, known problem lists, and risk assessments per IEC 62304 § 8.
IEC 62304 does not operate in isolation. FDA references it in multiple device-specific guidances and in the QMSR transition materials. The standard is harmonized under the EU Medical Device Regulation (MDR 2017/745) and In Vitro Diagnostic Regulation (IVDR 2017/746), making compliance required for CE marking of software-enabled devices. ISO 14971:2019 (risk management for medical devices) is normatively referenced by IEC 62304 — software risk management activities must integrate with the device-level risk management process. IEC 62304 does not address system-level requirements (covered by IEC 60601-1 and IEC 62366 for usability), so software lifecycle compliance exists within a broader systems engineering framework. For AI/ML-enabled devices, the standard's concept of "software system" must be extended to cover trained model artifacts, training data management, and model versioning — areas where supplementary FDA and IMDRF guidance is evolving.
We implement IEC 62304-compliant development processes using a documentation-as-code approach: requirements traceability matrices are generated from Jira Epic/Story hierarchies, architectural decisions are captured in structured ADR templates linked to design artifacts, and automated test execution produces evidence artifacts formatted for audit review. Our SOUP management tooling automates dependency scanning, cross-references against known vulnerability databases, and generates compliant SOUP lists with anomaly assessments. We maintain class-specific documentation templates that scale rigor to the safety classification without over-engineering Class A/B software.
Compliance-Native Architecture Guide
Design principles and a structured checklist for building software that is compliant by default — not compliant by retrofit. Covers data architecture, access controls, audit trails, and vendor due diligence.