IMDRF publishes international reference documents on AI/ML Software as a Medical Device. They are not EU law. In the EU, your legal anchor remains Regulation (EU) 2017/745. Specifically Article 51 and Annex VIII Rule 11. IMDRF outputs are useful as state-of-the-art evidence and structuring aids, nothing more.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • IMDRF is an international harmonisation forum. Its AI/ML SaMD documents are informational, not binding in the EU.
  • The legal anchor for SaMD classification in the EU is Annex VIII Rule 11 of the MDR, referenced through Article 51.
  • MDCG 2019-11 Rev.1 is the EU interpretive guide for software classification. It references international work but does not cede authority.
  • IMDRF framing (significance of information, state of healthcare situation) can help you structure intended purpose and risk argumentation. But does not replace a Rule 11 determination.
  • Treat IMDRF outputs as state-of-the-art evidence under Annex I, not as an alternative regulatory pathway.
  • Founders who cite IMDRF as if it were law lose credibility in notified body audits.

Why this matters

Every few months an AI/ML founder walks into a review meeting waving a printed IMDRF document and says: "Here is the framework we followed." The instinct is good. IMDRF work is serious, globally coordinated, and written by regulators. The problem is jurisdictional. IMDRF documents describe shared vocabulary and principles. They do not place devices on the EU market. Regulation (EU) 2017/745 does.

We have seen startups spend weeks tuning their technical file to IMDRF categories only to discover during stage 2 audit that the notified body wanted a clean Annex VIII Rule 11 justification with MDCG 2019-11 Rev.1 as the interpretive reference. The IMDRF work was not wrong. It was just in the wrong slot of the file.

This post untangles what IMDRF actually publishes on AI/ML SaMD, where it carries weight in an EU technical file, and where it does not.

What MDR actually says

The MDR does not mention IMDRF. It does not mention "SaMD" as a defined legal term either. What it does define is the broader category of software as a medical device through the qualification and classification machinery of Article 2, Article 51, and Annex VIII.

Article 51. Classification of devices. Devices are divided into classes I, IIa, IIb and III based on the rules in Annex VIII. Manufacturers apply these rules based on intended purpose.

Annex VIII Rule 11. This is the rule most AI/ML SaMD devices fall under. In short: - Software intended to provide information used to take decisions with diagnostic or therapeutic purposes is class IIa. - It is class IIb if such decisions may cause serious deterioration of a person's state of health or a surgical intervention. - It is class III if the decisions may cause death or an irreversible deterioration. - Software intended to monitor physiological processes is class IIa, or class IIb if monitoring vital parameters where variations could result in immediate danger. - All other software is class I.

Annex I General Safety and Performance Requirements. GSPR 17 (electronic programmable systems, including software) demands lifecycle controls, risk management, verification and validation. GSPR 1–9 demand that risks be reduced as far as possible taking the "generally acknowledged state of the art" into account.

That state-of-the-art anchor is where IMDRF documents earn their legitimate place in the file. As one input into what competent practice looks like globally for AI/ML in medical software.

MDCG 2019-11 Rev.1 (October 2019, Rev.1 June 2025) is the Medical Device Coordination Group's guidance on software qualification and classification under Rule 11. It is the document a notified body will open when they want to see whether your classification logic holds. IMDRF work is referenced in the broader literature, but MDCG 2019-11 Rev.1 is what governs the EU interpretation.

A worked example

A three-person startup in Vienna is building a retinal image analysis tool that flags suspected diabetic retinopathy for referral. A GP uses it in primary care. The intended purpose: "Software intended to analyse fundus images and provide information to support referral decisions for suspected diabetic retinopathy in adult patients in primary care settings."

The founder arrives with a classification deck built around IMDRF categories: state of healthcare situation ("non-serious"), significance of information ("drives clinical management"). She has classified as "category II" using the IMDRF risk framework and written the technical file around that.

The problem is not the reasoning. The IMDRF logic is sensible. The problem is legal form. In the EU, the classification that matters is:

  • Intended purpose provides information used in a decision with diagnostic purpose. Rule 11 applies.
  • The decision (refer or not refer for suspected diabetic retinopathy) is not one that may cause death or irreversible deterioration in the near term. Missed cases lead to delayed diagnosis, which is serious but not immediate.
  • Under Rule 11 this maps to class IIa unless a case can be made that a wrong output could cause serious deterioration, which would push it to IIb.
  • MDCG 2019-11 Rev.1 examples for diagnostic support software confirm IIa is typical for this use pattern, with IIb required when the decision's consequences are more severe.

