Is your software a medical device? The Rule 11 analysis your team needs to do before anything else
Before you write a single line of regulatory documentation, you need to answer one foundational question: does EU MDR apply to your software at all? Getting this wrong — in either direction — is costly.
Rule 11 of MDR Annex VIII classifies software that provides information which is used to take decisions with diagnostic or therapeutic purposes. The classification depends on the severity of that decision and the population affected.
The threshold question: does MDR apply at all?
EU MDR defines a medical device, in part, as software intended to be used for a medical purpose. The word "intended" is key — it refers to the manufacturer's intended purpose as stated in the labelling, instructions for use, and promotional material.
General purpose software — a standard spreadsheet, a generic communication tool, an EHR system used for administrative purposes — does not fall under MDR. But the line becomes unclear when software starts to process patient-specific data to generate outputs used in clinical decisions.
The Rule 11 classification logic
Once MDR scope is established, Rule 11 applies a risk-based classification logic. Software that provides information used to take decisions with diagnostic or therapeutic purposes is classified as Class IIa at minimum, rising to Class IIb or III depending on the potential impact of an incorrect output.
The most common error is treating Rule 11 as a bright-line test. In practice, classification depends on a careful reading of the intended purpose, the clinical context, and the degree to which the software output drives — rather than merely informs — clinical decisions.
The AI/ML complication
AI-enabled software adds another layer. Machine learning models that generate patient-specific outputs are almost always in scope under Rule 11, but the classification depends on what those outputs are used for and how directly they influence clinical decisions.
The practical implication: if your software uses AI to support clinical decisions, you are likely facing a Class IIa or IIb device requiring Notified Body involvement.
What to do first
Before any other regulatory work, produce a written classification rationale. Document the intended purpose precisely, apply the classification rules systematically, and record your reasoning. This document becomes the foundation of your technical file.
If the classification is genuinely ambiguous — and for many AI/ML products it is — the classification rationale is the document you will need to defend your position to a Notified Body.
Sources & references
Official guidance and legislation underpinning this analysis.
Have a classification or compliance question?
I am happy to discuss your device and where you are in the regulatory journey.
Get in touch