Is My App a Medical Device? The FDA Test Explained

The FDA doesn't look at your code, your tech stack, or how sophisticated your algorithm is. It looks at intended use: what you say your app is for, and whether that use is to diagnose, treat, cure, mitigate, or prevent a disease or health condition. Two apps built on nearly identical software can end up on opposite sides of that line, because the line is drawn by labeling and claims, not architecture.

Quick Answer: The FDA applies what's commonly called the intended-use test — it reads your labeling, marketing claims, and how the software is meant to function, not your codebase. An app that analyzes patient-specific data to inform a specific diagnosis or treatment decision tends to draw more regulatory attention than one offering general wellness or informational content. This article explains that framework. It is not, and cannot be, a determination of your specific app's status — that call belongs to FDA regulatory counsel or a regulatory affairs specialist reviewing your actual product.

If you're validating a health-adjacent idea from the ground up — market, business model, and regulatory exposure together, not the regulatory question in isolation — the Complete Guide to Startup Idea Validation is a good place to see how this question fits into the bigger picture before you commit months to a build.

How the FDA Decides: Intended Use and Claims

Intended use is the entire test. The FDA determines whether software meets the legal definition of a medical device by looking at what you represent it as being for — in your labeling, your marketing copy, your app store listing, even your sales conversations — not by inspecting the underlying code. Two teams could ship functionally identical software and land in different places purely because of how they described it.

A handful of factors tend to push software toward being read as a medical device. None of them is decisive alone, and there's no point system that adds up to a definitive answer, but they're worth knowing before you write a line of marketing copy:

• Does the app analyze patient-specific data — symptoms, images, vitals, lab values — to generate an output about one specific person's health, rather than presenting general reference information?
• Does the output speak to diagnosis, treatment selection, or disease prevention, naming a specific disease or condition, rather than staying at the level of general fitness or wellbeing?
• Does a clinician or patient rely on the app's output to make a clinical decision, with limited practical ability to independently review the data behind it?
• Do your marketing claims reference a specific disease, symptom, or medical outcome — even if the underlying software never changes?

The FDA's own guidance in this space spans multiple documents, has been updated over time, and gets interpreted case by case against a specific product's facts. That's exactly why this isn't a self-service determination. If your app touches any of the factors above, the right move is a conversation with FDA regulatory counsel or a regulatory affairs specialist who can evaluate your actual labeling, claims, and functionality — not a generic framework, however well-intentioned.

It's also worth knowing that intended use isn't fixed at launch. A support agent answering "can this diagnose X?" with "yes" in a help article, or a growth team adding a disease-specific claim to a landing page months after ship, can shift how your own product gets read — regardless of what the software itself actually does. Keep product, marketing, and legal aligned on exactly what you're claiming before you claim it, and revisit that alignment every time copy changes.

Common App Types and Where They Generally Land

There's no master list of "device apps" and "non-device apps" — classification depends on your specific labeling and claims, not your category. But looking at how the FDA has approached broad categories of software in its public guidance gives you a useful mental model for where your own idea might sit relative to others.

The pattern across these rows: software that stays at the level of general self-tracking and awareness tends to sit outside the device definition, while software that names a specific disease, drives a specific clinical decision, or narrows a clinician's independent judgment tends to attract more scrutiny. Where your particular app falls on that spectrum — and which pathway, if any, applies — is exactly the question to bring to a regulatory specialist before you lock in your claims or your build roadmap. For a fuller walkthrough of validating a medical-device-adjacent idea before you commit engineering time, see How to Validate a Medical Device Startup Idea.

What Changes If Your App Is a Medical Device

If your app meets the legal definition of a medical device, you generally can't market it until you've gone through an FDA premarket pathway suited to its risk level — and afterward, you carry ongoing regulatory obligations that a purely informational app never has to think about.

There are three pathway names worth knowing at a conceptual level, without treating any of this as a claim about which one applies to you:

• 510(k) — a premarket pathway built around demonstrating your device is substantially equivalent to a device already legally on the market (a "predicate"). It's a commonly used route for lower- to moderate-risk devices that have an existing comparable product to point to.
• De Novo — a pathway for novel, generally low- to moderate-risk devices that don't have an existing predicate to compare against, which creates a new device classification in the process.
• PMA (Premarket Approval) — the most rigorous pathway, generally reserved for higher-risk devices, requiring the FDA to review clinical evidence supporting safety and effectiveness before market entry.

Which of these — if any — applies to your product depends on its specific risk profile, intended use, and classification, and that determination sits with regulatory counsel, not a blog post or a founder's best guess. Getting it wrong in either direction is expensive: underestimating your obligations risks an enforcement problem after you've already gone to market, while overestimating them can send you down a pathway, and a budget, you never actually needed.