We rewrote the classification justification with Rule 11 as the primary reasoning and MDCG 2019-11 Rev.1 as the interpretive support. The IMDRF logic did not disappear. We moved it into a separate section titled "State-of-the-art considerations and international harmonisation context" and referenced it under GSPR 1 as evidence the risk reasoning is consistent with global regulator thinking. The notified body accepted the file at stage 2 without classification findings.

That is the correct placement. IMDRF as context, MDR as decision.

The Subtract to Ship playbook

Here is the practical approach for an AI/ML SaMD startup that wants to use IMDRF work without tripping on jurisdictional confusion.

1. Write your classification on Rule 11 first. Open Annex VIII, read Rule 11 in full, apply it to your intended purpose. One page. No IMDRF at this stage. If you cannot reach a clean class decision from Rule 11 alone, your intended purpose is probably underdefined.

2. Pull in MDCG 2019-11 Rev.1 as your interpretive layer. This is the document notified bodies will check against. Use its examples, its qualification flowchart, and its Rule 11 decision logic. Cite the Rev.1 date so no one assumes you are working from the superseded version.

3. Add IMDRF content where it genuinely fits. Typical slots: - GSPR 1 state-of-the-art evidence. A statement that your risk framing is consistent with international regulator consensus on AI/ML SaMD. - Risk management file under EN ISO 14971:2019+A11:2021. IMDRF categorisations can support your severity and probability reasoning, as long as you are clear they are inputs, not outputs. - Clinical evaluation. IMDRF discussion of "analytical validity, clinical validity, clinical utility" maps cleanly onto how you structure performance evidence. - Post-market plan. IMDRF predetermined change control concepts inform your change management procedures even though EU law treats significant changes under MDR Article 120 and MDCG guidance on significant changes.

4. Never cite IMDRF as a legal authority. No sentence in your file should read "per IMDRF, this device is category X and therefore...". The "therefore" must trace to MDR.

5. Document the mapping. One internal note, one page, explaining which IMDRF documents you considered, where they appear in your file, and why they do not substitute for EU obligations. When a new team member or auditor asks, this note answers the question in 60 seconds.

6. Watch for updates. IMDRF releases new AI/ML work periodically. Re-read MDCG 2019-11 Rev.1 first, then the new IMDRF document, and update only the state-of-the-art section unless MDCG guidance changes.

This is the Subtract to Ship move: use the international work, do not duplicate it, but keep the legal spine of the file EU-native.

Reality Check

  1. Can you state your device's classification in one sentence citing only Annex VIII Rule 11?
  2. Does your classification justification reference MDCG 2019-11 Rev.1 by name and revision date?
  3. If an auditor removed every IMDRF reference from your file, would your classification still hold on MDR text alone?
  4. Where in your file does IMDRF content live. And is each instance labelled as state-of-the-art context rather than legal basis?
  5. Have you read Rule 11 in full (not summaries) in the last three months?
  6. If your intended purpose changed tomorrow, would your Rule 11 determination change with it. And do you have a process to catch that?
  7. Can your regulatory lead explain to a non-regulatory founder in two minutes why IMDRF is not EU law?

If you cannot answer any of these cleanly, the gap is not knowledge. It is structure. Fix the file architecture before the next audit.

Frequently Asked Questions

Is IMDRF guidance legally binding in the EU? No. IMDRF is an international forum for regulator harmonisation. Its documents are reference material. The EU's binding text is Regulation (EU) 2017/745, supported by MDCG guidance.

Can I use IMDRF documents in my technical file at all? Yes. As state-of-the-art evidence, risk reasoning context, and structural inspiration. Just never as the legal basis for a classification or a GSPR conformity claim.

What if IMDRF and MDCG guidance disagree? MDCG wins in the EU. Always. MDCG 2019-11 Rev.1 is the interpretation notified bodies will apply to Rule 11 classification questions.

Does the EU AI Act change this? The AI Act adds obligations for high-risk AI systems, including many medical AI devices, but it does not change MDR classification. Rule 11 still determines your MDR class. The AI Act runs in parallel.

Is there an EU equivalent of the IMDRF SaMD risk categorisation? Not as a legal framework. Rule 11 is the EU classification logic. MDCG 2019-11 Rev.1 is its interpretive companion.

My notified body mentioned IMDRF in a meeting. Does that mean it applies? It means they recognise it as part of the global conversation. It does not mean they will accept it in place of a Rule 11 justification. Ask them directly which document they will audit against. The answer will be MDCG 2019-11 Rev.1.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Article 51, Annex VIII Rule 11, Annex I GSPR 1–9 and 17.
  2. MDCG 2019-11 Rev.1. Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 and Regulation (EU) 2017/746 (October 2019, Rev.1 June 2025).
  3. EN ISO 14971:2019+A11:2021. Medical devices. Application of risk management to medical devices.
  4. EN 62304:2006+A1:2015. Medical device software. Software life cycle processes.