The Software Lifecycle Standard That Turns One Question Into Your Whole Process.
IEC 62304 strategy for medical device software — a compliant lifecycle whose depth is set by a single safety-classification call, produced by your engineering process rather than reconstructed after it.
Safety Class Is the Question. Everything Downstream Is the Answer.
IEC 62304 assigns each software item a safety class from the harm a failure could cause — before mitigation. The class decides how much architecture, documentation, and testing the standard requires of you.
Class A
No injury possible
Failure cannot contribute to a hazardous situation, or the situation cannot lead to harm. The lightest process burden — but the classification has to be defensible, not convenient.
Class B
Non-serious injury possible
Failure could contribute to non-serious injury. Detailed design, unit implementation, and integration testing enter the required process.
Class C
Death or serious injury possible
Failure could contribute to death or serious injury. The full architecture, detailed design, and verification rigour the standard defines — the tier most clinical software lands in.
Segregation can lower the burden. A well-architected system isolates the items that could cause harm, so only those carry Class C rigour — which is why architecture is a regulatory decision here, not just an engineering one.
62304 Isn’t Paperwork Bolted On. It’s the Shape of How You Build.
IEC 62304 defines a software development lifecycle — planning, requirements, architecture, detailed design, implementation, integration, system testing, release — plus the ongoing processes of maintenance, risk management, configuration management, and problem resolution. The standard doesn’t ask for a binder; it asks that your process produce the evidence as a by-product of building.
That is the whole difference between programs that pass and programs that suffer. Retrofit 62304 onto a finished codebase and the “documentation” becomes archaeology under submission deadline. Build the lifecycle to emit the file, and the file is simply there when the SaMD submission needs it.
The compliant lifecycle produces its records while you build — not reconstructed for the audit afterward.
Six Disciplines That Carry a 62304 Program.
From the classification call to the change discipline that keeps every release compliant.
Safety Classification
Each software item classified A, B, or C from pre-mitigation harm — documented and defensible, because the class sets the entire process burden.
Architecture & Segregation
An architecture that isolates the harmful items, so Class C rigour falls only where it must — a design decision that pays back across the whole lifecycle.
Lifecycle Process Design
The 62304 lifecycle wired into your actual development process — requirements, design, verification — so compliance is how you already work, not a parallel track.
Software Risk Management
Software risk management tied to ISO 14971, with the hazard analysis that drives the classification and the controls that earn it back.
Configuration & Problem Resolution
Configuration management and problem-resolution processes that make releases traceable and defects auditable — the unglamorous half of the standard.
Legacy Software & SOUP
Legacy software handled under Amendment 1 and SOUP (software of unknown provenance) controlled — the two realities every real codebase brings to 62304.
62304 mapped onto CI/CD and sprints emits evidence per release — the standard keeps pace with the product.
Your Product Ships Monthly. The Standard Has to Keep Up Without Slowing You Down.
Medical software releases continuously; a lifecycle standard written around discrete versions can feel like friction. The resolution is not to fight 62304 but to implement it inside your CI/CD and agile process — so each release carries its verification evidence forward automatically, and the maintenance process handles the change stream by design.
We map 62304’s activities onto sprints and pipelines, and connect it to the SaMD change discipline that decides, release by release, what stays inside the cleared envelope — so speed and compliance stop being a trade-off.
Six Failure Modes We Are Brought In to Prevent.
Nearly all of them are the standard treated as documentation instead of process.
Retrofitted after the build
A finished codebase with no lifecycle records — the documentation reconstructed after the fact, under submission pressure and at full cost.
Optimistic classification
Software classed A or B to lighten the burden, on a harm analysis that won’t survive review — and a reclassification that reopens the process.
Architecture that segregates nothing
A monolith where every item is Class C because nothing is isolated — the whole codebase carrying the heaviest rigour needlessly.
SOUP uncontrolled
Third-party and open-source components with no provenance or version control — the software-of-unknown-provenance gap an auditor opens first.
Risk management disconnected
A 62304 process running beside ISO 14971 instead of driven by it — so the classification and the controls never actually meet.
Agile pitted against the standard
Design controls treated as waterfall paperwork instead of mapped onto sprints — both systems lose, and the auditor notices.
62304 Leadership That Speaks Engineering.
Our software leads have classified items, architected for segregation, and built 62304 lifecycles inside real release pipelines.
“62304 doesn’t want a document. It wants a process that can’t help but produce one. Build that, and the audit is a formality.”
The discipline we bring to medical software.
Building Medical Software? Set the Safety Class Before You Set the Architecture.
A senior software-regulatory lead can classify your items, design the segregation, and wire 62304 into your pipeline — before a retrofit becomes the only option.
Senior-led. Embedded in your team. No junior hand-offs.