What is IEC 62304?
IEC 62304 is the international standard that defines the lifecycle processes required to develop and maintain safe medical device software. It does not tell you how to write code — it defines the activities, records, and controls you must have in place to demonstrate the software was developed under control.
The standard applies to software that is itself a medical device (Software as a Medical Device, SaMD) and to software embedded in or driving a hardware device (Software in a Medical Device, SiMD). It is recognized by the U.S. FDA as a consensus standard and is harmonized in the European Union, so a single IEC 62304-conformant lifecycle supports submissions in both markets.
What are the IEC 62304 software safety classes (A, B, C)?
IEC 62304 assigns each software item a safety class based on the worst-case harm a software failure could cause: Class A (no injury possible), Class B (non-serious injury possible), and Class C (death or serious injury possible). The class determines how many lifecycle activities and records you must produce.
- Class A — no injury or damage to health is possible from a software failure.
- Class B — a software failure could contribute to a non-serious injury.
- Class C — a software failure could contribute to death or a serious injury.
Classification is driven by ISO 14971 risk analysis and may be reduced when external risk-control measures (hardware interlocks, independent monitors) prevent the hazardous situation. Higher classes require detailed software architecture, detailed design, and unit-level verification that Class A does not.
What lifecycle activities does the standard require?
IEC 62304 defines a set of processes: software development planning, requirements analysis, architectural design, detailed design, implementation and unit verification, integration and integration testing, software system testing, release, maintenance, risk management, configuration management, and problem resolution.
The development and risk-management processes run in parallel. Every requirement traces to design, to test, and to the risk controls it implements — the traceability that an FDA reviewer or notified body expects to see. Configuration management and problem resolution continue across the maintenance phase, including the disciplined handling of SOUP (Software Of Unknown Provenance) such as third-party libraries and operating systems.
How does IEC 62304 connect to ISO 14971 and FDA submissions?
IEC 62304 does not stand alone. ISO 14971 supplies the risk management framework that drives software safety classification and risk controls, and the records produced under IEC 62304 become part of the Design History File and the software documentation in an FDA premarket submission.
In practice, the standards interlock: ISO 14971 identifies hazards and required risk controls, IEC 62304 governs how the software implementing those controls is built and verified, and IEC 62366-1 covers the usability engineering that prevents use-related hazards. The FDA reviews the resulting software documentation against the level of concern / documentation level for the device.
Frequently asked questions
Is IEC 62304 required by the FDA?
The FDA recognizes IEC 62304 as a consensus standard. Conforming to it is the most direct way to show your software was developed under a controlled lifecycle, which streamlines premarket submissions, though the FDA evaluates the overall software documentation rather than mandating the standard by name.
Does IEC 62304 apply to AI/ML software in medical devices?
Yes. AI/ML-enabled device software functions are still software items under IEC 62304 and must follow the same lifecycle, with additional considerations for data management, model validation, and change control under FDA Good Machine Learning Practice and the Predetermined Change Control Plan framework.
Can you retrofit IEC 62304 onto an existing codebase?
Yes, through a gap assessment that reconstructs requirements, architecture, and risk traceability, then establishes configuration management and verification going forward. It is more efficient to start under the lifecycle, but legacy software can be brought into conformance.