·

AI-sikkerhed i sundhedsvæsenet

Sundhedsvæsen

Sundhed IT / CIO

Why AI clinical decision support needs MDR Class IIa

MDR Class IIa certification ensures AI clinical decision support tools are validated, monitored, and safe. Learn why this regulatory standard matters for healthcare organisations

Regulatory classification of AI tools in clinical care is not a paperwork exercise. When software influences whether a clinician prescribes a particular drug, refers a patient to a specialist, or rules out a serious diagnosis, the consequences of a failure are clinical, not administrative. Across the European Union, the Medical Device Regulation (MDR) establishes the legal framework that determines how such tools must be developed, validated, and monitored before they reach a clinical setting. For AI clinical decision support, that framework typically points to Class IIa certification, a designation that carries specific, auditable obligations.

What the MDR classification hierarchy actually means

The EU MDR (Regulation 2017/745) organises medical devices into four risk classes: Class I (lowest risk), Class IIa (medium risk), Class IIb (medium-high risk), and Class III (highest risk). Classification is not determined by the technology itself. It is determined by the device's intended purpose and the potential harm that could result from its failure or misuse.

Class I devices, such as non-sterile bandages or simple measuring instruments, can be placed on the market through a manufacturer's self-declaration of conformity. No independent third-party review is required. Class IIa sits at the first threshold where that self-declaration is no longer sufficient: an independent Notified Body must be involved in the conformity assessment process. As TrustedTrace Med explains in their Rule 11 guide, the practical difference between Class I and Class IIa is substantial, involving not just cost and time, but an entirely different level of clinical evidence, quality management, and post-market accountability.

For software, the operative classification rule is MDR Annex VIII Rule 11. It applies specifically to software that functions as a medical device in its own right, rather than merely driving or influencing a hardware device. The regulation terms this Software as a Medical Device (SaMD).

How the MDR defines a medical device, and why AI tools often qualify

Under Article 2(1) of the MDR, a medical device is any instrument, apparatus, appliance, software, implant, reagent, material, or other article intended by the manufacturer to be used for purposes including diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease. The inclusion of software in that definition is explicit and has been since the regulation came into force.

The critical word is "intended." If a vendor positions an AI tool as supporting clinical decisions, flagging abnormal findings, suggesting diagnoses, recommending treatments, or stratifying patient risk, that stated purpose is sufficient to bring the software within the MDR's scope. As Tandem Health's regulatory explainer on EU healthcare AI regulations notes, the distinction that matters is between tools that merely organise or display information and those that flag findings, suggest diagnoses, or triage patients. The latter category is likely SaMD, regardless of how the vendor labels the product commercially.

Marketing language does not determine regulatory status. A tool described as an "AI assistant" or a "decision support aid" may still meet the MDR's definition of a medical device if its output is intended to inform clinical action.

The specific risk criteria that push AI decision support into Class IIa

Under MDR Rule 11, software is classified according to what its output is used for and the severity of harm that could result from an error. The classification logic, as detailed by IntuitionLabs in their 2026 compliance guide, works as follows:

  • Software intended to provide information used to make decisions with serious consequences for individual patients, such as diagnosis of life-threatening conditions or selection of treatment, is classified as Class IIa at minimum.

  • Software intended to provide information used to make decisions with critical consequences, where incorrect output could cause death or irreversible deterioration, is classified as Class IIb or Class III.

  • Software that performs no diagnostic or therapeutic function, but merely stores, archives, communicates, or searches data without influencing clinical decisions, may fall outside the medical device definition entirely.

The authoritative interpretive framework for these distinctions is MDCG 2019-11, the Medical Device Coordination Group (MDCG) guidance on qualification and classification of software under MDR and the In Vitro Diagnostic Regulation (IVDR). It establishes that the key question is not what the software does technically, but what clinical action its output is intended to support and what harm could follow from an error.

