Is My Health AI a Medical Device? FDA Clearance Explained

"Do I need FDA clearance?" is one of the most common questions a health AI founder asks, and one of the most consistently under-answered, because the honest answer depends on exactly what your software claims to do, not on how clinical it feels to build.

In short: If your health AI analyses patient data to diagnose, treat, monitor, or recommend care, it likely meets the FDA's medical device definition and needs clearance or authorization before US marketing. Wellness apps sit outside FDA's enforcement focus and some clinical decision support tools are statutorily carved out, but a wellness label doesn't override clinical marketing language.

The device definition, applied to AI

The FDA's device definition, set out in section 201(h) of the Federal Food, Drug, and Cosmetic Act (21 U.S.C. §321(h)), is broad by design: an instrument, apparatus, or software intended for use in the diagnosis, cure, mitigation, treatment, or prevention of disease, or intended to affect the structure or function of the body. Software that meets this definition is regulated as Software as a Medical Device, commonly abbreviated SaMD, and the same product faces a separate medical device classification test in the EU.

For AI specifically, the FDA has been explicit that the presence of machine learning doesn't itself trigger regulation, and its absence doesn't exempt a product from it. What matters is the same thing MDR asks in Europe, phrased differently: what does the software claim to do with patient data, and does that claim fall inside the device definition. A model that predicts a patient's risk of a clinical event and presents that prediction to a clinician for use in a treatment decision is almost certainly a device. A model that recommends today's step goal based on yesterday's activity is almost certainly not.

The three buckets: wellness, the CDS carve-out, SaMD

Health software in the US sorts into three practical categories, and knowing which one you're in changes everything about your regulatory obligations. The two non-device buckets rest on legally different mechanisms, and the difference is worth keeping straight rather than calling both "exemptions."

General wellness products sit outside FDA's active oversight under its general wellness policy — General Wellness: Policy for Low Risk Devices (first finalised 2016, most recently revised January 2026): low-risk products intended to promote a healthy lifestyle, with no claim to diagnose, treat, cure, mitigate, or prevent a specific disease or condition. Strictly, this is enforcement discretion, not a statutory exemption: FDA states it does not intend to examine low-risk general wellness products, which is a policy posture FDA can narrow, not an affirmative legal status you can cite in diligence. The policy is about claims, not technology. A product with sophisticated sensors and machine learning can still be general wellness if it stays on the wellness side of the claims line. Wellness App or Medical Device? The FDA Line covers this test in detail, including the specific claims patterns that tend to push a product across it.

Clinical decision support software has a narrower — but legally stronger — statutory carve-out: software meeting the four criteria of FD&C Act section 520(o)(1)(E), added by the 21st Century Cures Act and interpreted in FDA's Clinical Decision Support Software final guidance (September 2022, most recently revised January 2026), is excluded from the device definition itself — it is not a device at all, rather than a device FDA chooses not to police. Four conditions have to be met together for the carve-out to apply. The software must not acquire, process, analyse, or interpret medical images or signals directly — where "signals" means signals from an in vitro diagnostic device or patterns and signals from a signal-acquisition system, a scope FDA reads broadly, so this pushes more software back into device territory than founders expect. It must be intended to support, not replace, clinical judgment. It must allow the healthcare provider to independently review the basis for the recommendation, rather than presenting a black-box output the clinician is expected to simply accept. And it has to be aimed at a healthcare professional rather than a patient making decisions without professional involvement. Many rules-based clinical decision support tools qualify against all four. Most AI-driven tools that analyse images, waveforms, or complex physiological signals don't, because the "independently review the basis" condition is difficult to satisfy when the recommendation comes from a trained model rather than a transparent, inspectable rule set.

Software as a Medical Device, SaMD, is everything else that meets the device definition: software that analyses patient data, images, signals, lab values, clinical history, to diagnose, treat, monitor, or recommend a course of care, and falls under neither the wellness policy nor the CDS carve-out above. This is where most substantive health AI products land once they move past pure wellness framing.

SaMD risk categorization: not every SaMD product carries the same regulatory weight

Once you've concluded your product is SaMD, it helps to understand that regulators don't treat all SaMD as a single undifferentiated risk tier. A widely used way of thinking about this, drawing on work by the International Medical Device Regulators Forum, runs on two axes: the significance of the information the software provides to a healthcare decision, and the state of the healthcare situation or condition involved. One caveat before using it: the IMDRF categorization is a risk heuristic — a genuinely useful mental model — not the mechanism FDA uses to assign your device's class. US classification is formally Class I, II, or III, assigned through product codes and classification regulations, so don't cite an "IMDRF category" as if it were an FDA determination.

Software that informs clinical management, providing information that aids a decision but where the clinician has other reasonably available sources of information and time to make an independent judgment, sits toward the lower end of SaMD risk, particularly for non-serious conditions. Software that drives clinical management, where the output is used to guide immediate treatment or intervention decisions, carries more weight, especially for serious or critical conditions. Software that diagnoses or treats directly, particularly for critical conditions where a wrong output could have immediate and severe consequences, sits at the highest end.

This framework matters practically because it shapes the depth of clinical evidence FDA will expect and the pathway most likely to fit. A SaMD product that informs management of a non-serious condition might reasonably pursue 510(k) clearance against an established predicate with a moderate evidence package. A SaMD product that drives management of a critical condition, with no comparable predicate on the market, is a much stronger De Novo or even PMA candidate, and the evidence bar rises accordingly. Thinking through where your product sits on both axes, information significance and condition seriousness, before you pick a pathway saves a lot of wasted motion later, because it tells you roughly how much clinical evidence you're going to need to generate regardless of which specific pathway you end up filing under.

Why your marketing copy can reclassify you

FDA doesn't classify software based on its technical architecture. It classifies based on intended use, and intended use is established primarily through labelling, marketing claims, and how the product is presented to users and clinicians, not through an engineering description of what the model does under the hood. A sophisticated diagnostic algorithm marketed with careful, general wellness language can sometimes genuinely sit inside the wellness policy, provided the underlying claims are actually kept general. The more common and more expensive failure mode is the opposite: a product understood internally as "just a wellness tool" that acquires device-triggering claims over time, as marketing reaches for language that converts better.

This is the same dynamic Wellness App or Medical Device? The FDA Line covers in depth, including the specific claims-drift examples, like a testimonial describing a "condition caught early," that tend to trigger it. Rather than repeat that argument here, the point worth making specific to health AI is this: because AI outputs often feel more authoritative to a marketing team than a static tool's outputs, the temptation to describe them in stronger clinical language is correspondingly higher, and worth watching for during copy review specifically on AI-driven features. The discipline this requires is cross-functional. Regulatory, product, and marketing need a shared, current understanding of exactly what claims are and aren't supported by your regulatory status, reviewed whenever marketing copy changes materially, not just at launch.

Which pathway follows

Once you've concluded your product is SaMD, the next question is which FDA pathway applies, and the honest answer depends on whether a comparable device already exists on the market.

The 510(k) pathway is the most common route. You demonstrate your device is substantially equivalent to an existing, legally marketed predicate device, and FDA clears it, not approves it, for that intended use. That word distinction matters and we return to it below. The De Novo pathway exists for genuinely novel low-to-moderate-risk devices with no suitable predicate, and results in a new device classification rather than a comparison to something that already exists. Premarket Approval, PMA, is the most rigorous route, reserved for Class III high-risk devices, and is the only one of the three where "approval" is the technically correct word. A fourth, narrower option, the 513(g) request, lets you ask FDA directly how it would classify your device before committing to a pathway, useful when genuine ambiguity remains after working through the tests above. 510(k) vs De Novo vs PMA: Which FDA Pathway walks through how to work out which one fits your device, and Why Most 510(k)s Get an Information Request covers what to expect once you've chosen that route.

Pathway selection also isn't the whole story once you're a device. A cleared, granted, or approved device owes quality-system compliance under FDA's QMSR (in force since 2 February 2026, incorporating ISO 13485:2016 by reference) and, for any "cyber device" — which covers most connected health software — the cybersecurity documentation requirements of FD&C Act section 524B.

If your model will keep learning: the PCCP

For adaptive AI specifically, one further mechanism is the single most consequential thing in FDA's toolkit, and no founder of a continuously improving model should leave this article without knowing it exists: the Predetermined Change Control Plan (PCCP). FDA's final guidance on PCCPs for AI-enabled device software functions, issued 4 December 2024, lets you get a bounded plan for anticipated model changes — retraining on expanded data, recalibration within a defined performance envelope — reviewed and authorized as part of your original marketing submission, whether your route is 510(k) clearance, De Novo authorization, or PMA approval. Changes within the plan's bounds then ship without a new submission; without a PCCP, a material change to a cleared model can require a new submission each time. Because the plan is authorized with the original submission rather than bolted on afterwards, PCCP scoping belongs in your initial submission planning if your product's value depends on the model improving post-clearance. FDA PCCP: Updating AI Models After Clearance covers the full framework, including what FDA will and won't accept inside a plan.

Five borderline products worth thinking through

Abstract rules are easier to apply once you've seen them run against specific products. Here are five that come up often in early founder conversations.

A triage chatbot that asks about symptoms and recommends "see a doctor within 24 hours" versus "this can likely wait" is making a clinical urgency judgment about a specific patient, and generally functions as SaMD rather than qualifying for the CDS carve-out, because the recommendation is typically presented to the patient directly rather than reviewed independently by a clinician before use.

A radiology worklist prioritization tool that reorders a queue based on suspected findings, without stating a diagnosis, still analyses images directly, which disqualifies it from the CDS carve-out regardless of how the output is framed. The carve-out's first condition rules this out immediately, since it's built entirely on image analysis.

