Is your software a medical device? MDR Rule 11 explained

Start with qualification, not classification

Classification is the second step. Before Rule 11 is relevant at all, you have to establish that the software is a medical device, and that turns entirely on intended purpose. Under Article 2 of the MDR, intended purpose is the use for which the device is intended according to the data supplied by the manufacturer on the label, in the instructions for use, and in promotional or sales material, as well as what is specified in the clinical evaluation. That last part catches people out: your marketing copy is part of your intended purpose, whether you meant it to be or not.

A product is a medical device when it is intended for one or more specific medical purposes: diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease, among others. The current guidance is MDCG 2019-11, revised to Rev. 1 in June 2025. If you are working from the original 2019 document, you are working from a superseded version. Rev. 1 tightened several points, including guidance on writing a clear intended purpose, more material on modular software, and clarification that software which processes health information falls in scope only where that processing directly serves a medical purpose.

The practical test is not what your software technically does, it is what you claim it is for. A tool that stores and displays results is in a very different position from the same tool marketed as detecting a condition. Write the intended purpose first, deliberately, and treat it as a regulatory artefact rather than a marketing afterthought.

What Rule 11 actually says

Rule 11 reads: software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa, except if such decisions have an impact that may cause death or an irreversible deterioration of a person's state of health, in which case it is in class III, or a serious deterioration of a person's state of health or a surgical intervention, in which case it is class IIb. Software intended to monitor physiological processes is classified as class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is class IIb. All other software is classified as class I.

MDCG splits that text into three sub-rules, and using their labels makes the analysis much easier to document. Sub-rule 11a is the decision limb. Sub-rule 11b is the monitoring limb. Sub-rule 11c is everything else.

Sub-rule 11a: the decision limb, and why it catches almost everything

Sub-rule 11a covers software intended to provide information used to take decisions with diagnostic or therapeutic purposes, and its default outcome is class IIa. The reason it catches so much is stated plainly in the guidance itself: that wording describes, in very general terms, the mode of action that is characteristic of all medical device software. MDCG therefore treats sub-rule 11a as generally applicable to all medical device software, excluding only software that has no medical purpose at all.

That is the single most important sentence in this whole area. It means the starting assumption for clinical software is class IIa, and the burden is on you to explain why your product sits lower, not on anyone else to explain why it sits higher.

The two exceptions escalate from there, and the qualifier matters enormously. The guidance frames it in terms of decisions which, if based on incorrect information from the software, are reasonably likely to have an impact that may cause death or irreversible deterioration, which is class III, or serious deterioration or a surgical intervention, which is class IIb. That phrase, reasonably likely, is often missed. Rule 11 is frequently criticised for reading as pure worst case severity, since almost any clinical software could contribute to a catastrophic outcome in some imaginable chain of events. The guidance moderates that by asking what is reasonably likely, not what is conceivable.

The international framework helps structure the argument. IMDRF's SaMD risk categorisation, which Rule 11 was written to mirror, turns on two factors: the significance of the information the software provides to the healthcare decision, and the state of the healthcare situation or patient condition. Setting your rationale out along those two axes is far more persuasive to a Notified Body than an unsupported assertion.

One common line of argument deserves a warning. Teams often reason that because a clinician always reviews the output and exercises independent judgment, the software is not really used to take a decision. That framing is weak on its own. What matters is whether the software is intended to provide information used to take the decision, and what would reasonably follow if that information were wrong. Human oversight is a risk control, and it belongs in your risk management file, but on its own it is unlikely to move you down a class.

Sub-rule 11b: monitoring physiological processes

Software intended to monitor physiological processes is class IIa. It moves to class IIb only where both conditions of the exception are met: the parameters being monitored are vital physiological parameters, and the nature of variations in those parameters is such that they could result in immediate danger to the patient.

Both limbs are needed. Monitoring something continuous and physiological is not enough on its own; the question is whether a variation could put the patient in immediate danger. Cardiac and respiratory parameters in an acute setting are the obvious candidates. Trend monitoring of a parameter that changes slowly, and where a missed change would be noticed and acted on long before harm occurred, sits differently.

Note also that a product can engage both limbs. Software that monitors a parameter and also generates a recommendation for treatment is doing two things, and implementing rule 3.5 means the strictest applicable sub-rule sets the class.

Sub-rule 11c, and the near disappearance of class I software

Sub-rule 11c says all other software is class I. In practice, very little clinical software lands there, precisely because sub-rule 11a is drafted so broadly. This is the software version of the wider class I squeeze under MDR, and it is the single biggest commercial surprise for software manufacturers moving from the old directives, where a great deal of this software sat comfortably in class I and could be self certified.