For most AI clinical decision support tools, those that analyse patient data and return outputs intended to guide diagnosis, treatment selection, or risk stratification, the combination of clinical influence and potential for patient harm places them squarely in Class IIa territory. MDCG 2025-6, published in early 2025, introduced the specific term "Medical Device AI" (MDAI) to describe AI systems that meet the MDR's medical device definition, reinforcing that there are no AI-specific exemptions from these classification rules, as IntuitionLabs confirms.

The patient safety case for regulated AI decision support

The MDR's conformity assessment requirements exist because the failure modes of AI clinical decision support are not theoretical. A peer-reviewed commentary published in PubMed Central on regulatory frameworks for clinical decision support software notes that even medium-risk MDR devices may generate serious harm through errors that clinicians do not recognise or are not positioned to override in time.

The specific risks that regulation is designed to address include:

  • Algorithmic bias: AI models trained on non-representative datasets may perform systematically worse for certain patient populations, with errors that are invisible to the clinician using the tool.

  • Opaque reasoning: Without explainability requirements, clinicians cannot assess whether an AI recommendation is based on clinically sound reasoning or a spurious statistical correlation.

  • Automation bias: Clinicians may over-rely on AI outputs, particularly when time-pressured, reducing the likelihood of independent clinical judgement overriding an incorrect recommendation.

  • Failure mode opacity: Unlike a broken thermometer, a malfunctioning AI model may continue to produce plausible-looking outputs while systematically misclassifying a subgroup of patients.

A narrative review on AI in personalised prescription published in Therapie identifies hallucinations, lack of explainability, and clinical de-skilling as significant risks in AI-assisted prescribing. The authors recommend that any generative AI used in clinical settings be treated as a medical device by default, with general-purpose large language models permitted only via certified clinical wrappers that close what they describe as the "MDR-inconsistent gap."

Research published in Clinical Orthopaedics and Related Research found that only 38 per cent of FDA-approved AI/ML orthopaedic devices had EU MDR equivalents, and that independent peer-reviewed evidence existed for only 30 per cent of those devices. This raises substantive questions about the evidentiary basis on which many AI tools have entered clinical use. The EU MDR's requirements are designed to prevent that gap from persisting.

One limitation is worth acknowledging: the evidence base on real-world harm directly attributable to unregulated AI decision support tools remains limited. Much of the safety case rests on demonstrated failure modes in controlled studies and on the precautionary logic of the regulatory framework itself, rather than on large-scale post-market harm data. That is partly because rigorous post-market surveillance of AI tools, one of the MDR's requirements, is still maturing across the industry.

What MDR Class IIa compliance requires from vendors

Achieving Class IIa certification is not a single event but an ongoing regulatory commitment. The core obligations for vendors include:

  • Quality Management System (QMS): Certification to ISO 13485, the international standard for medical device quality management systems, is required. This covers design controls, risk management, and change management processes.

  • Clinical evaluation: A systematic review of clinical evidence demonstrating that the device achieves its intended purpose safely and performs as claimed. For AI tools, this includes validation datasets and real-world performance data.

  • Technical documentation: A complete technical file covering device description, design and manufacturing information, risk management (typically per ISO 14971), and software lifecycle documentation per IEC 62304.

  • Notified Body involvement: Unlike Class I, Class IIa certification requires an independent Notified Body to review the quality management system and, in most cases, the technical documentation or a representative sample of it.

  • CE marking: Following successful conformity assessment, the device may bear the CE mark, indicating compliance with MDR requirements.

  • Post-market surveillance (PMS): Ongoing collection and analysis of real-world performance data, with a Post-Market Surveillance Plan and periodic safety update reports.

TrustedTrace Med's 2026 Rule 11 guide notes that the December 2025 European Commission proposal to amend Rule 11 may affect how some AI tools are classified going forward, but the core Notified Body requirement for software that influences clinical decisions is not expected to be removed.

The role of the Notified Body and clinical evidence requirements

A Notified Body is an independent conformity assessment organisation designated by an EU member state to evaluate whether medical devices meet MDR requirements. For Class IIa AI clinical decision support tools, the Notified Body reviews the quality management system and audits the technical documentation.

