A practical guide to the FDA line between a wellness app and a regulated medical device, how AI features change it, and what to do if your app crosses over
H1: Is Your Healthcare App a Medical Device? The FDA SaMD Line (2026)
Most teams building a health app assume the FDA has nothing to do with them. They are shipping a tracker, a coaching tool, or a way to book a visit, so medical device rules feel like someone else’s problem. Then a hospital procurement team, an investor’s diligence lawyer, or the FDA itself asks a harder question, and the answer decides whether the product ships as planned or needs months of clearance work first.
The line between a wellness app and a regulated medical device is narrower than most founders expect, and in 2026, it moved twice. On January 6, the FDA reissued its two most relevant guidance documents, one on general wellness products and one on clinical decision support software, and both changed where the line sits. If you are scoping a healthcare app right now, you want to know which side of that line you are on before you write the first user story, not after a launch date is public.
H2: What the FDA mean by Software as a Medical Device
The FDA borrows its core definition from the International Medical Device Regulators Forum: software intended to be used for one or more medical purposes that perform those purposes without being part of a hardware medical device. Recent guidance often calls this a device software function, but the idea holds. If your software carries out a medical purpose on its own, on a phone, a tablet, or a cloud server, it can be a device in the FDA’s eyes even though there is no hardware in the box.
A second category is worth separating out. Software built into a piece of hardware, like the firmware that runs an insulin pump, is regulated as part of that device. Your standalone app is judged on its own. That distinction matters because a general-purpose app on an app store gets no automatic exemption. The platform is ordinary. The purpose is what the FDA looks at.
H2: Intended use is the deciding factor
The same feature can be a device or not, depending on what you claim it does. A heart-rate reading offered to help someone pace a workout sits in one place. The same heart-rate reading offered to flag a possible arrhythmia sits in another. The FDA’s device definition turns on purpose: software meant to diagnose, cure, mitigate, treat, or prevent a disease or condition falls inside the definition. Software that logs, displays, or educates without making a clinical claim usually falls outside it.
This is why your marketing copy, your onboarding screens, and your app store description carry regulatory weight. If the product page says the app detects atrial fibrillation, you have made a diagnostic claim, and the FDA reads that claim as your intended use. Teams get caught here more than anywhere else. The engineering was careful. The landing page was not.
H2: Where wellness apps stay outside FDA rules
Plenty of health apps live in a zone the FDA has chosen not to police. Its general wellness policy covers low-risk products meant to support a healthy lifestyle with no tie to a specific disease. A sleep-habit tracker, a fitness coach, a stress-reduction timer: these encourage general health, carry little risk, and the FDA does not treat them as devices or enforce device rules against them.
The January 2026 update widened this zone in a way that matters for hardware-adjacent apps. Non-invasive products that estimate physiologic signals such as heart rate, blood glucose, or even blood pressure can now claim general wellness status, provided they are intended only for wellness, stay noninvasive and low risk, and avoid any disease, diagnostic, or clinical-management claim. The catch sits in that last clause. In July 2025, the FDA sent a warning letter to a wearable maker whose blood-pressure feature implied hypertension insight, because a blood-pressure reading is hard to separate from a hypertension diagnosis. The 2026 guidance gives more room, but the moment your copy crosses from lifestyle into disease, the wellness shield drops.
H2: How AI features can turn an app into a device
AI features are the fastest way for a calm wellness app to slide into device territory, and the reason sits in one specific rule. When software gives a healthcare professional a recommendation, the 21st Century Cures Act lets it stay outside device regulation only if it meets four conditions. It cannot analyze a medical image or a continuous signal from a sensor. It has to work from the kind of medical information clinicians already use, such as lab results, guidelines, and demographics. It has to support a professional instead of replacing their judgment. And, the condition that trips up AI, it has to let that professional independently review the basis for its recommendation, so they are not leaning on the software as the answer.
A transparent, rule-based tool clears that last bar without trouble. A clinician can see why it fired. A deep-learning model that outputs a risk score with no visible reasoning often cannot clear it, because there is nothing for the clinician to review. The FDA said this plainly in its January 2026 refresh of the clinical decision support guidance: the more a tool behaves like a black box, the more likely the agency treats it as a device. The same update softened a related rule, offering enforcement discretion to tools that surface a single sensible recommendation or a risk score, as long as every other condition still holds. So the 2026 news cuts both ways. There is more room to ship reviewable AI and a sharper edge under models that hide their work.
H2: Device risk classes and clearance pathways
Once your app is a device, the next question is how much scrutiny it draws, and that depends on risk. The FDA sorts devices into three classes. Class I covers low-risk tools and carries the lightest requirements. Class II covers moderate-risk software, the band most clinical apps land in, and usually calls for a 510(k) submission that shows your product is substantially equivalent to one already on the market. Class III covers the highest-risk software, the kind that drives a critical treatment decision, and it demands premarket approval with clinical evidence behind it.
A newer app with no close predecessor has a fourth route. The De Novo pathway exists for lower-risk devices that are genuinely novel, so a first-of-its-kind tool avoids being forced into the Class III process by default. Picking the right lane early shapes your timeline, your evidence plan, and your budget, which is why this decision belongs at the start of a build.
H2: What FDA regulation changes about how you build
Becoming a regulated device changes how you build, not only what you file. You take on design controls, which means documented requirements, risk management, and verification and validation running alongside development instead of bolted on before launch. You maintain a quality system. As of February 2, 2026, that system follows the FDA’s new Quality Management System Regulation, which aligns the old 21 CFR Part 820 rules with the international ISO 13485 standard, so a team building for the US and for markets abroad now works from a closer-to-one rulebook.
None of this is a reason to avoid building a device. It is a reason to know early. Design controls added from the first sprint cost far less than the same controls reconstructed after the fact, when engineers are reverse-documenting decisions nobody wrote down. The expensive version of this story is always the retrofit.
H2: Six questions to check if your app is a device
Run your product through these before your next planning cycle:
- Does the app claim to diagnose, treat, prevent, or monitor a specific disease anywhere in the product or its marketing?
- Does it analyze a medical image or a continuous signal from a sensor, rather than a discrete reading a clinician already uses?
- Does an AI feature produce a recommendation a clinician cannot trace or explain?
- Do any outputs mimic clinical values, such as a blood-pressure number or a glucose level, without validation behind them?
- If the software is wrong, could a patient be harmed or a treatment decision be misdirected?
- Would a hospital or payer buyer ask for FDA clearance during procurement?
A yes on the first five points pulls you toward device territory. A yes on the sixth means the market will treat you as regulated, whether you agree, so the paperwork question arrives either way.
H2: What to do if your app is a regulated device
If those questions put you on the device side, the work is manageable with the right plan. Map your intended use and your claims first, because that single document drives your class, your pathway, and your evidence. Decide between a 510(k), a De Novo request, and premarket approval before you lock the architecture. Build design controls and your quality system into the first sprint. And bring in people who have carried a healthcare product through clearance before, since the gap between a six-month submission and an eighteen-month one usually traces back to decisions made in week one.
This is the point where the team you build with matters. Companies shipping regulated software tend to work with experienced healthcare mobile app development services rather than a generalist studio that treats FDA pathways as a detail to sort out later, because a partner who has already done design controls, 510(k) evidence, and post-market monitoring will not learn those lessons on your budget.
H2: Ask the device question before you build
The healthcare app that gets built twice is the one that guessed wrong about the FDA. The team assumed wellness, shipped, then met a procurement reviewer or a warning letter that sent them back to redesign around rules they could have planned for. The version that ships once is the one that asked the intended-use question at the start, chose its pathway on purpose, and built to it. In 2026 the FDA gave developers more clarity about where the line sits. The work now is to find your side of it before the code, the claims, and the launch date are already set.