What still plausibly sits in class I is software that genuinely does not provide information used for a diagnostic or therapeutic decision and does not monitor physiological processes. Simple administrative, storage, communication or display functions are the usual examples, along with software whose purpose is not medical at all, which fails qualification and never reaches Rule 11.

The consequence is not academic. Class IIa is the point at which a Notified Body becomes mandatory, which brings certification cost, audit scope and, most acutely, queueing for capacity. If your plan assumes class I, that assumption deserves testing early and in writing, because discovering otherwise late is what wrecks timelines.

Software inside a device: SaMD, SiMD, and the implementing rules

The MDR deliberately dropped the old term standalone software. Software is qualified and classified on its intended purpose, regardless of where it physically runs, whether that is a phone, a server, the cloud, or embedded in an instrument. Location does not change the analysis; purpose does.

Three implementing rules in Annex VIII do the work here. Software independent of any other device is classified in its own right. Software that both achieves its own intended purpose and drives or influences the use of a hardware device is classified on its own, based on the purpose it achieves, but its class may not be lower than the class of that hardware device, under implementing rule 3.3. And where several rules, or several sub-rules within one rule, apply to the same device, implementing rule 3.5 means the strictest applies.

The practical upshot for anyone building an algorithm that ships inside someone else's hardware: embedding does not let you inherit a convenient lower class. It sets a floor, not a ceiling. Rule 11 still applies to what your software is for, and if Rule 11 gives a higher class than the hardware, the higher class wins.

Four worked examples

These are illustrative only, to show how the analysis runs. They are not advice, and a real classification depends on the exact intended purpose, the claims made, and the clinical context.

First, an imaging tool that measures a lesion and outputs a dimension a radiologist uses when diagnosing. It provides information used to take a diagnostic decision, so sub-rule 11a applies and the baseline is class IIa. If an incorrect measurement is reasonably likely to lead to a decision causing death or irreversible deterioration, for example by contributing to a missed malignancy, class III comes into view.

Second, the example MDCG uses in its own guidance: melanoma image analysis software intended for use with a near-infrared laser scanner, where the software takes control of the scanner and runs proprietary exposure programmes. The scanner itself is class IIa under Rule 10. Because the software drives that hardware, implementing rule 3.3 engages, but Rule 11 also applies on the software's own intended purpose, which is cancer diagnosis. Applying implementing rule 3.5, MDCG puts this at class III.

Third, software that continuously monitors cardiac and respiratory parameters in an acute care setting and raises alerts. This is the monitoring limb, sub-rule 11b. The parameters are vital ones and variation could place the patient in immediate danger, so the exception applies and the result is class IIb.

Fourth, a consumer fitness app that records steps and resting heart rate for general wellbeing, with no medical claim. It has no medical purpose, so it fails qualification and Rule 11 is never reached. Change one sentence of the marketing so that it detects a possible arrhythmia, and it becomes a medical device, sub-rule 11a applies, and it starts at class IIa or higher. The engineering did not change. The claim did.

What the December 2025 reform proposal would change

On 16 December 2025 the European Commission published COM(2025) 1023, a proposal to amend both the MDR and the IVDR. It is the most substantial reopening of the framework since the MDR replaced the directives, and it explicitly addresses the software classification problem. The proposed amendment to Rule 11 would make classification more genuinely risk-based and closer to international consensus, with the practical effect that a broader range of software could sit in class I and avoid mandatory Notified Body involvement.

It is important to be precise about status. This is a proposal, not law. It sits at the beginning of the ordinary legislative procedure, it requires agreement from both the European Parliament and the Council, and it is likely to be amended significantly along the way. A revised regulation is realistically a 2027 prospect at the earliest, and that timeline is optimistic.

So the planning advice is straightforward. Classify against Rule 11 as it stands today, because that is the law you will be assessed against. Follow the reform, and factor it into longer term roadmap thinking, but do not build a market access plan on a proposal that has not been through Parliament.

What to do now

Classification is not a box to tick once. It is a decision you have to be able to defend, and it drives nearly everything downstream: whether you need a Notified Body, how heavy your technical documentation is, and how much rigour your software lifecycle needs under IEC 62304 and your quality system under ISO 13485.

The most useful thing most teams can do is write the intended purpose properly and early, then write the classification rationale against the specific sub-rule, in a document someone else could follow. Revisit it whenever the claim, the feature set, or the target population changes, because any of those can move the class.

• Write a precise intended purpose, and align the marketing copy with it
• Confirm qualification before arguing about class
• Name the sub-rule you are relying on, 11a, 11b or 11c, and justify it
• Apply implementing rules 3.3 and 3.5 where software touches hardware
• If the answer is class IIa or above, approach a Notified Body early, because capacity is the constraint
• Re-run the analysis on every material change to claims, features or intended users