Photo: Google Gemini · AI-generated
IEC 62304 has governed medical device software life cycles since 2006. Its second edition is the largest revision in that time — and it is currently a committee draft, not a published standard.
That distinction matters, so let us start there rather than at the end.
What is actually settled, and what is not
Not settled: the date. Published forecasts disagree. Some point to publication in mid-to-late 2026, others to early-to-mid 2027. Anyone quoting you a firm date is guessing.
Not settled: when it binds you. Publication is not adoption. Formal regulatory recognition — FDA recognition, EU harmonisation — typically follows two to three years later. Nothing here changes your obligations today.
Reasonably settled: the content. The draft text is stable, and the direction of travel is clear enough to plan against. That is the useful position: plan, do not panic.
The four changes that matter
1. Three safety classes become two process levels. Classes A, B and C are replaced by two levels. Level I corresponds broadly to the old Class A; Level II absorbs both B and C.
This is the change with the most practical bite, and it is easy to read the wrong way. Fewer categories sounds like simplification — but for software currently classified B, the lighter middle tier disappears. Work that sat comfortably below Class C rigour moves up to the same process level. If your product is Class B today, this is the paragraph to reread.
2. Scope widens from device software to health software. Edition 2 extends beyond strictly regulated medical device software toward the broader category of health software, aligning with IEC 82304-1. Clinical and health applications that do not meet a device definition today can fall inside the standard’s boundary.
3. AI and machine learning get their own lifecycle. The draft introduces provisions for AI/ML development, including a defined development lifecycle for it. If you are adding AI features to clinical software, this is the first time the standard speaks to that directly rather than by analogy.
4. “Harm” is broadened to align with ISO 14971. The term now covers damage to property and the environment, not only harm to patients and operators. A small wording change that quietly widens what your risk analysis has to consider.
What is worth doing before publication
Most of the honest answer is unglamorous, and most of it you would want regardless of any standard.
- Re-examine your classification. If anything you own is Class B, model what Level II rigour would mean for it. That is the single largest potential cost, and it is knowable now.
- Check what falls in scope. Companion apps, portals, and clinical tools that sit outside the device boundary today may not stay outside it. Inventory them.
- Write the AI lifecycle down. If clinical software uses AI, document how models are trained, validated, versioned, and monitored. You will need this regardless of which standard demands it.
- Do not rewrite your QMS yet. The text is stable, not final. Restructuring documentation against a draft is work you may do twice.
The uncomfortable, useful part
Read the four changes again and notice something: none of them asks for anything a careful team would not already want. Traceable classification. Knowing which software is in scope. Documented AI validation. Risk analysis that considers real consequences.
That has been our experience building for regulated clients. MedLabel enforces required data fields per label type so a non-compliant UDI label cannot be produced. MedERP puts batch, lot and serial tracking in every transaction rather than in a report bolted on top. MedCatalog has been in production for close to a decade — long enough for several regulatory shifts to pass through it. In each case, the practices that made regulatory life easier were practices that made the software better first.
So the practical reading of Edition 2 is not “a new burden arrives in 2027.” It is: the gap between good engineering and compliant engineering is narrowing, and the middle tier where you could do less is being removed. Teams already building carefully will find the transition small. Teams relying on Class B to avoid rigour will find it is not.
We are a software partner, not a regulatory consultancy — your notified body and quality team own the compliance call. What we can do is build medical technology software to a standard that survives it, with QA and testing discipline built into delivery rather than added at the end.
If you are mapping what Edition 2 means for a product you own, we are happy to think it through with you.