MDR Rule 11 in transition: What the planned realignment means for medical software manufacturers
The European Union is planning a fundamental revision of the MDR classification rule for medical software. The draft published on December 16, 2025 promises a clearer, more risk-oriented approach, but does this really mean less effort for manufacturers? And how can companies ensure that their classification decisions remain robust under the new conditions? We answer these questions in our blog post.
Why the EU is putting its classification rule to the test
Since the Medical Device Regulation (MDR) came into force, the pressure on medical device manufacturers has increased noticeably. Long certification procedures, busy notified bodies and a high regulatory burden are hitting small and medium-sized companies particularly hard. The concern that proven products could disappear from the European market due to the stricter requirements is omnipresent in the industry.
Software manufacturers face particular challenges in this regard: Unclear interpretations of the classification rules, constant pressure to adapt due to updates and new features as well as the already tense situation at the certification bodies make MDR compliance a complex undertaking. With the planned revision, the EU Commission does not want to lower safety standards, but rather create a legal framework that enables innovation without jeopardizing the security of supply.
The revision of Rule 11, which defines how medical software is classified, plays a central role in this. This change will have far-reaching practical consequences for anyone who has to develop and regulate software.
From the exception to the rule: the new classification approach
Until now, Rule 11 was often understood in practice to mean that almost all software relating to diagnostic or therapeutic decisions was to be classified as at least Class IIa. Only software with no discernible influence on clinical decision-making had a realistic chance of being classified as Class I.
The new draft reverses this logic: In future, class I is to be the starting point. Only when clearly defined, risk-based criteria are met will the software be upgraded to IIa, IIb or III. Two factors are decisive here: the severity of the clinical situation (non-serious, serious, critical) and the specific role of the software in clinical management (inform, drive, control).
This reorientation shifts the focus away from abstract definitions of purpose such as “software to support…” to the crucial question: What clinical risk actually arises from the use of this software in a specific application scenario?
The trick is in the detail: Is classification really getting easier?
At first glance, the draft appears to be manufacturer-friendly. However, the reality is likely to be more nuanced. Some products will indeed benefit from a simpler classification, particularly software with very limited risk potential or, conversely, clearly highly critical applications from intensive care medicine, for which the classification was already clear anyway.
However, many medical software solutions operate in a gray area: they work in situations in which incorrect or delayed information can have a negative impact on the clinical outcome. Even under the new rule, these use cases will often have to be classified as at least a “non-serious situation” with an impact on clinical management, which typically leads to Class IIa.
Greater clarity therefore arises primarily at the edges of the spectrum. For all borderline cases between “actually Class I” and “rather IIa”, the specific interpretation by authorities, notified bodies and market surveillance will be decisive. Manufacturers will therefore have no choice but to continue to justify their classification decisions in a structured, transparent and comprehensible manner.
What manufacturers need to know now
Even with the planned new regulation, a central insight remains: Class I is not an automatic result, but the starting point of a well-founded argument. Manufacturers must be able to explain the following aspects precisely:
The company must be able to clearly describe the clinical benefits of the software – as well as the specific impact on diagnosis, therapy, monitoring or prognosis. Based on this, a systematic risk analysis is required that transparently shows which hazards may arise for patients. And finally, a comprehensible explanation must be provided as to why a higher risk class is not appropriate.
Even if software can remain in Class I, this does not mean that the basic regulatory obligations no longer apply: Risk management, technical documentation, clinical evaluation and a functioning quality management system are not optional extras, but the necessary basis for any viable classification decision.
Structured governance instead of regulatory patchwork
This is precisely where the difference between reactive compliance management and strategic regulatory governance becomes apparent. Scattered individual documents, Excel lists and fragmented processes may suffice for the moment, but the weak points become apparent during audits or inquiries from notified bodies at the latest.
Consistent, system-supported documentation creates decisive advantages here. Manufacturers need the ability to record the intended purpose, target population, clinical situation and the role of the software in the decision-making process in a structured manner – precisely the information that is also central to the new Rule 11. It should be possible to build the argumentation along the new logic: from Class I as the starting point to the relevant escalation criteria to the justified classification, in each case linked to the underlying assumptions and evidence.
This approach is particularly valuable if risks, measures, tests, clinical data and requirements can be brought together. This makes the justification of the risk class much more robust and manufacturers can respond to inquiries from notified bodies or authorities in a well-founded and swift manner.
Be prepared for change
The medical technology industry is subject to constant change. Regulatory adjustments such as the planned revision of Rule 11 are just one aspect, but there are also product developments, new features, additional indications or extended areas of application. Each of these changes can have an impact on the risk profile and therefore on the classification.
With a structured documentation basis, manufacturers can specifically understand and evaluate the consequences of such changes. Impact analyses should show which areas of the technical documentation, risk management or clinical evaluation are affected by a change.
A practical example: A manufacturer develops an app for the management of a chronic, non-life-threatening disease. The intended purpose, severity of the clinical situation, influence on clinical management, risk controls and test results should be documented in such a way that it is transparent at all times whether classification as Class I remains justifiable or whether Class IIa is the appropriate framework. If a new function is added later, an impact analysis immediately shows whether this extension influences the classification.
Conclusion: clearer rules, lasting responsibility
The planned revision of MDR Rule 11 is a step in the right direction. A more risk-oriented, systematic classification logic can help to create legal certainty and enable innovation. At the same time, it is clear that the responsibility for a well-founded, comprehensible classification decision remains with the manufacturers.
Software used in medical contexts requires structured regulatory governance, regardless of whether it ends up in Class I, IIa or a higher category. With our validated software solution BAYOOSOFT Themis, manufacturers can put this governance on a solid, audit-proof foundation. The platform digitizes and links technical documentation processes, reduces effort and minimizes redundant data – from the intended purpose and risk management to the finished technical documentation in accordance with MDR and IVDR. This means that companies are well equipped for future regulatory developments.
Would you like to put your medical software classification on a reliable basis? Find out more about BAYOOSOFT Themis or test the software free of charge.