For AI tools specifically, the clinical evidence requirements are more complex than for traditional software. Decomplix's October 2025 regulatory analysis highlights the challenge of demonstrating high-quality training data to Notified Body reviewers, noting that Team-NB (the European association of Notified Bodies) has published position papers on the specific data governance requirements for MDAI under MDCG 2025-6.

Sufficient clinical evidence for an AI decision support tool typically includes:

  • Validation datasets that are representative of the intended patient population, including demographic diversity.

  • Real-world performance data from clinical settings comparable to the intended deployment environment.

  • Transparency documentation covering model architecture, training data provenance, and known limitations.

  • Evidence that the tool performs as intended across clinically relevant subgroups, not only in aggregate.

The Clinical Evaluation Navigator's analysis of MDCG 2025-6 also highlights a specific challenge for adaptive AI systems: tools whose models update over time must have Predefined Change Control Plans (PCCPs) that describe how changes will be validated and documented without requiring a full re-certification for every update.

What procurement teams must verify before deploying AI decision support

For healthcare organisations evaluating AI clinical decision support tools, vendor claims about regulatory compliance require active verification, not passive acceptance. A structured due diligence process should cover the following:

  • CE marking under MDR, not MDD: The legacy Medical Devices Directive (MDD) was superseded by MDR in May 2021 (with a transitional period). CE marks issued under the MDD are no longer valid for new devices placed on the market, and transitional provisions for legacy devices are expiring on a phased schedule through 2027–2028. Verify that the CE mark references Regulation (EU) 2017/745.

  • Device classification and GMDN code: The vendor should be able to state the MDR classification (Class I, IIa, IIb, or III) and the applicable Global Medical Device Nomenclature code.

  • Notified Body certificate: For Class IIa and above, a Notified Body certificate number should be verifiable. The certificate should be current and issued by a Notified Body designated under MDR (listed in the NANDO database).

  • Clinical evaluation report: Request a summary of the clinical evaluation, including the validation datasets used and any known performance limitations.

  • Post-market surveillance plan: Confirm that the vendor has an active post-market surveillance process and is collecting real-world performance data.

  • EUDAMED registration: The European Database on Medical Devices (EUDAMED) is being progressively populated. Vendors should be able to confirm their registration status.

A checklist-based methodology for AI policy implementation published in the Journal of Anaesthesia, Analgesia and Critical Care in September 2025 recommends systematic assessment covering evidence-based performance, real-world validation, MDR compliance, General Data Protection Regulation (GDPR) compliance in healthcare adherence, and post-deployment monitoring. This confirms that procurement accountability does not end at the point of purchase.

The EU AI Act explained introduces a parallel compliance layer. As Reed Smith's June 2025 legal analysis confirms, any MDR Class IIa device that incorporates AI is automatically classified as a high-risk AI system under the AI Act, imposing additional obligations around transparency, human oversight, and conformity assessment. The MedDeviceGuide 2026 compliance guide confirms that AI Act enforcement for CE-marked MDR devices applies from August 2026, with the broader August 2027 deadline covering certain other high-risk AI categories under the dual-compliance model.

The consequences of misclassification

When vendors misclassify AI clinical decision support tools, either by asserting they fall outside the MDR's medical device definition or by self-declaring Class I compliance when Class IIa applies, the consequences extend across multiple dimensions.

Regulatory enforcement: National competent authorities, such as the Agence nationale de sécurité du médicament et des produits de santé (ANSM) in France or the Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM) in Germany, have the power to require market withdrawal, impose financial penalties, and refer cases for criminal prosecution in serious cases. The MDR's enforcement provisions are substantially stronger than those of the MDD it replaced.

Institutional liability: Healthcare organisations that procure and deploy a misclassified AI tool carry their own regulatory exposure. Procurement teams that fail to verify MDR compliance cannot rely on vendor assurances as a complete defence. A risk management study published in Studies in Health Technology and Informatics in October 2025, examining MDR Article 82 compliance for clinical decision support systems, illustrates how even academic feasibility studies of clinical decision support systems now require systematic risk management under MDR, a signal of the regulation's broad reach.

