When Your Health App Becomes a Medical Device: FDA SaMD Regulation for AI Health Tech

Most health tech founders we work with share the same assumption: their AI-powered health app is a wellness product, not a medical device. That assumption can be the most expensive mistake in your company's lifecycle. The FDA has cleared hundreds of AI/ML-enabled medical devices as of 2026, and the line between a wellness app and a regulated medical device turns on a single question that most founders cannot answer: what is your software's intended use?

If your AI diagnostic tool, clinical decision support engine, or AI-powered therapeutic app meets the FDA's definition of a medical device — and increasingly, AI-powered software does — you need FDA clearance before you can legally market it. This guide walks through the four questions every health tech founder building AI products must answer: (1) does your software trigger FDA device classification, (2) does the Clinical Decision Support exemption apply, (3) which regulatory pathway do you need, and (4) how the FDA's Predetermined Change Control Plan lets adaptive AI models evolve after clearance.

If you are also navigating telehealth prescribing rules and state medical licensing, our guide to telehealth cross-state licensing compliance covers the provider-side regulatory stack that complements the device-side framework here. And if you are procuring AI models from third-party vendors — as many health tech companies do — our guide to AI vendor agreement clauses covers the contract provisions you need before signing.

What Counts as Software as a Medical Device (SaMD)?

The FDA adopts the International Medical Device Regulators Forum (IMDRF) definition of Software as a Medical Device: "software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device." The critical phrase is "medical purpose." Under the Federal Food, Drug, and Cosmetic Act, a device is an instrument, apparatus, implement, machine, or other article that is "intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease" or that "affects the structure or any function of the body."

For AI health tech founders, the operative test is intended use — not what your software does, but what you say it does. The FDA determines intended use by looking at labeling, advertising, promotional statements, oral and written statements, and any other relevant evidence. If your marketing materials say your AI app "detects diabetic retinopathy," that is a diagnostic claim, and your software is a medical device. If you say it "helps users track wellness metrics," you may stay outside the device definition — but only if the claim is genuinely limited to wellness, not a thinly veiled diagnostic assertion.

This is not a fine line. It is a bright line that most founders cross inadvertently through marketing copy, investor decks, or app store descriptions. The moment you claim your AI software diagnoses, treats, prevents, or mitigates a disease or condition, you are in FDA territory — regardless of how the underlying technology works.

The Clinical Decision Support Exemption: Four Criteria

Not all clinical decision support software is a medical device. Section 3060(a) of the 21st Century Cures Act, enacted in December 2016, amended the FD&C Act to exclude certain decision support software from the device definition. The FDA's Clinical Decision Support Software guidance, finalized in January 2026, clarifies which CDS functions fall outside FDA jurisdiction through a four-criteria test.

To qualify as Non-Device CDS, your software must meet all four of the following criteria:

1. The software does not acquire, process, or analyze a medical image or signal from an in vitro diagnostic device. If your AI processes imaging data (X-rays, retinal scans, dermatology photos) or lab results, this criterion fails, and your software is a device.
2. The software displays, analyzes, or prints medical information. This means information that would typically be communicated to or by a healthcare professional — not raw patient-generated data.
3. The software provides recommendations, information, or a clinical report to a healthcare professional — not an autonomous diagnosis. The recommendation must be one that the professional can independently review and not rely on as the sole basis for treatment decisions.
4. The software provides the basis of its recommendations such that the professional can independently review the underlying logic. If your AI is a black box that outputs a diagnosis without explaining its reasoning, this criterion fails. The professional must be able to understand why the software made its recommendation.

The practical implication: if your AI-powered app is designed for patient self-management, provides autonomous diagnoses, or processes medical images, the CDS exemption will not save you. IDx-DR, the first FDA-cleared autonomous AI diagnostic system for diabetic retinopathy, was cleared precisely because it makes a diagnosis without physician involvement — meaning it cannot meet criterion three and is unambiguously a device.

Three Regulatory Pathways: 510(k), De Novo, and PMA

Once you determine your AI software is a medical device, the next question is which premarket pathway applies. The FDA offers three primary routes, each tied to the device's risk classification.

510(k) Premarket Notification: For Predicate-Matched Devices

The 510(k) pathway is the most common route for moderate-risk devices. You must demonstrate that your device is "substantially equivalent" to a legally marketed predicate device — meaning it has the same intended use and similar technological characteristics. For AI/ML-based SaMD, the 510(k) pathway works when a comparable AI diagnostic tool has already been cleared. Most AI-enabled radiology tools cleared by the FDA have gone through 510(k), comparing against previously cleared computer-aided detection systems. The 510(k) is generally faster and less expensive than the other pathways, but it requires a predicate — if no similar device has been cleared, you cannot use this route.

De Novo Classification: For Novel Moderate-Risk Devices

The De Novo pathway is for novel devices of low to moderate risk where no valid predicate exists. The De Novo request creates a new classification regulation, meaning future devices with similar characteristics can follow the 510(k) pathway against your device as a predicate. IDx-DR was cleared through a De Novo classification request (DEN180001) because no prior autonomous AI diagnostic device existed to serve as a predicate. For AI health tech founders building a genuinely novel type of diagnostic or therapeutic tool, De Novo is often the correct pathway — but it requires more documentation and review time than a 510(k).