Beyond the premarket question, device status changes the operational shape of the company:

• A formal quality management system covering design controls, documentation, and change management — not just a bug tracker and a deploy pipeline.
• Post-market obligations, including adverse event reporting and ongoing monitoring of how the software performs once it's in real-world use.
• Narrower marketing claims: what you can say in your app store listing, on your website, and in sales conversations gets bounded by what your clearance or approval actually supports.
• Downstream effects on fundraising and hiring — investors and enterprise health-system buyers will ask about regulatory status directly, and you'll typically need dedicated regulatory and quality expertise well before headcount planning would otherwise call for it.

None of this makes device status something to avoid at all costs. Plenty of well-funded companies operate successfully as regulated medical device businesses, and clearance itself can become a credibility signal with health-system buyers who won't take an unregulated claim at face value. It does mean the question belongs on your roadmap early, worked through with a regulatory affairs specialist, rather than discovered after a growth team has already shipped a claim the product was never built to support.

Wellness App or Medical Device? The Adjacent Category

Between "clearly not a device" and "clearly a device" sits a category the FDA has separately addressed: general wellness products. These are products intended to support a general state of health or a healthy lifestyle without claiming to diagnose, treat, cure, mitigate, or prevent a specific disease or condition.

Plenty of sleep, stress, and general fitness apps are built and marketed to live inside that category deliberately. But the boundary is thinner than most founders expect. Adding a single disease-specific reference — in an ad, a testimonial, a comparison chart, or even a one-off landing page — can undercut a wellness position and pull the product back into device-question territory, even if the software itself never changed. Third-party review sites, app store category placement, and language other people write about your product aren't fully within your control. The language you choose is, and in this category it matters more than almost any other product decision you'll make.

The distinction between a genuine wellness claim and a device-level claim is nuanced enough to deserve its own deep dive rather than a paragraph here — see Wellness App vs Medical Device: Where Is the Line? for a closer look at where that boundary tends to sit. And if you want the fuller picture of how the FDA's software-specific framework treats products like this regardless of whether they ship on dedicated hardware, What Is Software as a Medical Device (SaMD)? walks through that concept directly.

Key Takeaways

• Intended use, not technology, drives classification. The FDA reads your labeling, marketing claims, and functional description — not your codebase or architecture.
• Patient-specific plus disease-specific is the pattern to watch. Software analyzing an individual's data to inform a specific diagnosis or treatment decision tends to draw more scrutiny than general wellness content.
• Claims can shift your classification after launch. A support answer, a landing page edit, or a testimonial referencing a specific disease can change how your own product gets read.
• Three premarket pathways exist for different risk levels — 510(k), De Novo, and PMA — but which, if any, applies to you is a specific determination, not a self-service checklist.
• Device status brings ongoing obligations, not a one-time approval. A quality management system, post-market monitoring, and narrower marketing claims all follow.
• General wellness products are a real, separate category, but the line between a wellness claim and a device-level claim is thinner than most founders assume.
• This is a determination for FDA regulatory counsel or a regulatory affairs specialist, made specifically for your product's facts — not inferred from an article like this one.

Frequently Asked Questions

Does the FDA regulate every health or wellness app?

No. The FDA generally doesn't regulate software that stays within general wellness — supporting a healthy lifestyle without claiming to diagnose, treat, cure, mitigate, or prevent a specific disease. Software that crosses into disease-specific, diagnostic, or treatment-decision territory is where device-level questions start. Where your specific app falls needs a case-by-case review from a regulatory specialist, not a blanket rule.

What's the actual difference between a wellness app and a medical device app?

It generally comes down to whether the app's claims reference a specific disease or medical condition, and whether its output is meant to inform a diagnosis or treatment decision rather than general self-awareness. It's a claims-and-function question, not a features question — two apps with nearly identical functionality can land differently depending on how they're labeled and marketed.

Can I determine on my own whether my app is a medical device?

You can build useful intuition using the intended-use framework — what your app's output claims to do, and whether it touches diagnosis, treatment, or disease prevention for a specific patient. But the actual determination is a fact-specific legal and regulatory judgment that depends on your exact labeling, claims, and functionality. Treat any self-assessment as a reason to bring in FDA regulatory counsel, not as a final answer.

What happens if I market health claims my app hasn't cleared with the FDA?

Marketing a product with disease-specific, diagnostic, or treatment claims it hasn't gone through the appropriate FDA pathway for creates real regulatory risk, including possible enforcement action, and can complicate fundraising and enterprise sales once a buyer's compliance team asks about your regulatory status. If there's any chance your claims read as device-level, the right move is to get a regulatory affairs specialist involved before you ship the claim, not after.