IEC 62304 Is Not Just a Checklist
Most teams treat the standard as a compliance exercise. The organizations that build truly safe medical software treat it as something else entirely, a discipline of engineering thinking.
There’s a familiar pattern in regulated medical device development. A team of engineers ships features, a quality manager generates the documentation afterward, and everyone checks the boxes needed to pass a regulatory audit. The standard is satisfied. The paperwork is in order. And yet something important has been missed.
IEC 62304, the international standard governing the life cycle processes of medical device software, was never designed to be a documentation template. It was designed to make software safer. Those two things are profoundly different, and conflating them is one of the most common and consequential mistakes in the industry.
Compliance is a floor, not a ceiling. The standard tells you the minimum required; patient safety demands that you ask how far above that floor you’re actually standing.
What the Standard Actually Says
IEC 62304 defines a framework for the entire software life cycle: planning, requirements, architecture, detailed design, unit implementation, integration, testing, maintenance, and risk management. At its core, it does two things. First, it requires that you classify your software based on the severity of potential harm: Class A (no injury), Class B (non-serious injury), Class C (serious injury or death). Second, it scales your required activities based on that classification.
That scaling is the key insight that compliance-oriented teams miss. For Class C software, including cardiac monitors, insulin pump controllers, and radiation therapy planning systems, standard demands architectural design reviews, documented unit testing at every module, traceable requirements, and a formal system for managing changes throughout the entire lifecycle. For Class A software, obligations are considerably lighter.
The point is not bureaucratic: the point is that the severity of the harm your software could cause should determine the rigor with which you build it. That is a statement about engineering culture, not paperwork volume.
SOFTWARE SAFETY CLASSIFICATION
Class A : No injury or damage to health is possible. Lightest documentation obligations.
Class B : Non-serious injury is possible. Moderate rigor required, including architecture documentation.
Class C : Death or serious injury is possible. Full rigor: architectural reviews, unit-level testing, complete traceability.
The Classification Trap
One of the most consequential decisions a development team makes under IEC 62304 is software safety classification. And it is also one of the most frequently gamed. There is enormous pressure, commercial, resource-driven, or simply borne of wishful thinking, classify software at the lowest class possible.
The logic is understandable: Class C demands significant additional rigor. Architectural reviews. Traceable unit tests. Formal change management. All of that costs time and money. But misclassification is not just a regulatory risk, it is a patient safety risk. If you have built a dosing algorithm that could administer a harmful quantity of medication and called it Class B because a human “could theoretically” catch the error, you have not reduced the hazard; you have only reduced your documentation burden.
The question to ask is not “what is the minimum class I can justify?” It is: what class honestly reflects the injury this software could contribute to? The standard is clear that the classification must be driven by the consequences of a software failure, not by organizational convenience.
Four Principles for Teams That Get It Right
01 Classify Honestly
Base class decisions on real hazard severity, not on desired documentation load. Revisit classification when the software’s clinical role changes.
02 Trace Requirements
Every software requirement should trace to a system-level need, and every test should trace to a requirement. Traceability is not busywork it reveals gaps.
03 Integrate Risk Management
IEC 62304 and ISO 14971 are designed to work together. Risk controls live in code. Software architecture decisions are risk management decisions.
04 Maintain and Don’t Abandon
Post-release software changes must go through the same lifecycle rigor as the original development. Problem reports are safety signals, not just support tickets.
Risk Management Is Not a Separate Document
Perhaps the deepest misconception about IEC 62304 is that its relationship to ISO 14971, the companion standard for medical device risk management, is administrative. Teams produce a risk management file, populate it with hazards and mitigations, and treat it as a separate artifact that lives alongside the software documentation.
In practice, risk controls and software architecture are the same thing. When you decide that a particular module should be isolated to contain failure propagation, that is a risk control. When you choose to add a confirmation step before a destructive action, that is a risk control. When you test to a specific coverage level because the consequences of an undetected bug are severe, that is a risk control expressed as a software process.
A development team that genuinely understands IEC 62304 does not ask “have we addressed the risk management requirements?” They ask “does our architecture reflect our understanding of the hazards this software presents?” Those are very different questions, and only one of them produces safer software.
When software engineers understand why a requirement exists, what patient harm it prevents, they make better decisions in every line of code they write, not just in the lines they know are being reviewed.
Maintenance: Where Compliance Culture Does the Most Damage
The section of IEC 62304 that receives the least serious treatment is section 6: software maintenance. Post-release, once the regulatory submission is approved, many organizations treat the standard as effectively complete. Changes go through abbreviated processes. Problem reports accumulate without systematic analysis. The risk management file is not updated to reflect what has been learned from real-world use.
This is precisely backwards. Post-market software is software that has been tested by patients. Problem reports from the field are the richest source of safety information available. A complaint that a user misunderstood a displayed value, or that the software behaved unexpectedly in an edge case, is not a customer service issue, it is a safety signal that deserves root cause analysis and, where appropriate, a software change managed with the same rigor as original development.
Organizations that treat maintenance as a lightweight afterthought are not just cutting corners on compliance. They are actively abandoning the safety improvement loop that makes iterative software development compatible with patient safety.
Building a Culture, Not a Compliance Program
None of this requires heroic effort. It requires a shift in framing. Engineers who understand that a Class C system might directly affect a patient’s life write tests differently. Architects who understand the hazard analysis behind a design decision make better tradeoff choices. Product managers who understand the maintenance requirements of IEC 62304 don’t treat post-release problem reports as noise to be triaged away.
The standard provides the structure. The culture provides the meaning. When an organization genuinely internalizes that its software is in the path between a care decision and a patient outcome, IEC 62304 stops feeling like an obstacle and starts feeling like a useful discipline for doing the work well.
Checklists close audits. Culture closes the gap between what the standard requires and what patients actually need.
IEC 62304 is a starting point, not a finish line.
The teams building the safest medical software are the ones who have moved beyond asking “are we compliant?” to asking “are we doing this well?” Those are not always the same question. The best organizations make sure the answers always converge.