Premarket Approval (PMA): For High-Risk Devices

PMA is the most rigorous pathway, required for Class III high-risk devices that support or sustain human life, are of substantial importance in preventing impairment of human health, or present a potential unreasonable risk of illness or injury. PMA requires clinical data demonstrating safety and effectiveness, typically through clinical trials. For AI-based SaMD, PMA is rare — most software-based devices are classified as Class II (moderate risk) — but it may apply to AI therapeutic apps that directly deliver treatment, such as AI-powered digital therapeutics that administer cognitive behavioral therapy for serious mental health conditions. PMA is the most time-consuming and expensive pathway, often requiring multi-site clinical studies and an FDA advisory panel review.

Predetermined Change Control Plans for Adaptive AI

The FDA's traditional device regulation framework assumes that a device is static — it is cleared once, and it does not change. AI breaks that assumption. Machine learning models can continue learning after deployment, and even models that do not continuously learn will be updated, retrained, and improved. The FDA's Predetermined Change Control Plan (PCCP) guidance, finalized in August 2025, is the agency's framework for regulating AI that evolves after clearance.

A PCCP is submitted as part of your marketing application (510(k), De Novo, or PMA) and describes three things:

• Planned modifications: The specific types of changes you anticipate making to the AI model after clearance — for example, retraining on new data, updating the model architecture, or expanding the indication.
• Modification protocol: The methodology you will use to develop, validate, and implement those changes, including how you will assess the impact on safety and effectiveness.
• Impact assessment: An evaluation of how the planned modifications could affect the device's performance and risk profile.

If the FDA reviews and approves your PCCP, you can implement the described modifications without submitting a new marketing application for each change. This is a significant structural shift: it is the first FDA framework that contemplates a device that changes after approval without requiring a new premarket review each time. For AI health tech founders, this means you should build your product roadmap with the PCCP in mind from the beginning — anticipating which model parameters you will need to update and designing your validation infrastructure to support those updates within the approved plan.

The PCCP guidance applies across all three premarket pathways — 510(k), De Novo, and PMA — meaning regardless of how your device is classified, you can build a change control plan into your initial submission. The FDA reviews the PCCP as part of the marketing submission to ensure continued safety and effectiveness without necessitating additional submissions for each modification described in the plan.

For a broader framework on AI governance — including vendor management and policy infrastructure that complements your FDA compliance strategy — our guide to building an AI use policy covers the organizational side of deploying AI responsibly.

Real-World Example: IDx-DR

The FDA's 2018 clearance of IDx-DR (De Novo request DEN180001) remains the clearest illustration of how autonomous AI diagnostic software navigates the device classification framework. IDx-DR is an AI system that autonomously analyzes images of the retina to detect diabetic retinopathy — without a physician interpreting the results. It makes a clinical determination on its own and provides a diagnostic output directly to the patient's care team.

Three things made IDx-DR a medical device requiring FDA clearance: (1) it processes medical images (retinal scans), failing CDS criterion one; (2) it provides an autonomous diagnosis without requiring a physician to independently review the AI's reasoning, failing CDS criterion three; and (3) its intended use statement explicitly claims diagnostic capability. IDx-DR went through the De Novo pathway because no predicate device existed, and its clearance created a new classification that subsequent autonomous AI diagnostic systems can reference.

The lesson for founders: if your AI app makes a diagnosis or treatment recommendation autonomously — without requiring a healthcare professional to independently evaluate the AI's reasoning — you are building a medical device. The CDS exemption is not available to you, and you need to plan for FDA clearance from day one. The FDA's growing list of cleared AI-enabled devices, which now spans radiology, cardiology, neurology, and other specialties, demonstrates that the agency has a workable pathway for AI diagnostics — but only for companies that engage with the regulatory process before launch.

Actionable Next Steps

1. Audit your intended use statements. Review every public-facing description of your product — app store listing, website copy, investor deck, marketing materials, and internal product specifications. Every diagnostic, treatment, or prevention claim triggers FDA device classification. If you intend to market your app as a wellness tool, your claims must be genuinely limited to wellness, not thinly veiled diagnostic assertions.
2. Run the four-criteria CDS test. If your software provides clinical decision support, walk through all four CDS exemption criteria with your regulatory counsel. If your AI processes medical images, provides autonomous diagnoses, or acts as a black box that professionals cannot independently review, the exemption will not apply, and you need a premarket strategy.
3. Determine your risk classification and pathway. Work with regulatory counsel to classify your device (Class I, II, or III) and identify the correct pathway: 510(k) if a predicate exists, De Novo for novel moderate-risk, or PMA for high-risk. The pathway determines your timeline, cost, and clinical data requirements.
4. Design your PCCP from the beginning. If your AI model will evolve after clearance — and most will — build the Predetermined Change Control Plan into your initial regulatory strategy. Document the modifications you anticipate, the validation methods you will use, and the impact assessment framework. Submitting a PCCP with your initial marketing application is far easier than retrofitting one after clearance.
5. Engage FDA regulatory counsel early. The cost of restructuring your product to stay outside device classification — or preparing for a 510(k) or De Novo submission — is a fraction of the cost of receiving an FDA enforcement letter after launch. If you are building AI diagnostic tools, clinical decision support, or AI-powered therapeutic apps, bring regulatory counsel into your product roadmap before you write your first line of clinical validation code.