EU MDR Class IIa software: what founders need to know

Rule 11 classifies software by what its output is used for. Software intended to provide information used to take diagnostic or therapeutic decisions is Class IIa by default — rising to IIb where such a decision could cause serious deterioration in a person’s state of health or require surgical intervention, and to III where it could cause death or an irreversible deterioration. Software intended to monitor physiological processes follows the same logic: IIa in general, IIb where the monitored parameters are vital and their variation could put the patient in immediate danger. Everything that falls outside these descriptions defaults to Class I.

The practical effect, well documented since Rule 11 took effect, is that a large amount of software which would have been self-declared Class I under the old Medical Devices Directive is now IIa under MDR. Founders building on assumptions inherited from an earlier regulatory era, or from a US-only mental model, are the ones most often caught by this — the EU threshold for "needs a notified body" is simply lower than intuition suggests.

Below Class IIa, a manufacturer can self-declare conformity. At Class IIa and above, a notified body has to assess both your technical documentation and your quality management system as part of conformity assessment — meaning an actual audit, not a paper review. That audit examines whether your QMS, typically built to ISO 13485, has genuinely operated: whether design controls produced real records, whether internal audits and management reviews actually happened on the cycle your procedures describe, and whether the risk management file under ISO 14971 reflects decisions made during development rather than a narrative written afterward.

The technical documentation itself, structured per MDR Annexes II and III, has to demonstrate conformity with the General Safety and Performance Requirements in Annex I, supported by a clinical evaluation appropriate to the claims made. For software, that evaluation increasingly draws on the IMDRF three-part model — that the output relates to the clinical condition, that the software computes it correctly, and that using it produces the intended clinical result — even though MDR does not cite IMDRF guidance directly.

It is easy to read "Class I to Class IIa" as one step up a ladder. In practice it is the difference between self-declaring and needing an external, resourced, audited quality system — which is a different company operationally, not just a different form filed. Teams that budget for Class IIa as a modest increment on Class I consistently underestimate both the calendar time (see the companion piece on notified body timelines) and the organisational discipline a genuine QMS requires from a small engineering team that has never operated one before.

A detail that catches founders specifically: post-market surveillance, post-market clinical follow-up, and vigilance plans are reviewed as part of conformity assessment itself — before the product has shipped and before there is any real-world data to plan around. Treating these as a "later" problem, to be written once the product is live, means arriving at audit with a gap the notified body will find immediately. They need to exist, credibly, at the point of certification.

Confirming Class IIa applies — rather than assuming it, or hoping a wellness framing avoids it — is exactly the qualification and classification work in our guide to SaMD risk classification, and building the QMS and evidence base that a Class IIa audit expects is the core of our SaMD regulatory strategy advisory.