IEC 62304 Edition 2: What Changes for SaMD and Medical Device Software Teams

IEC 62304 has been the foundational standard for medical device software development since its first edition. The second edition is now in active development by IEC SC62A. This article draws exclusively from the official IEC SC62A Design Specification and the MT49 Change Rationales. Both are early working documents issued ahead of a Committee Draft Vote (CDV), so the points below are proposed and subject to change. 

Two Process Rigor Levels Replace Three Safety Classes 

The most significant structural change is the replacement of the three software safety classes (A, B, and C) with two software process rigor levels. 

1. Rigor Level I replaces Class A.
2. Rigor Level II replaces both Class B and Class C. 

Level II applies by default until a rigor level is formally assigned. A manufacturer may assign Level I only if the product level risk management process determines the software cannot contribute to a hazardous situation. Software that implements a risk control measure is Level II regardless of any mitigations applied during development. 

The Change Rationales explain that Class B and Class C are no longer differentiated, aligning IEC 62304 more closely with IEC 81001-5-1. The concept of “unacceptable risk” is removed from classification. The standard instead asks whether harm can result from a software failure, using worst-case scenarios and excluding only risks that are “very unlikely” or whose harm is “negligible.” Where external risk control measures lower a rigor level, their effectiveness must be verified. The team also moved from the ISO 14971 term “hazardous situation” toward the broader concept of “harm” to suit the wider health software audience. 

Scope Expands to All Health Software 

Edition 2 broadens scope beyond medical device software. Using the ISO 81001-1 definition, health software covers software intended for managing, maintaining, or improving the health of individuals, the delivery of care, or software developed for incorporation into a medical device. The requirements apply whether the product is software only or interacts with specific hardware to achieve its health purpose. 

Quality and Risk Management Clauses Modified 

Because IEC 62304 is not a product standard, the Clause 4.1 quality management requirement is removed and left to the product or system level. Clause 4.2 is modified to remove the requirement for a specific risk management process, retaining a note that ISO 14971 is expected for medical software. Software level clauses now focus on the information developers must provide to support the product level risk management process. 

AI Planning Becomes a Formal Requirement 

Edition 2 introduces Clause 5.1.15 on AI planning, applying to software incorporating decision trees, machine learning, deep learning, reinforcement learning, and large language models. It defines an AI Development Lifecycle, integrated within the software development lifecycle, covering planning and design, data engineering, model building, verification and validation, deployment, maintenance, and decommission. Monitoring must begin early, and the rationale stresses that manual checks alone are not sufficient for post-market monitoring of AI performance against drift and degradation. 

Other Notable Changes 

1. Software architecture design now applies to all rigor levels, not only the former Class B and C.
2. Static code analysis becomes a formal requirement for Level II under new Clause 5.5.6.
3. New planning sub-clauses cover software release planning (5.1.13) and software maintenance planning (5.1.14) for all rigor levels, plus a communication plan under 5.1.16.
4. The term “detailed” is removed from “detailed design,” resolving long standing confusion over what that level of detail required.
5. The maintenance process (Clause 6) clarifies that maintenance excludes new features and draws on the 2022 revision of ISO/IEC 14764.
6. The legacy software clause moves from normative text to an informative annex, converting requirements to guidance; existing Edition 1.1 software can address rigor levels by updating the software development plan to reflect prior work. 

What This Means for SaMD Teams 

In practice, software previously treated as Class B will sit at Level II alongside former Class C, so teams should map current classifications to the new levels, build AI planning into their development plans, and treat architecture and cybersecurity considerations as applicable across rigor levels. Because the documents remain pre CDV, these steps are best treated as preparation rather than firm compliance targets. 

How NexorTest Can Help 

Preparing for a major standard revision is easier with a partner that works across the full product lifecycle. NexorTest supports medical device and SaMD teams with software lifecycle and cybersecurity testing, safety and reliability testing, and design and development input from concept through verification. The team also provides global certification and regulatory support, including CE, USFDA, EU MDR, EU IVDR, UKCA, and BIS, helping manufacturers align their software processes, AI planning, and cybersecurity work as Edition 2 takes shape. 

To discuss readiness for IEC 62304 Edition 2, visit NexorTest