Rule 11 of Annex VIII of the MDR is the classification rule that has shaken digital health the most. Under Directive 93/42/EEC, the majority of medical software fell under class I, self-certified, with no notified body. Under the MDR, most decision-support software is at least class IIa. Changing class is not a documentary adjustment: it brings a notified body into the developer’s life.
What Rule 11 says exactly
The text sets out a three-step logic that must be read in order.
First step: class IIa by default. Software intended to provide information used to take decisions with diagnostic or therapeutic purposes falls under class IIa. This is the starting point, not the exception. Any clinical decision-support software enters scope through this door.
Second step: two exceptions upward. If the decisions the software informs may cause death or an irreversible deterioration of a person’s state of health, the software falls under class III. If they may cause a serious deterioration of a person’s state of health or a surgical intervention, it falls under class IIb. Surgical intervention is a criterion in its own right: software whose error may lead to operating, or to operating badly, is IIb even without a direct threat to life. These same serious consequences that raise the class are also those that, once the software is on the market, trigger the vigilance obligations and reporting deadlines.
Third step: monitoring. Software intended to monitor physiological processes falls under class IIa. It moves to class IIb only if it monitors vital physiological parameters where the nature of variations could result in immediate danger to the patient. The two conditions are cumulative: vital parameter, and immediate danger in case of variation. Software tracking heart rate in intensive care ticks both boxes. An app tracking the same heart rate for wellness monitoring ticks neither, and is probably not even a medical device.
All other software falls under class I. In practice, this category has become narrow: the 2025 revision of the guidance gives one example, under strict conditions.
An implementing rule completes the framework: software that drives a device or influences its use falls into the same class as that device (Annex VIII, rule 3.3). Rule 11 applies to software classified in its own right.
Why the reclassification was so wide
Under the directive, the central criterion was the software’s place within a physical device. The MDR shifts the criterion toward the clinical impact of an error in the software itself. Software that suggests a differential diagnosis starts as IIa, rises to IIb or III depending on the consequences of an erroneous suggestion. Radiotherapy planning software ends up as IIb or III: a dosimetry error can cause irreversible deterioration. Automatic ECG interpretation software rises to IIb as soon as its outputs steer a decision with serious consequences.
Moving from class I to IIa or IIb changes the nature of the exercise: a complete technical file, substantial clinical evaluation, a software life cycle in accordance with IEC 62304, a PMS and PMCF plan, and assessment by a notified body. The developer who moves up in class discovers ISO 13485 at the same time and must audit their ISO 13485 QMS. Their software, now classified as a medical device, is also subject to unique device identification and EUDAMED registration, including in digital distribution. The developer is not filling in more forms. They are changing regulatory profession.
MDCG 2019-11 Rev.1: the June 2025 revision reshuffles the deck
The reference guidance on the qualification and classification of software, MDCG 2019-11, was revised on 17 June 2025. This is not a cosmetic update. Four contributions concern developers directly.
The end of “standalone software.” The revision abandons the notion of standalone software in favour of a function-based approach: what matters is the intended purpose of each functionality, not the medium that hosts it. The European term is MDSW (Medical Device Software). SaMD remains the IMDRF vocabulary used across the Atlantic, but a European file that reasons in MDSW terms speaks the language of its assessor.
The modular approach. Software can be broken down into modules, some with a medical purpose, others without. Each medical module must have a defined and documented intended purpose, and the developer must demonstrate that the non-medical modules compromise neither the safety nor the performance of the medical modules. The boundary is drawn in writing, in the technical documentation.
The appearance of the term MDAI. The revision names, for the first time, medical device software with artificial intelligence (Medical Device AI), a subset of MDSW simultaneously subject to the AI Regulation. Developers of learning algorithms now have two texts to cross-reference, not one.
Intended purpose as the cornerstone. The revision hammers home the requirement for a precise, unambiguous intended purpose, aligned with the validation data and the developer’s public claims, including website and app store listings. A classification is built on this written intended purpose. A vague intended purpose produces an indefensible classification.
The guidance also distinguishes software that creates or modifies medical information from software that merely displays or stores it. An algorithm that processes data to derive a clinical result is in the first category. A portal that displays laboratory results without processing them is in the second, and the first question to ask it is one of qualification, before that of class.
What this means for a developer in 2026
A developer who classified their software before June 2025 built their reasoning on the 2019 version of the guidance. That version has been superseded. The assumptions about module qualification, borderline cases, prevention software: all points that Rev.1 decides differently or more finely. A class I classification decided in 2022 deserves a re-read with the 2025 text on the table, especially if the software incorporates decision-support functions added over successive versions.
The scenario that costs dearly is always the same: software classified as class I at launch, enriched feature by feature, whose actual intended purpose has drifted toward decision support without the classification following. The day a notified body or a competent authority raises the question, the answer is built under pressure, with a version history working against you.
Re-reading your classification with Rev.1 costs a structured half-day. Discovering it obsolete in an audit costs a rework under constraint. The right time to have your software classification re-verified is the one you choose, not the one an auditor imposes on you.
Regulatory sources: