When Is a Healthcare AI Tool an FDA-Regulated Medical Device?

The question is never whether a product uses AI. FDA's jurisdiction turns on intended use, and the analysis has the same shape it has had since long before machine learning: does the software function meet the definition of a device in section 201(h) of the Federal Food, Drug, and Cosmetic Act, meaning is it intended for use in the diagnosis, cure, mitigation, treatment or prevention of disease.

Section 3060 of the 21st Century Cures Act, enacted in December 2016, then carved several software categories out of that definition at section 520(o). The carve-out that matters most for healthcare AI is 520(o)(1)(E), covering certain clinical decision support software intended for health care professionals. Software that meets all four of its criteria is not a device at all, which is a stronger position than being a device FDA chooses not to enforce against.

FDA has been careful to say that its 2022 Clinical Decision Support Software guidance did not bring new software functions under oversight. It interprets a statutory boundary that already existed. FDA has also been careful to say that the CDS guidance is one of several documents that bear on the question and should not be used as the sole reference, pointing separately to its Policy for Device Software Functions and Mobile Medical Applications, its Multiple Function Device Products guidance, and its Digital Health Policy Navigator. If a product's status is genuinely close to the line, that is a question for regulatory counsel and a pre-submission, not for a procurement checklist.

All four must be met. Failing any one takes the software out of the exclusion, although it does not automatically make it a regulated device, because other policies may still apply.

Two consequences are easy to miss. The exclusion is written around software intended for health care professionals, so tools aimed at patients or caregivers are analysed differently. And FDA has said that software meant to support time-critical decision making generally cannot meet the criteria, because in a time-critical situation it is hard to sustain the claim that a clinician is not meant to rely primarily on the output or will pause to understand its basis. Deployment context, not just design, moves the answer.

In the ordinary case, no, and it is worth being unambiguous about it because the uncertainty costs organisations months.

An ambient documentation tool that listens to an encounter and drafts a note is transcribing and summarising a conversation that already happened. It is not intended for the diagnosis, cure, mitigation, treatment or prevention of disease. The same reasoning covers an AI phone agent that books and reschedules appointments, a patient intake agent that collects history into a form, scheduling automation, and revenue cycle and denial management workflows. None of these has a device intended use, so the four CDS criteria never come into play. There is nothing to argue about.

FDA has also said, in its CDS frequently asked questions, that software functions that merely provide an electronic means of distributing, completing and sharing a well understood survey are not devices, and that software automating simple tasks for health care professionals is generally a function for which FDA would exercise enforcement discretion even if it did meet the device definition.

What changes the answer is a claim, not a technology. If a scribe vendor markets the product as identifying suspected conditions the clinician missed, or a triage agent as determining clinical urgency, the intended use has shifted and the analysis restarts. This is the practical reason to read marketing copy as carefully as the contract: the vendor's own claims are evidence of intended use, and a claim made in a sales deck can create a regulatory question that the engineering never intended.

Worked examples travel better than principles. The table below reflects how the criteria apply to categories of tool that healthcare organisations commonly evaluate. It is a guide to the conversation, not a regulatory determination for any specific product, and the answer for a given product always depends on its own intended use and labelling.

The row that generates the most disagreement is the risk score, and it is worth understanding why. A score that displays alongside its contributing factors, in a workflow with time to reflect, looks very different from the same score firing a page to a rapid response team. Same model, different regulatory posture, because intended use and context of use both count. This is also the row where ONC's predictive decision support requirements most often apply in parallel, and FDA says plainly that some predictive DSIs are devices and some are not.

Traditional device regulation assumes a product that does not change. AI models change, and every significant change to a cleared device would ordinarily require a new marketing submission. A predetermined change control plan is the mechanism FDA created to resolve that tension, finalised in guidance in December 2024 for AI-enabled device software functions.

A PCCP describes, in advance and as part of the marketing submission, the modifications the manufacturer plans to make, the methodology it will use to develop, validate and implement them, and an assessment of their impact. FDA reviews it with the submission. Changes made within the authorised plan can then be implemented without a further submission each time.

For a buyer this is one of the most informative documents a vendor can hand over, and almost nobody asks for it. It tells you what the vendor is permitted to change, how it validates changes, and by extension what will arrive in your environment without a formal notification. Three questions follow naturally. Does the authorised device have a PCCP. What modifications does it cover. How and when will we be told a change has been implemented. A vendor that cannot answer the third question has an operational gap regardless of what FDA authorised, and that gap lands in your change management process.

The statute does not mention model architecture, so the analysis is unchanged: intended use first, then the four criteria. In practice generative systems make criterion 4 harder to satisfy, because a fluent narrative recommendation whose basis cannot be traced is close to the definition of something a clinician cannot independently review. A generative tool that cites the specific guideline, note or result behind each statement is in a much better position than one that does not, which is a good reason to prefer that design irrespective of regulatory status.

FDA has been actively working on this. It convened its Digital Health Advisory Committee on total product lifecycle considerations for generative AI-enabled devices in 2024 and announced a further meeting and public docket on generative AI-enabled devices in September 2025. It has also said it intends to explore ways to identify and tag devices that incorporate foundation models, including large language models, on its AI-Enabled Medical Device List, and has asked sponsors to include appropriate information in their public summaries so that it can do so.

None of that changes the position for a general purpose assistant used by a clinician on their own initiative. FDA regulates products with a medical intended use placed on the market, not a professional's decision to consult a general tool. That does not make it a good idea: HIPAA, your own clinical governance and your medical staff bylaws all have things to say about it, and none of them are answered by the observation that FDA is not involved.

You are not the regulated party, so your goal is not to police the vendor. It is to know which regime you are relying on and to make sure your workflow matches the vendor's own position.

1. Is any function of this product a medical device, and if so which one? Ask for the specific function, not a product level answer, because multiple function products are common and FDA analyses the device functions individually.
2. If it is a device, what is the authorisation? A 510(k) number, De Novo classification or PMA, plus the cleared indications for use. Then check that your intended workflow sits inside those indications rather than beside them.
3. If it is not a device, on what basis? The credible answers are that it has no device intended use, that it meets all four criteria of section 520(o)(1)(E), or that it falls within a stated FDA enforcement discretion policy. A vendor that cannot articulate which of these applies has not done the analysis.
4. Is there a predetermined change control plan, and what does it cover?
5. What claims does marketing make? Compare the sales deck against the regulatory position. Divergence between them is the most common early warning sign we see.
6. What happens when the model is updated? Notification, revalidation and rollback, in writing.

Ask these during vendor selection. After signature, the same questions are an argument rather than an evaluation, and the answers arrive slower.

A short standing process handles this well. It does not need a regulatory affairs function.

1. Classify every AI tool in your estate into three buckets: no device intended use, non-device CDS relying on 520(o)(1)(E) or an enforcement discretion policy, and authorised device. Record the basis for each in one line. Most administrative agents land in bucket one and take a minute each.
2. For bucket three, record the authorisation and the cleared indications and confirm your deployed workflow sits inside them.
3. For bucket two, record which criterion is doing the work, and flag anything where the deployment is time-critical or the basis is not visible to the user. Those are the ones to revisit.
4. Re-run the classification whenever intended use, marketing or workflow changes. A tool that moves from suggesting to deciding has changed category even if the code has not.
5. Ask for the PCCP on any authorised device and build its change notifications into your change management calendar.
6. Keep the classification in the same register as your other AI governance records, not in a separate legal folder, so that the person doing the annual review sees the whole estate at once.

Done properly this is an afternoon's work for most organisations and a recurring half hour thereafter. Done badly, it becomes a stalled deployment while a committee tries to answer a question nobody has framed. If you would rather have the classification, the vendor questions and the change management process set up once and handed over, that is what our AI governance and compliance engagement delivers, and the readiness audit is where most organisations start.