IEC 62304: the medical device software lifecycle, explained

IEC 62304, Medical device software — Software life cycle processes, is the international standard that defines how software in (or as) a medical device should be developed and maintained. Recognized by the FDA and harmonized under the EU MDR, it’s the backbone reviewers expect when software contributes to a device’s safety.

IEC 62304 doesn’t tell you how to write code. It defines a lifecycle framework — a set of processes and the documentation they produce — with the depth of rigor scaled to how much harm the software could cause.

Software safety classes drive the rigor

The standard assigns each software item a safety class based on the severity of harm that a software failure could contribute to, assuming no external risk controls:

• Class A — no injury or damage to health is possible.
• Class B — non-serious injury is possible.
• Class C — death or serious injury is possible.

The class determines which activities and documentation the standard requires. Class C software carries the fullest set — detailed software architecture, unit-level design and verification, and the most thorough integration and system testing — while Class A requires far less. A 2015 amendment also clarified that classification is done at the software-item level and reassessed as the architecture is understood.

The lifecycle processes

IEC 62304 organizes development into a set of processes, each producing required records:

• Software development planning — how you’ll develop, verify, and control the software.
• Software requirements analysis — deriving software requirements from system requirements and risk controls.
• Software architectural design (Class B and C) — and detailed design (Class C).
• Implementation and unit verification.
• Integration and integration testing, then software system testing.
• Software release — with documented evidence that planned activities are complete and known anomalies are evaluated.

Around development sit the maintenance process, configuration management, and problem resolution — because for medical software, what happens after release matters as much as what happens before it.

The link to ISO 14971 risk

IEC 62304 doesn’t manage risk on its own — it connects to ISO 14971, the risk-management standard for medical devices. Software contributes to hazards, and risk controls implemented in software become software requirements that must be specified, implemented, and verified like any other. That connection means your software requirements, your risk controls, and your verification can’t live in separate worlds: a risk control with no verifying test is exactly the kind of gap a reviewer looks for.

Traceability ties it together

Underneath the process structure, IEC 62304 is a traceability standard in disguise. To demonstrate conformity you must show that system requirements flow to software requirements, that software requirements flow to architecture and tests, and that risk controls flow to the requirements and verification that implement them. Reviewers read that chain to confirm nothing was specified without being verified, and nothing was built without being specified.

Maintaining that chain by hand across separate requirements, test, and risk tools is where teams lose time — and where the trace quietly drifts between a design freeze and an audit. A living requirements traceability matrix keeps it current.

That’s the model TraceUnified is built on: software requirements, architecture, tests, and ISO 14971 risk as linked records in one system, with suspect-on-change flagging and live coverage analysis, plus a tamper-evident audit trail and Part 11 signatures for the records that need them. The lifecycle work and its classification are still yours to own; the system is engineered to keep the IEC 62304 thread — requirement to risk control to verification — intact and audit-ready.