IEC 62304 Software Lifecycle & Verification

IEC 62304 is the international standard for medical device software life cycle processes. It doesn't tell you what your software should do — it defines the process you follow to build it: planning, requirements analysis, architectural design, detailed design, implementation, integration and integration testing, system testing, and release, followed by ongoing maintenance and problem resolution once the product ships.

What makes it a compliance standard rather than just good practice is that every one of those stages has to produce documented, traceable evidence — a reviewer should be able to follow a single requirement all the way from the requirements document, through the design, into the code, and out to the test case that verifies it.

Not every piece of medical device software carries the same risk, and IEC 62304 doesn't pretend it does. Before development starts, software is assigned a safety class based on the severity of harm that could result if the software fails or contributes to a hazard:

• 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 classification is driven by severity, not probability — a distinction that matters, because it means classification is decided through the same risk-management process (ISO 14971) used for the device's safety hazards generally, not through a separate judgment call. A software item can also be assigned a lower class than the system it's part of if it can be shown, through the architecture, that it can't contribute to a higher-severity hazard — part of why architectural design is treated as a compliance activity, not just an engineering one.

The classification isn't just a label — it determines how much process rigor the rest of the lifecycle requires. In practice, that means:

• Class A software can get by with comparatively light documentation and verification, since a failure has no safety consequence.
• Class B software needs documented, requirement-based test cases and evidence that verification actually happened, since a failure could cause non-serious harm.
• Class C software is expected to carry the full weight of the standard: complete requirements-to-test traceability, rigorous architectural and detailed design documentation, comprehensive verification, and a more formal, more heavily reviewed change-control process — because a failure here could be fatal.

We scale unit testing, integration testing, and documentation depth to match the assigned class, rather than applying the same checklist regardless of risk — which keeps Class A work fast and keeps Class C work as rigorous as it needs to be.

IEC 62304 doesn't operate in isolation. ISO 14971 (risk management) is what actually drives the safety classification and the identification of risk-control measures that become software requirements. ISO 13485 (quality management systems) is the broader framework IEC 62304 activities sit inside — document control, design history files, and change management processes that apply to software the same way they apply to hardware. Teams that already operate under ISO 13485 get a home for IEC 62304 records; teams that don't yet have a QMS need that structure built alongside the software process, not after it.

IEC 62304 doesn't end at release. Once software ships, the standard requires a defined problem-resolution process — a way to receive, evaluate, and address defects and field issues — and a defined process for evaluating whether any change (a bug fix, a new feature, a third-party component update) needs to go back through classification and verification, proportional to what changed.