Most AI health apps do not automatically need FDA clearance — what triggers it is your intended use. If your software diagnoses, treats, or drives a clinical decision a clinician can't independently verify, the FDA likely treats it as a medical device (often Software as a Medical Device, or SaMD) requiring 510(k) clearance, De Novo authorization, or PMA. Wellness, administrative, and many provider-facing decision-support tools stay non-device. Scope claims carefully and you can validate first, regulate later.
This article is general information for founders, not legal or regulatory advice. FDA classification is fact-specific. Engage qualified regulatory counsel before making market decisions. SpeedMVPs builds compliant, HIPAA-ready MVPs and works alongside your regulatory advisors — we don't replace them.
When does software become a medical device?
The dividing line is intended use, not the technology. The same large language model can power a regulated diagnostic tool or an unregulated wellness coach — what matters is what you claim it does and how a user relies on it. The FDA looks at your marketing, labeling, and the function you actually ship.
Under the FD&C Act, software is a device when it's intended to diagnose, cure, mitigate, treat, or prevent a disease, or to affect the structure or function of the body. The 21st Century Cures Act later carved out several software functions — including some general wellness, administrative, and clinical decision support tools — from the device definition.
So three rough buckets exist:
- Non-device: general wellness ("track your steps and sleep"), administrative tools, EHR data display, and qualifying clinical decision support.
- Device, lower risk: software that informs or drives clinical management for non-serious conditions.
- Device, higher risk: software that diagnoses or drives treatment for serious or critical conditions, especially without a clinician in the loop.
Getting this boundary right early is the single highest-leverage regulatory decision you'll make. It shapes your roadmap, your budget, and how fast you can ship. Our pillar guide on healthtech MVP development walks through how this fits the broader build, and our overview of healthcare AI use cases maps which applications tend to land in which bucket.
What is Software as a Medical Device (SaMD)?
SaMD is software intended for a medical purpose that performs that purpose on its own, without being part of a hardware medical device. An app that reads a skin photo and flags a likely melanoma is SaMD. Firmware running inside an infusion pump is software in a device, not SaMD.
The international IMDRF framework, which the FDA references, categorizes SaMD into four levels based on two axes: the seriousness of the condition (non-serious, serious, critical) and how the output is used (inform clinical management, drive clinical management, treat or diagnose).
| SaMD significance of information | Non-serious condition | Serious condition | Critical condition |
|---|---|---|---|
| Inform clinical management | Category I (lowest) | Category II | Category III |
| Drive clinical management | Category II | Category III | Category III |
| Diagnose or treat | Category II | Category III | Category IV (highest) |
Higher IMDRF categories generally map to higher FDA device classes and heavier evidence requirements. A Category I "inform" tool for a minor condition is a very different regulatory animal than a Category IV tool that diagnoses a life-threatening disease. If your roadmap involves imaging analysis, our deep dive on the AI medical imaging MVP covers the evidence and validation realities specific to that space.
The clinical decision support (CDS) exemption
Many founders building clinician-facing tools can avoid device status entirely through the CDS carve-out. Under the Cures Act and FDA guidance, software is not a device when it meets all four criteria:
- It does not analyze a signal from an in-vitro diagnostic or a pattern from a signal-acquisition device (so no ECG-waveform or imaging analysis).
- It displays, analyzes, or prints medical information (e.g., guidelines, patient records, peer-reviewed literature).
- It provides recommendations to a healthcare provider (not the patient) about prevention, diagnosis, or treatment.
- It allows the provider to independently review the basis for the recommendation, so they don't rely primarily on the software.
That fourth point is where many AI tools fail. If your model outputs a recommendation the clinician can't realistically scrutinize — a "black box" score with no explainable basis — the FDA is likely to treat it as a device. Transparent reasoning, cited sources, and provider-reviewable logic keep you on the non-device side. Our guide to clinical decision support software development details how to design for that independent-review standard from the start.
Note: the CDS exemption applies to provider-facing tools. Patient-facing software that tells someone what disease they have or what drug to take generally cannot use this carve-out and is far more likely to be regulated.
FDA device classes and the pathways
If your software is a device, the FDA sorts it into one of three risk classes, each with a typical pathway:
| Class | Risk | Typical pathway | Example software |
|---|---|---|---|
| Class I | Low | Often exempt; general controls | Simple data-display or administrative tools |
| Class II | Moderate | 510(k) clearance (or De Novo if no predicate) | Many AI triage, monitoring, and analysis tools |
| Class III | High | Premarket Approval (PMA) | Software sustaining or supporting life |
510(k): substantial equivalence
The 510(k) is the most common path for AI startups, used for Class II devices. You demonstrate your device is "substantially equivalent" to a legally marketed predicate device with the same intended use and similar technological characteristics. You're not proving the device is safe from scratch — you're proving it's as safe and effective as something already cleared.
Realistic 2026 timelines: preparing a strong 510(k) for AI software often takes 6-12 months (clinical validation, software documentation, cybersecurity), followed by an FDA review that commonly runs around 3-6 months. Out-of-pocket consulting, testing, and submission costs frequently land in the low-to-mid six figures, and more for novel claims.
De Novo: when there's no predicate
If your software is genuinely novel and no predicate exists, you can't file a 510(k). The De Novo pathway lets the FDA create a new classification for a low-to-moderate-risk device. It's heavier than a 510(k) but lighter than a PMA, and a granted De Novo can then serve as a predicate for competitors — so being first has a cost and a moat.
PMA: the heaviest path
Class III devices that support or sustain life go through Premarket Approval, which requires substantial clinical evidence and is the most time- and capital-intensive route. Most seed-stage startups deliberately scope away from PMA territory for their first product.
Predetermined Change Control Plans for AI
AI models that learn and update create a unique FDA problem: a cleared device is supposed to be the thing that was cleared, but your model might improve next quarter. The FDA's answer is the Predetermined Change Control Plan (PCCP) — a section of your submission that pre-authorizes specific, bounded model changes (like periodic retraining on new data) without requiring a brand-new submission each time.
A PCCP defines what can change, the methods and data you'll use to validate each change, and the performance limits the model must stay within. For any AI product you intend to iterate on — which is most of them — designing the PCCP early shapes your data pipeline, monitoring, and MLOps. This is one reason picking the right architecture matters; see our take on the best tech stack for healthtech apps and the broader best tech stack for AI MVPs in 2026.
How to scope an MVP that avoids premature regulatory burden
The expensive mistake is building a fully regulated product before you know anyone wants it. The smarter sequence is to validate demand with a non-device or exempt MVP, then add regulated claims once the market is proven and you've raised the capital to fund a submission.
Practical ways to stay non-device while you learn:
- Narrow your claims. "Organize your symptoms before a doctor visit" is wellness; "diagnose your condition" is a device. Words matter as much as code.
- Keep a human in the loop. Provider-reviewable, explainable outputs help you qualify for the CDS exemption.
- Defer the regulated module. Ship the workflow, scheduling, engagement, or documentation layer first; bolt on the diagnostic engine later behind a clearance.
- Don't market beyond your clearance. Off-label promotion can turn a non-device into an enforcement problem.
This is exactly how we approach builds at SpeedMVPs: ship a compliant, HIPAA-ready MVP in 2-3 weeks that proves the use case without taking on premature regulatory load, with direct developer access so claims and architecture stay aligned. Our guides to validating a healthtech startup idea and the broader scope an AI MVP before you build framework go deeper on sequencing. For full implementation help, our medical app development services overview shows what compliant delivery looks like end to end.
De-risking FDA requirements before you write a line of code
Regulatory rework is the most expensive kind. A few habits dramatically cut that risk:
- Write the intended use statement first. One precise paragraph that drives classification, claims, and architecture. Revisit it whenever the product changes.
- Stand up a light quality system early. Design controls and a design history file are far cheaper to maintain from day one than to reconstruct later.
- Use the Q-Sub (Pre-Submission) program. The FDA offers free meetings to discuss classification and study design before you submit. Founders consistently say these conversations save months.
- Budget honestly. Map the time and cost of your likely pathway into your fundraising plan; our healthcare app development cost breakdown and general how much an AI MVP costs guide help set expectations.
- Hire experienced builders. Engineers who've shipped HIPAA-ready, audit-friendly systems make the eventual submission smoother. See how to hire AI developers for what to look for.
Again: this is general guidance. Classification and submission strategy should be confirmed with qualified FDA regulatory counsel and, where clinical claims are involved, appropriate clinical experts.
Book a free discovery call
Figuring out whether you need FDA clearance — and how to ship something valuable before you do — is a scoping problem as much as a regulatory one. SpeedMVPs builds compliant, HIPAA-ready AI MVPs in 2-3 weeks with fixed pricing and direct developer access, and we'll help you draw the line between your validation MVP and your regulated roadmap. Book a free discovery call to talk through your intended use and architecture, explore our AI MVP Development service, or estimate your build with the AI MVP Cost Calculator.
