IEC 62304 Edition 2, and is your QMS ready for software and AI evidence

IEC 62304 has been the core software life cycle standard for medical device software since 2006, with Amendment 1 added in 2015. The current text applies to the development and maintenance of medical device software where the software is itself a medical device, or where it is embedded in, or integral to, the final medical device.

That makes IEC 62304 a software life cycle standard sitting inside a wider regulated system. It provides structure to software planning, requirements, architecture, design, implementation, verification, release, maintenance, configuration management, and problem resolution. It does not replace the product risk file, the QMS, the technical documentation, the clinical evidence, or the system-level validation work.

Quality management systems that cannot manage software evidence efficiently, or integrate AI systems and their development lifecycle into controlled processes, may soon become unfit for modern regulated software development.

Scope moves toward health software

Edition 2 is expected to move toward a wider health software scope. That brings more attention to software-only health applications, clinical decision support tools, SaMD, software that is part of a device, embedded software, health workflow software, and AI or ML-powered health software.

This matters for companies that have historically described themselves as digital health businesses rather than medical device manufacturers. A remote monitoring platform, a patient portal, a clinical dashboard, a decision support module, or an AI-enabled health function still needs a disciplined software life cycle if it supports care delivery or makes claims that bring it close to regulated use.

Classification moves from Classes A, B, and C to Levels I and II

The current edition uses three software safety classes. The manufacturer assigns each software system to Class A, B, or C according to the risk of harm resulting from a hazardous situation to which the software system can contribute in a worst-case scenario.

• Class A applies where the software system cannot contribute to a hazardous situation, or where the resulting risk is acceptable after external risk controls are considered.
• Class B applies where the possible harm is non-serious injury.
• Class C applies where the possible harm is death or serious injury.

Edition 2 is expected to replace those three classes with two software process rigor levels. Level I broadly corresponds to current Class A. Level II covers what were previously Class B and Class C. That is a simplification, and manufacturers should not read it as a lower bar. Software that can contribute to harm, implements a risk control, drives therapy, supports diagnosis, performs a clinical calculation, filters clinically relevant data, or generates safety-related information should be expected to need Level II evidence.

Risk management remains the anchor

Amendment 1 already ties software classification to hazardous situations, risk controls, and harm. Edition 2 is expected to keep software classification close to product or system-level risk management. That is a good direction, because many software files still show weak links between software requirements and the product risk file.

A requirement may exist. A test may exist. A risk control may exist somewhere else. The problem appears when no one can show how those records belong together. Classification, risk controls, architecture, verification, anomalies, changes, and release decisions need to point back to the same controlled risk argument.

AI becomes part of the software life cycle

The 2015 amendment contains no AI-specific requirements. Edition 2 is expected to introduce an AI development lifecycle for software incorporating AI or machine learning, covering planning and documentation for data collection, training, validation, deployment, and monitoring.

This is where conventional IEC 62304 files are often too thin. AI adds records that organizations still manage informally: dataset selection, data provenance, model training, tuning, validation, model versioning, performance monitoring, drift, retraining, and decommissioning. If an AI model affects intended use, diagnosis, treatment, prioritization, monitoring, or risk control, the model evidence needs to connect to the software development plan, product risk management, verification, validation, change control, and post-market monitoring.

Maintenance needs to be planned earlier

Amendment 1 already makes clear that software maintenance should be planned, and that modifications should use the software development process or an established software maintenance process. Edition 2 is expected to distinguish development from maintenance more clearly. New software and significant changes follow development logic. Routine updates and urgent fixes for software already on the market follow maintenance logic.