Erosion of clinical trust: Beyond legal consequences, deploying unvalidated AI tools that subsequently fail in clinical use damages the credibility of AI-assisted care more broadly. The peer-reviewed literature on AI as a medical device in radiology, published in European Radiology in March 2026, identifies transparency, explainability, and human oversight as convergence points across EU, US, and Chinese regulatory frameworks, reflecting a global consensus that clinical AI requires demonstrable accountability.

MDR Class IIa certification as a basis for responsible AI adoption

The framing of MDR Class IIa certification as a barrier to innovation misrepresents its function. For AI clinical decision support, certification is the mechanism through which a tool earns the right to influence clinical decisions. It creates the audit trail, the evidence base, and the ongoing surveillance infrastructure that allow healthcare organisations to deploy AI with a defensible basis for trust.

Vendors who pursue rigorous classification signal something specific to procurement teams: that they have subjected their tools to independent scrutiny, that their clinical evidence has been reviewed by a Notified Body, and that they are committed to ongoing performance monitoring. That signal matters in a market where self-declared compliance is easy to assert and difficult to verify from the outside.

The MDx CRO regulatory guide notes that the AI Act's human oversight requirements, mandatory for high-risk AI systems including Class IIa MDR devices, reinforce rather than duplicate the MDR's safety framework. Together, these regulatory layers create the conditions under which clinicians can use AI decision support tools with appropriate confidence: knowing that the tool has been validated, that its limitations are documented, and that its performance in real-world use is being tracked.

For healthcare decision makers, the practical implication is straightforward. When evaluating AI clinical decision support tools, MDR Class IIa certification, with a verifiable Notified Body certificate, a current CE mark under Regulation (EU) 2017/745, and an active post-market surveillance programme, is the minimum credible evidence that a vendor has met the regulatory standard the EU has established for software that influences clinical care.

Frequently asked questions

▶ What is MDR Class IIa certification and why does it apply to AI clinical decision support tools?

The EU Medical Device Regulation (Regulation 2017/745) organises medical devices into four risk classes. Class IIa covers medium-risk devices, including software that provides information used to make decisions with serious consequences for individual patients, such as diagnosis or treatment selection. AI clinical decision support tools that analyse patient data and return outputs intended to guide diagnosis, treatment, or risk stratification typically fall into Class IIa because their failure could cause patient harm. Unlike Class I devices, Class IIa certification requires independent review by a Notified Body, a designated conformity assessment organisation, rather than a manufacturer's self-declaration alone.

▶ What makes an AI tool a Software as a Medical Device under the MDR?

Under Article 2(1) of the MDR, software qualifies as a medical device if its manufacturer intends it to be used for diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease. The classification rule that applies specifically to standalone software is MDR Annex VIII Rule 11. If an AI tool flags abnormal findings, suggests diagnoses, recommends treatments, or stratifies patient risk, it is likely Software as a Medical Device regardless of how the vendor labels it commercially. Marketing language such as "AI assistant" or "decision support aid" does not determine regulatory status.

▶ What are the main patient safety risks that MDR regulation of AI decision support is designed to address?

The MDR's conformity assessment requirements address several specific failure modes. Algorithmic bias can cause AI models trained on non-representative datasets to perform worse for certain patient populations in ways that are invisible to the clinician. Opaque reasoning means clinicians cannot assess whether a recommendation is based on sound clinical logic or a spurious statistical correlation. Automation bias describes the tendency for clinicians to over-rely on AI outputs, particularly under time pressure, reducing independent clinical judgement. A malfunctioning AI model may also continue producing plausible-looking outputs while systematically misclassifying a subgroup of patients, unlike a broken thermometer whose failure is immediately apparent.

▶ What does achieving MDR Class IIa certification actually require from a vendor?

Class IIa certification is an ongoing regulatory commitment, not a one-time event. Vendors must hold a Quality Management System certified to ISO 13485, the international standard for medical device quality management. They must produce a clinical evaluation demonstrating that the device achieves its intended purpose safely, including validation datasets and real-world performance data. A complete technical file covering device description, risk management per ISO 14971, and software lifecycle documentation per IEC 62304 is required. A Notified Body must review the quality management system and technical documentation. Following successful assessment, the device may carry the CE mark under Regulation (EU) 2017/745. Vendors must also maintain an active post-market surveillance programme collecting real-world performance data on an ongoing basis.

