IEC 62304: medical device software life cycle processes, explained

Per its own text, IEC 62304 "defines the life cycle requirements for medical device software" and establishes "a common framework for medical device software life cycle processes." It applies to software that is itself a medical device, and to software embedded in or forming part of a final medical device. Two things sit outside its scope by design: validation and final release of the complete medical device (that belongs to broader device-level standards and a manufacturer's quality system), and any specific life cycle model — the standard does not mandate waterfall, iterative, or any other development approach; a manufacturer's existing life cycle model is what the standard's processes get layered onto.

Clauses 1 through 3 cover scope, normative references and definitions. Clause 4 sets general requirements. Clauses 5 through 9 are the substantive processes:

Clause 4.1 requires a manufacturer to operate a quality management system — in practice, most manufacturers demonstrate this through ISO 13485 certification. Clause 4.2 requires a risk management process conformant with ISO 14971, run throughout the life cycle rather than as a one-time exercise. Clause 4.3 requires a documented software safety classification (A, B or C) for every software system, assigned before development work starts, since the classification determines which later-clause activities actually apply. Clause 4.4 handles legacy software: rather than forcing a full retroactive development-process record onto software already fielded or acquired, it requires a gap analysis against the standard's current requirements and a risk-based decision about which gaps must be closed.

A subcomponent inherits its parent software item's classification by default; a manufacturer can only assign a lower class to a subcomponent by demonstrating adequate segregation from the higher-risk parts of the system. This makes the classification decision an early-architecture decision, not a paperwork exercise done after the fact — getting the segregation argument wrong after Class C work has already been built at Class A rigor is expensive to retrofit.

IEC 62304 does not duplicate quality management or risk management — it points outward to ISO 13485 and ISO 14971 and builds its own process requirements on top of them. It also sits underneath IEC 81001-5-1, the newer security-specific standard for health software: per IEC 81001-5-1's own Introduction, its Clauses 5 through 8 are "arranged in the ordering of IEC 62304" specifically so a manufacturer already running an IEC 62304-conformant life cycle can extend it with security activities rather than build a second, parallel process. A manufacturer building a connected or network-capable medical device in practice runs both: IEC 62304 for the safety-oriented software life cycle, IEC 81001-5-1 layered on top for the security activities within that same life cycle.

FDA's Recognized Consensus Standards database lists IEC 62304 Edition 1.1:2015-06 (the consolidated version) and the equivalent ANSI/AAMI/IEC 62304:2006/A1:2016 both under recognition number 13-79, recognized 14 January 2019, category Software/Informatics, extent of recognition "Complete." A manufacturer can cite conformance to the consolidated edition directly in the Software/Firmware section of a 510(k), De Novo or PMA submission — though FDA recognition of a standard is never a substitute for FDA's own review of the specific device and submission; see FDA premarket cybersecurity for medical devices for the Section 524B cybersecurity duties that sit alongside this software life cycle requirement.

IEC/TC 62/SC 62A and mirror national committees (BSI's project reference 2024-03021, among others) are actively developing an Edition 2, but no published text or confirmed date exists yet; nothing below is normative. Independent secondary reporting on the draft describes: a proposed retitling and scope expansion from "medical device software" to "health software" more broadly — mirroring how IEC 81001-5-1 already defines that wider category; a proposed consolidation of the three safety classes into two rigor levels, intended to better align with FDA's Basic/Enhanced documentation framework; and a proposed informative annex flagging AI/ML software as a discussion topic rather than a normative requirement. Treat all of this as to be confirmed against IEC's own published Edition 2 once it exists, not something to build a compliance program around today.