Proposal for MDR/IVDR changes and Rule 11 - software classification
By Mitch on Friday, 19 December 2025, 13:47 - Regulations - Permalink
Lots of fuzz and buzz on the proposal for MDR/IVDR changes published on the 16th December 2025.
First, keep in mind this is a proposal.
Second, keep calm and wait for the version amended and voted by the European Parliament.
This doesn't prevent us to make a analysis of changes. Lots of consultants, hungry of new regulations, already did their homework! Let's add in this blog an additional voice to all the other ones already expressed!
New Rule 11 proposal
Let’s take our favourite subject: Rule 11. And cut it in swallowable chunks (gulp).
Confers a clinical benefit
Software which is intended to generate an output that confers a clinical benefit
Do you often use the word confer? I don't. The Merriam Webster dictionary, contains the following two definitions of the word confer:
- to bestow from or as if from a position of superiority
- to give (something, such as a property or characteristic) to someone or something
We assume that the first meaning isn’t applicable in our context. Thus, we may rephrase the first sentence of the newly drafted rule 11 as: Software which is intended to generate an output that gives a clinical benefit (to the patient).
The wording: confers a clinical benefit (or gives a clinical benefit) is puzzling. What does it mean: does it include direct benefit only or does it also include indirect benefit? This is a recurring subject for SaMD, discussed by people in charge of clinical evaluation.
Needless to say, this new rule 11 doesn’t simplify the debate.
Remark: a software, which doesn’t confer a clinical benefit, may be an accessory to a medical device, or a software driving or influencing a medical device, with technical performance only. The fate of accessories may be easier to determine with this new rule.
And is used for…
And is used for diagnosis, treatment, prevention, monitoring, prediction, prognosis, compensation or alleviation of a disease or condition
We retrieve here the first two bullets in the list of medical purposes of the medical device definition: diagnosis, treatment, prevention, etc. This covers the vast majority of software qualified as medical device, per the medical device definition.
But what about the other bullets of the medical device definition: investigation, replacement or modification of the anatomy, etc? They don’t fall into this rule? Where do they go to? Rule 1?
Class I by default
is classified as class I, unless the output is intended for a disease or condition
OK,if we have such software (I fact, almost any MD software is used for diagnosis, treatment and so on), it is class I by default, unless…
A big unless.
Unless, my dear Watson
Let’s continue with the sentences after unless. They are based on the wording of the IMDRF SaMD risk categorisation framework. We can try to fill in the SaMD Risk in the table 7.2 of this IMDRF document, also present (and tweaked) in the Annex III of the MDCG 2019-11 rev.1.
in which case it is classified as class III:
in a critical situation with a risk of causing death or an irreversible deterioration of a person's state of health;
Since, we don’t have more information about this critical situation (severity), all cases of significance of information are included. We obtain this:

in which cases it is classified as class IIb;
in a serious situation with a risk of causing a serious deterioration of a person's state of health or a surgical intervention,
Likewise, we don’t have more information about this serious situation (severity), all cases are included. We obtain this:

or to drive clinical management in a critical situation
Here, we have information about the critical situation (severity), with the expression “drive clinical management” (which confers (L.O.L.) a kind of probability). We can spot a single cell:

in which cases it is classified as class IIa
in a non-serious situation,
Likewise, we don’t have more information about this non-serious situation (severity), all cases are included. We obtain this:

And the last one:
or to drive clinical management in a serious situation or to inform clinical management in a critical or serious situation
We can spot three cells in the table:

All together
Merging all the cases in a single table, we obtain:

Comment 1
I don’t know if this clarifies something to you. For me, it doesn’t clarify anything.
Comment 2
As soon as we have software used for diagnosis, treatment and so on, which brings a clinical benefit, direct or indirect, we have software in class IIa or higher.
The cases after unless cover almost every case found in patient condition or clinical management:
- For patient condition, is there something below non-serious patient condition?
- Negligible patient condition? (Funny patient condition? Interesting patient condition? I digress),
- More seriously, If the intended use of the software is for screening, could we say there is no patient (no one is supposed to be sick), so there is no patient condition? Thus, we are in class I?
- For clinical management, is there something beyond Inform clinical management.
- Record clinical management? Communicate clinical management? That would place our software outside the MD definition.
- Support clinical management? Facilitate clinical management? This sounds stronger than inform. (Whisper clinical management? I digress too much).
Comment 3
As long as we don't have a rule, which follows one by one the cases of the IMDRF table, we are locked in class IIa.
Yet it's so easy to follow the cases in the classification table.
Here is the transcript:
Software which is intended to be is used for diagnosis, treatment, prevention, monitoring, prediction, prognosis, compensation or alleviation of a disease or condition:
is classified as class I, if the output is intended to drive clinical management in a non-serious situation or to inform clinical management in a serious or non-serious situation,
is classified as class IIa, if the output is intended to treat or diagnose in a non-serious situation or to drive clinical management in a serious situation or to inform clinical management in a critical situation,
is classified as class IIb, if the output is intended to treat or diagnose in a serious situation or to drive clinical management in a critical situation,
is classified as class III, if the output is intended to treat or diagnose in a critical situation,
in all other cases, it is classified as class I.
It's as simple as pie. But what were they thinking when they wrote this proposal? Why beating around the bush like this?
Conclusion
This new proposal is definitely not a game changer. It is definitely a missed opportunity of simplification and of more reasonable classification for low-risk software.
Rule 11 rules.
I’m rule 11, I eat MD software. What do you expect me to eat?