▶ What should procurement teams verify before deploying an AI clinical decision support tool?

Procurement teams should verify that the CE mark references Regulation (EU) 2017/745, not the legacy Medical Devices Directive, which is no longer valid for new devices. The vendor should be able to state the MDR classification and provide a current Notified Body certificate number verifiable against the NANDO database. Procurement teams should request a summary of the clinical evaluation, including the validation datasets used and known performance limitations. Confirming that the vendor has an active post-market surveillance plan and can confirm registration status with the European Database on Medical Devices (EUDAMED) are also part of a structured due diligence process. Procurement accountability does not end at the point of purchase.

▶ What is MDCG 2025-6 and what does it mean for AI medical devices?

MDCG 2025-6 is guidance published by the Medical Device Coordination Group in early 2025. It introduced the specific term "Medical Device AI" (MDAI) to describe AI systems that meet the MDR's medical device definition. The guidance confirms that there are no AI-specific exemptions from MDR classification rules. It also introduced requirements around data governance for MDAI, and highlighted a specific challenge for adaptive AI systems: tools whose models update over time must have Predefined Change Control Plans describing how changes will be validated and documented without requiring full re-certification for every update.

▶ How does the EU AI Act interact with MDR Class IIa certification for AI clinical decision support?

Any MDR Class IIa device that incorporates AI is automatically classified as a high-risk AI system under the EU AI Act. This creates a dual-compliance model, with the AI Act imposing additional obligations around transparency, human oversight, and conformity assessment alongside the MDR's existing requirements. AI Act enforcement for CE-marked MDR devices applies from August 2026. The AI Act's human oversight requirements reinforce rather than duplicate the MDR's safety framework, and together these regulatory layers create the conditions under which clinicians can use AI decision support tools with appropriate confidence.

▶ What are the consequences of misclassifying an AI clinical decision support tool under the MDR?

Misclassification carries consequences across several dimensions. National competent authorities, such as ANSM in France or BfArM in Germany, can require market withdrawal, impose financial penalties, and refer serious cases for criminal prosecution. Healthcare organisations that procure and deploy a misclassified AI tool carry their own regulatory exposure and cannot rely solely on vendor assurances as a defence. Beyond legal consequences, deploying unvalidated AI tools that subsequently fail in clinical use damages the credibility of AI-assisted care more broadly, a concern reflected in peer-reviewed literature across multiple clinical specialties.

▶ What clinical evidence does a Notified Body require when assessing an AI decision support tool?

Sufficient clinical evidence for an AI decision support tool typically includes validation datasets representative of the intended patient population, including demographic diversity. Real-world performance data from clinical settings comparable to the intended deployment environment is required. Transparency documentation covering model architecture, training data provenance, and known limitations must be provided. Evidence that the tool performs as intended across clinically relevant subgroups, not only in aggregate, is also expected. The European association of Notified Bodies has published position papers on the specific data governance requirements for Medical Device AI under MDCG 2025-6.

▶ Is MDR Class IIa certification a barrier to AI innovation in healthcare?

Framing MDR Class IIa certification as a barrier to innovation misrepresents its function. For AI clinical decision support, certification is the mechanism through which a tool earns the right to influence clinical decisions. It creates the audit trail, the evidence base, and the ongoing surveillance infrastructure that allow healthcare organisations to deploy AI with a defensible basis for trust. Vendors who pursue rigorous classification signal to procurement teams that their tools have been subjected to independent scrutiny, that their clinical evidence has been reviewed by a Notified Body, and that they are committed to ongoing performance monitoring. That distinction matters in a market where self-declared compliance is easy to assert and difficult to verify from the outside.

Get started with Tandem today

Join thousands of clinicians enjoying stress-free documentation.

Get started with Tandem today

Join thousands of clinicians enjoying stress-free documentation.

Get started with Tandem today

Join thousands of clinicians enjoying stress-free documentation.