Whether your clinical software is a regulated medical device is decided by what you claim it does, not by how it is built. The same model can be an unregulated administrative tool with one intended-use statement and a class III device with another, and the statement is yours to write.
Information, not legal advice, and not clinical or regulatory advice. Reviewed 4 August 2026. Device classification is fact-specific and the consequences of getting it wrong include enforcement action and product withdrawal. Use a regulatory professional. This page describes the questions that decide the answer; it does not answer them for your product.
The line, in one paragraph per jurisdiction
European Union. Software is a medical device if the manufacturer intends it for a medical purpose — diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease — as set out in the definition in Regulation (EU) 2017/745, the Medical Device Regulation, or the corresponding definition in the In Vitro Diagnostic Regulation (EU) 2017/746 where it works on specimens. There is no clinical decision support carve-out. Software that drives or influences the use of a device, or provides information used to take decisions for diagnostic or therapeutic purposes, is in.
United States. Software is a device under the Federal Food, Drug, and Cosmetic Act if it is intended for use in the diagnosis, cure, mitigation, treatment or prevention of disease — but section 520(o), added by the 21st Century Cures Act in 2016, excludes certain clinical decision support software from the device definition entirely, on four cumulative conditions. That carve-out has no EU equivalent and it is the single biggest structural difference between the two regimes.
EU: qualification then classification
Two questions in order. Qualification asks whether it is a device at all. Classification asks which class, which determines the conformity assessment route and whether a notified body is involved.
Qualification
- Is it software? A set of instructions processing input data and creating output data.
- Does it perform an action on data beyond storage, archival, communication or simple search? A viewer that displays an image unchanged is not a device; one that segments the image is performing an action.
- Is the action for the benefit of an individual patient? Software that produces population-level epidemiological output for research is treated differently from software that produces a result about a named patient.
- Does the manufacturer intend a medical purpose? This is decided from your intended purpose statement, labelling, instructions for use and promotional material. Marketing copy is evidence of intended purpose, which is why regulatory teams read it.
The MDCG guidance on qualification and classification of software (MDCG 2019-11) is the working document for this analysis, and it predates the current wave of AI products but is still the reference European regulators apply.
Classification
Software that qualifies is classified under the MDR’s classification rules in Annex VIII, and Rule 11 is the one that governs software intended to provide information used to take decisions for diagnostic or therapeutic purposes. The structure of Rule 11 is that such software is class IIa by default; class IIb if the decisions could cause serious deterioration of health or surgical intervention; and class III if they could cause death or an irreversible deterioration of health. Software intended to monitor physiological processes is class IIa, or IIb where the parameters monitored are such that variation could result in immediate danger. Everything else is class I.
The practical effect of Rule 11 is that almost no diagnostic AI is class I, and anything above class I needs a notified body. Notified body capacity has been a constraint on the European market since the MDR applied, and that is a scheduling reality rather than a compliance one.
US: the device definition and the CDS carve-out
The four conditions of the clinical decision support exclusion are cumulative — fail one and the software is a device. Paraphrasing the statute:
- It is not intended to acquire, process or analyse a medical image or a signal from an in vitro diagnostic device or a signal acquisition system. Failing this one is common and immediate: anything working on imaging or waveform data is out of the carve-out at step one.
- It is intended to display, analyse or print medical information about a patient or other medical information such as peer-reviewed clinical studies and clinical practice guidelines.
- It is intended to support or provide recommendations to a health care professional about prevention, diagnosis or treatment.
- It is intended to enable the professional to independently review the basis for the recommendations, so that they do not rely primarily on any of them.
The fourth condition is where most AI products fail, and it is worth being blunt about why. A model that outputs a score without an inspectable basis does not enable independent review. FDA’s guidance on the exclusion, finalised in September 2022, took a narrow view: the software should explain the basis, identify the inputs and the relevant sources, and be presented so the professional can reach their own conclusion rather than accept the output. “Explainable enough for a clinician to disagree with” is a good working restatement, and it is a product requirement with a regulatory consequence attached.
Note also that the carve-out is only for software supporting health care professionals. Software providing recommendations to patients or caregivers is not within it.
US pathways, and what most AI devices use
| Pathway | Description |
|---|---|
| 510(k) premarket notification | Demonstrate substantial equivalence to a legally marketed predicate device. The route the large majority of AI-enabled devices have taken. Requires a predicate, which is why the first device of a kind cannot use it. |
| De Novo classification | For a novel device of low to moderate risk with no predicate. Creates a new classification and a predicate for those that follow. |
| Premarket approval | Class III, highest risk. Clinical evidence of safety and effectiveness. Rare for software. |
| Enforcement discretion | FDA has said it does not intend to enforce against certain low-risk categories — general wellness products, some clinical decision support, certain mobile apps. Discretion is a policy position, not an exemption, and it can change. |
FDA maintains a public list of AI-enabled medical devices it has authorised. It passed a thousand entries during 2024 and 2025 and the large majority are radiology. That distribution is informative: imaging has quantifiable endpoints, established predicates and readable performance comparisons, and the areas where AI products are hardest to clear are the ones where the endpoint is a clinical judgement rather than a measurement.
Changing the model after clearance
This is the question that separates medical AI from ordinary software and it is the one teams discover late.
Traditionally, a change to a cleared device that could significantly affect safety or effectiveness requires a new submission. For a model you intend to retrain, that is a submission per retrain, which is commercially impossible.
The mechanism that solves it is the predetermined change control plan. You describe, in the original submission, the modifications you anticipate making, the methodology by which you will develop, validate and implement them, and an assessment of their impact. If FDA authorises the plan, changes within it can be made without a new submission. FDA finalised guidance on marketing submissions for predetermined change control plans for AI-enabled device software functions in December 2024, and the mechanism has a statutory basis added by legislation in 2022 — this page does not cite the section number for it.
The design consequence is that you must decide what you will be allowed to change before you submit. A plan that anticipates recalibration on new site data is very different from one that anticipates a new architecture, and you cannot widen it later without going back. Write the change control plan while you are still choosing the model, not after.
The EU has no direct equivalent. Under the MDR, significant changes to the design or intended purpose require notified body involvement, and the guidance on what counts as significant for software was not written with continuously learning systems in mind. In practice, European manufacturers of AI devices lock the model and revalidate through change management, which is slower.
How the AI Act stacks on top
A medical device is covered by Annex I of the AI Act — the list of Union harmonisation legislation. Under Article 6(1), an AI system that is a safety component of such a product, or is itself such a product, is high-risk where the product must undergo a third-party conformity assessment. A class IIa or higher device with AI in it therefore becomes a high-risk AI system, and that limb of the Act applies from August 2027 rather than from general application.
The Act tries to avoid duplication: where a product is already subject to a conformity assessment under Annex I legislation, the AI Act requirements are assessed as part of that existing assessment rather than through a separate one, and a single technical documentation set may cover both. That is real relief, but it is not nothing: Articles 8 to 15 add requirements — on data governance, on logging, on human oversight design, on cybersecurity — that the MDR does not articulate in the same terms, and your existing technical file will not contain them already.
One more layer for the US: clinical software handling protected health information is also governed by HIPAA, which is orthogonal to device regulation and is often the more immediate problem. See what HIPAA permits with language models.
The general-purpose model problem
Both regimes were built for software with a fixed, testable function. A general-purpose language model used clinically strains them in three specific ways, and neither regulator has fully resolved any of the three.
- Indeterminate intended use. Device regulation depends on a defined intended purpose. A model that answers any clinical question does not have one, which is why products are narrowed to a specific indication before submission — and why a general assistant marketed for clinical use is a much harder regulatory object than a segmentation tool.
- Non-deterministic output. Performance testing assumes a stable input-output relationship. Sampling makes the same input produce different outputs, so the evidence has to be distributional, and the acceptance criteria have to be written that way from the start.
- Model updates outside your control. If your device calls a third-party hosted model, the manufacturer of that model can change it without telling you, which under either regime is a change to your device that you did not make and cannot validate in advance. The only workable answers are version pinning with contractual notice of deprecation — see the model change clause — or hosting weights you control.
Meanwhile the administrative uses — ambient documentation, coding support, letter drafting — largely sit outside device regulation because they make no medical claim. That boundary is load-bearing and it is thinner than it looks: a documentation tool that starts suggesting diagnoses has changed its intended purpose, and intended purpose is established by what you say the product does, in every channel where you say it.
Top comments (0)