What the classes mean
EU MDR uses four main classes: Class I, Class IIa, Class IIb, and Class III. In general, Class I is the lowest risk and Class III the highest. The higher the class, the more demanding the conformity assessment route tends to be, and the greater the involvement of a Notified Body. But classification is not assigned by business preference. It follows the rules in Annex VIII.
The class affects far more than certification cost. It shapes what level of clinical evidence is expected, how detailed PMS and PMCF activities need to be, and how closely the technical file is reviewed. Misclassification can therefore create serious downstream problems. A device developed under assumptions suitable for one class may turn out to need far more evidence and system maturity than the team planned for.
That is why classification should happen early, be documented clearly, and be reviewed whenever intended purpose, design, software functionality, or user environment changes.
How Annex VIII and the 22 rules work
Annex VIII contains the classification rules. There are 22 of them, covering non-invasive devices, invasive devices, active devices, and special categories. The process is not to skim the list and pick the first rule that seems plausible. Manufacturers need to understand the device’s intended purpose, duration of contact, invasiveness, energy use, interaction with the body, and clinical context before applying the rules systematically.
Some devices are straightforward. Many others are not, especially when software, monitoring functions, or combinations of features are involved. Several rules may appear relevant at first glance, but the classification rationale must explain why a particular rule governs the final result. That rationale should be written down as part of the technical documentation, not left as tribal knowledge inside the regulatory team.
In practice, classification often benefits from a stepwise approach: define intended purpose first, map the key characteristics that affect the rules, test each plausible rule carefully, and record why the final class is justified.
- Start from intended purpose and intended user
- Identify whether the device is non-invasive, invasive, active, implantable, or software
- Apply all relevant Annex VIII rules, not just the most convenient one
- Document the reasoning in a classification rationale that can withstand review
Why Rule 11 changed software classification
Rule 11 is one of the most talked-about parts of Annex VIII because it pushed many software products into higher classes than they would previously have expected. The rule focuses on software that provides information used to make diagnostic or therapeutic decisions, and on software that monitors physiological processes. Depending on the impact of the decision or the severity of the situation, classification can move into Class IIa, IIb, or even Class III.
For software manufacturers, this means functionality matters more than labels. Calling a product a support tool, dashboard, or workflow platform does not in itself determine classification. What matters is what the software actually does, what outputs it provides, and how those outputs influence clinical decisions or patient management.
Teams commonly underestimate Rule 11 when software features expand over time. A product that begins as administrative support can become higher risk if it starts prioritising signals, recommending actions, or presenting information that clinicians rely on in decision-making.
The role of intended purpose in classification
Intended purpose sits at the centre of classification. It defines what the device is meant to do, for whom, and in what context. If intended purpose is vague, overbroad, or internally inconsistent, classification becomes unstable. The same issue then spills into clinical evaluation, labelling, verification plans, and PMS.
Manufacturers sometimes treat intended purpose as a marketing statement and classification as a separate regulatory exercise. Under the MDR, that separation is risky. The claims made in labelling, instructions, websites, and submissions should align with the intended purpose used in classification. If they do not, reviewers may conclude that the rationale is incomplete or misleading.
Strong classification work therefore depends on disciplined claim-setting. Before debating rules, the team should make sure the product description, target user, patient population, and use environment are all stated precisely.
Common classification mistakes manufacturers make
A frequent mistake is beginning with a desired class instead of a documented rationale. Another is failing to revisit classification after product changes. Devices evolve, software gains new modules, and intended uses broaden. If the classification file does not evolve with them, the compliance strategy drifts out of sync with the actual product.
Manufacturers also run into trouble when they rely too heavily on competitor assumptions. Similar products on the market may look like useful benchmarks, but classification depends on intended purpose and detailed functionality, not just outward similarity. Using a competitor’s class as a shortcut can hide key differences that matter under Annex VIII.
The most robust approach is to treat classification as a living decision supported by traceable reasoning. That helps the organisation defend the chosen class during reviews and makes future updates much easier to manage.