A medication dosing assistant for a narrow therapeutic index drug, built as a transparent, rules-based calculator that shows its working and lets the clinician see exactly which inputs drove the recommendation, has a much better argument for the CDS carve-out than an opaque model producing the same recommendation, precisely because of the independent-review condition.

A mental health screening tool using natural language processing on a patient's own typed responses, to flag possible depression severity, is analysing a specific patient's data to produce a clinically meaningful output, and most versions of this land as SaMD, even when the underlying screening questions are drawn from a validated, publicly available questionnaire.

A remote patient monitoring platform that aggregates vitals and only alerts when a value crosses a clinician-configured threshold, without doing its own interpretation, sits closer to the CDS carve-out or even outside the device definition altogether, since the interpretive judgment (what threshold matters and why) was supplied by the clinician rather than the software.

The thread across all five: non-device status, whether via the wellness policy or the CDS carve-out, is fragile and specific. Small implementation choices, whether the recommendation goes straight to a patient or is filtered through a clinician, whether the reasoning is visible or opaque, whether the software sets the clinical threshold or just applies one a human chose, repeatedly turn out to be the deciding factor.

FDA vs EU: two separate systems

It's worth being direct about something founders frequently assume incorrectly: FDA clearance doesn't help you market in the EU, and a CE mark doesn't help you market in the US. The two systems are legally independent. FDA reviews under its own statutory framework and its own evidence standards; the EU assesses conformity against MDR through Notified Bodies. Clearing a 510(k) doesn't shorten, waive, or substitute for any part of the CE marking process, and the reverse is equally true.

What does transfer between the two, in practice, is underlying evidence: your clinical data, your verification and validation testing, elements of your quality management system. This is real and valuable, but it's evidentiary reuse, not regulatory equivalence. CE Mark vs FDA Clearance: The Real Differences sets out exactly what transfers and what has to be rebuilt for each market, which matters if you're sequencing a launch across both.

Next step

If you're still genuinely unsure which of the three buckets your product falls into, that uncertainty is itself useful information. It usually means your current claims are ambiguous enough to need tightening regardless of which regulatory answer you land on. Start by writing down, in one sentence, exactly what your product claims to do for the user's health, no technical description, just the claim as a user or clinician would read it. That sentence is closer to how FDA will read your intended use than any description of your model architecture.

Frequently asked questions

Does using a large language model instead of a traditional classifier change the regulatory answer? No. FDA's device definition, the wellness policy, and the CDS carve-out all turn on intended use and claims, not on the specific machine learning technique used. An LLM-based symptom checker that outputs a likely diagnosis is assessed the same way a rules-based one would be.

If my app only gives general health information, sourced from an LLM, am I automatically exempt? Not automatically. General, non-patient-specific information is more likely to stay outside the device definition, but if the tool takes a specific user's data and returns a patient-specific recommendation about a named condition, it can cross into device territory regardless of how general the underlying model's training was.

Can I launch as general wellness and add clinical claims later once I have evidence? Yes, but that later addition is a regulatory decision, not just a marketing one. Adding a diagnostic or therapeutic claim after launch means revisiting your FDA status from that point forward, and potentially needing clearance or authorization before the new claim goes live, not retroactively.

Does FDA clearance let me make stronger claims than an uncleared device? Clearance authorises the specific intended use reviewed and cleared, and claims beyond that scope aren't covered by it. A cleared device with narrow labelling can't market itself for a broader use without additional review.

Is a 510(k) always faster than a De Novo? Usually, because a De Novo involves FDA creating a new classification rather than comparing to an existing predicate, which typically takes longer and requires more original evidence. But a 510(k) is only available if a genuine predicate exists. Forcing a weak predicate comparison to avoid a De Novo often costs more time later in the form of additional information requests.

Does the CDS carve-out ever apply to a patient-facing tool, or only clinician-facing ones? In practice, almost always clinician-facing. The carve-out's conditions, particularly the requirement that the healthcare provider be able to independently review the basis for the recommendation, are built around a clinician using the software as one input among several, not a patient receiving a recommendation directly with no professional in the loop.

How does SaMD risk categorization affect how much clinical evidence I need? Broadly, more significant information and more serious conditions call for a deeper evidence package, regardless of which specific pathway you use. A tool informing management of a non-serious condition can often rely on a narrower validation study; a tool driving management of a critical condition needs evidence closer to what a full clinical investigation would produce, even if it technically files as a 510(k).

The free MedTech Compass can give you an AI-generated first read on which bucket your product likely falls into, based on the claims you describe. It's not a validated regulatory determination. Treat it as a starting point for a conversation with someone who can review your actual labelling and marketing material.

---

Where next: MDR Rule 11: Why Software Lands in Class IIa · 510(k) vs De Novo vs PMA: Which FDA Pathway · Wellness App or Medical Device? The FDA Line · CE Mark vs FDA Clearance: The Real Differences

Find out in minutes whether your product needs FDA clearance. Start the MedTech Compass →