Do I Need FDA Clearance for My Health App? A Decision Framework

The biggest mistake health app founders make is assuming “it’s just software, so the FDA doesn’t care.” That’s how you end up with warning letters, frozen pilots, and investors quietly backing away.

You don’t need FDA clearance for every health app. But if you’re wrong about yours, it can kill your company.

Let’s walk through a practical, brutally clear decision framework: do you need FDA clearance for your health app, yes or no?

---

Step 1: Know What the FDA Actually Regulates

First line in the sand: the FDA regulates “medical devices,” not “apps.”

Your app is regulated if and only if it meets the legal definition of a medical device.

Stripped down, that definition is:

An instrument, machine, implant, in vitro reagent, or similar article (including a component, part, or accessory), intended to diagnose, treat, cure, mitigate, or prevent disease or affect the structure or function of the body, without working primarily through chemical action or metabolism.

Software that qualifies is called Software as a Medical Device (SaMD).

So the core question is intended use. Not what you think it does. Not what users might do with it. What you say it does. In your:

• App store description
• Website copy
• Sales decks
• Marketing and investor materials
• In‑app onboarding and prompts

If anywhere you’re claiming diagnosis, treatment, prediction, or high‑stakes clinical decision support, you’re walking straight into FDA territory.

---

Step 2: Quick Triage – Probably NOT FDA, Probably FDA, Definitely FDA

Use this as a gut-check. We’ll refine it after.

Category	FDA Likelihood	Example
Wellness / Lifestyle	Low	Meditation app, step counter
Medical Reference	Low–Medium	UpToDate-style guideline viewer
Consumer Health Tracking	Medium	Ovulation tracker, glucose log
Clinical Decision Support (CDS)	Medium–High	Risk calculator for stroke
Diagnostic / Monitoring	High	AFib detection, sleep apnea screening
Treatment / Therapy	High	Digital CBT for MDD, insulin dosing

If your gut says “high,” assume FDA until proven otherwise.

---

Step 3: Apply the FDA’s Digital Health Buckets

The FDA’s actual policies are scattered across guidance documents, but you can mentally sort apps into 4 buckets:

1. Low-risk general wellness – the FDA says, “We don’t care. Go away.”
2. Enforcement discretion – technically a device, but so low risk they usually don’t enforce requirements.
3. Device – but meets a specific carve‑out (e.g., non‑device clinical decision support).
4. Regulated medical device – you’re in 510(k) / De Novo / PMA land.

Bucket A: General Wellness – Safest Ground

These apps:

• Encourage a healthy lifestyle
• Don’t claim to diagnose, treat, or mitigate a specific disease
• Tie outcomes to general health, not a named condition

Examples that are typically NOT regulated:

• Step counters
• Sleep hygiene trackers (“improve your sleep habits,” not “treat insomnia”)
• Meditation apps (“reduce stress,” not “treat GAD”)
• Nutrition apps (“eat healthier,” not “manage type 2 diabetes”)

Change the words and you change the regulatory status. “Supports heart health” might be OK. “Prevents heart attack” is not.

If your entire product can genuinely live in this bucket and you’re disciplined about marketing language, you likely don’t need FDA clearance.

---

Step 4: The Four Killer Questions (Decision Framework)

Here’s the cleanest way I know to decide if you’re moving into FDA territory.

If you answer YES to any of these, you probably have a medical device:

1. Does your app claim to diagnose or detect a disease or condition?

   • “Screens for atrial fibrillation”
   • “Detects diabetic retinopathy”
   • “Identifies skin cancer from photos”
     These are diagnostic claims. That’s device land.

2. Does your app guide or change treatment decisions?

   • Dosing calculators (especially insulin, anticoagulants, chemo)
   • “Recommends treatment options based on patient data”
   • “Prioritizes which patient needs urgent intervention”
     If clinicians are relying on your tool to choose or adjust therapy, FDA cares.

3. Does your app provide therapy or directly modify behavior to treat a condition?

   • Prescription digital therapeutics (reSET, Somryst style)
   • PTSD, depression, substance use treatment apps
   • ADHD treatment games (like EndeavorRx)
     These are not “wellness.” They’re therapy.

4. Is your app marketed to clinicians or sold into clinical workflows as a decision tool?

   • “For use in hospitals”
   • “Supports radiologists in detecting lung nodules”
   • “Improves ED triage safety”
     You’re telling FDA, “Doctors will use this to care for patients.” Expect attention.

If you hit zero of these, and your claims stay vague and wellness‑y, you may be in a safe zone.

If you hit one or more, keep reading—because you’re likely in Device bucket.

---

Step 5: The Clinical Decision Support (CDS) Trap

This is where a lot of smart founders get burned.

They read about “non‑device CDS” and assume, “Our risk calculator is exempt.” Usually wrong.

The current FDA rule for non‑device CDS has four key criteria. To be NON‑device, your software must:

1. Not be for “time‑critical” or “serious” conditions where an error could cause significant harm.
   Helping pick between cancer regimens? Not exempt.

2. Be a tool that supports, not replaces, clinician judgment.
   Think: “Here’s information,” not “Do this.”

3. Allow the clinician to independently review the basis for the recommendations.
   Your logic must be transparent:

   • Show equations
   • Show data sources
   • Let the user see why you recommended X

4. Be intended for use by healthcare professionals (not patients directly).

If you fail any of those, your CDS is likely a regulated medical device.

You can absolutely design your product to fit this carve‑out. I’ve seen teams:

• Switch from black‑box AI to explainable scores
• Expose risk models and inputs explicitly
• Rewrite marketing language from “recommends treatment” to “displays risk scores and relevant guidelines”

That move alone can flip you from needing a 510(k) to not being a device at all.

---

Step 6: Risk vs Benefit of “Staying Non‑FDA”

Sometimes you can duck FDA. Sometimes you shouldn’t.

Here’s the tradeoff in plain language:

Perceived vs Real Tradeoffs of FDA Regulation

Category	Value
Speed to Market	90
Sales to Health Systems	30
Reimbursement Potential	20
Investor Confidence	40
Clinical Risk Management	25

(High numbers here are “easier” if you avoid FDA.)

Reality:

• Faster to market without FDA. Sure.
• Selling into hospitals is harder without some form of regulatory or clinical validation.
• Reimbursement (CPT codes, payers, PBMs) often expects FDA clearance for anything that smells like a therapeutic or diagnostic.
• Serious investors in digital therapeutics and AI diagnostics actually prefer a clear regulatory path, not a regulatory dodge.

If your whole value prop is “we change clinical outcomes,” pretending you’re just a wellness app is a short‑term hack and a long‑term liability.

---

Step 7: If You ARE a Device – What Class Are You?

You don’t need to be a regulatory lawyer, but you do need a rough sense of device classes:

• Class I – Low risk, often exempt from premarket review
• Class II – Moderate risk, usually needs 510(k) clearance
• Class III – High risk, life‑supporting, often needs PMA (rare for early‑stage software)

Most serious SaMD today is Class II. A few cutting‑edge AI systems with no predicate end up in De Novo.

Think in practical terms:

• ECG analysis app: very likely Class II
• Triage tool for low‑acuity conditions: could be Class II or under enforcement discretion
• Prescription digital therapeutics: usually Class II

The playbook for most startups: 510(k) or De Novo Class II SaMD.

---

Step 8: Cheap, Concrete Ways to Get Clarity Early

Here’s what you can do in the next 2–4 weeks that won’t break your burn:

1. Scrub your marketing language.

   • Remove “diagnose,” “detect,” “treat,” “prevent.”
   • Replace with “help track,” “support discussions with your clinician,” etc.
     That alone can move you a full bucket down in risk.

2. Create an “intended use” one‑pager.

   • Who is the intended user? (patient, clinician, caregiver)
   • What condition (if any) is targeted?
   • What action do you expect them to take based on the app?

3. Map your app to a known device or non‑device category.

   • Search the FDA databases for similar cleared products (510(k) database for “SaMD,” “ECG analysis,” “digital therapeutic”).
   • Look at whether those products are Class I, II, or III.

4. Do a 1–2 hour consult with a real regulatory expert.
   Not your friend who “once did a Q-sub.” Someone who’s actually taken digital health products through clearance.

---

Step 9: Don’t Ignore Data Privacy and Other Landmines

Even if you dodge FDA, you’re not out of the woods.

You still need to think about:

• HIPAA (if you’re a covered entity / business associate)
• State privacy laws (CCPA, etc.)
• FTC enforcement (if your claims are misleading)
• State medical board issues (if you’re blurring into telemedicine)

Seen this play out multiple times: team proudly avoids FDA, then gets hammered by the FTC for overstated claims or sloppy data practices.

FDA clearance ≠ your only regulatory concern. It’s just the biggest binary question early.

---

A Simple Flow You Can Actually Use

Here’s a mental flowchart you can sketch on a whiteboard with your team:

Health App FDA Decision Framework

Step	Description
Step 1	Describe intended use
Step 2	Likely non device
Step 3	Likely medical device
Step 4	Mention diagnose treat prevent or guide therapy
Step 5	Is it general wellness only
Step 6	Used by clinicians for clinical decisions
Step 7	Used by patients to manage disease

If you land in “Likely medical device,” assume you’ll need some form of FDA engagement unless a qualified expert tells you otherwise after reviewing your specifics.

---

Common Real-World Scenarios (and Where They Land)

Scenario 1: “Patient-facing diabetes app that ‘helps manage blood sugar’”

• Tracks glucose readings
• Shows graphs
• Sends reminders
• Suggests: “Talk to your doctor when values are above X”
• No dosing suggestions, no therapy changes

If you stay careful with language, you might avoid device status or land in low‑risk territory. The moment you start suggesting precise insulin doses? You’re a device.

Scenario 2: “AI radiology triage for chest X-rays”

• Flags suspected pneumonia, pneumothorax, or nodules
• Reorders worklist based on urgency
• Markets itself as improving detection and workflow

This is classic SaMD, generally Class II. Expect 510(k) or De Novo. Trying to call this “non‑device CDS” is fantasy.

Scenario 3: “CBT-based digital therapeutic for insomnia, prescribed by clinicians”

• Structured CBT modules
• Clinical trials
• Prescription workflow
• Claims to “treat insomnia and improve sleep onset latency”

You’re in full‑fledged digital therapeutic land. FDA, clinical evidence, the works.

---

Don’t Let Residency Brain Hurt You Here

If you’re fresh out of residency or a few years into practice, you’ve got a clinical mindset that actually helps here.

Ask yourself this:

“If a resident used this app to make a decision on rounds, and the app was wrong, could a patient be harmed?”

If the answer is yes, and that harm could be more than trivial, you’re probably in medical device territory.

Hospitals, insurers, and serious enterprise customers increasingly think the same way. They want tools that are either:

• Clearly non‑device, low‑risk wellness tools, or
• Clearly device, cleared or on a credible regulatory path

The mushy middle—“We’re kind of clinical, but we’re hoping no one asks hard questions”—is where startups go to die in procurement purgatory.

---

FAQ: 7 Questions Founders Keep Asking About FDA and Health Apps

1. If my app is just for clinicians, not patients, do I still need FDA clearance?
   Yes, potentially. FDA absolutely regulates clinician‑facing tools if they diagnose, monitor, or guide therapy. Being clinician‑only can help qualify you for the non‑device CDS carve‑out, but only if you meet all the criteria (non‑serious condition, explainable logic, supports rather than replaces judgment). Don’t assume “for doctors only” is a free pass.

2. Can I launch without FDA and get clearance later?
   You can, but it might backfire. If from day one your claims are clearly diagnostic or therapeutic, you’re technically marketing an unapproved device. That can complicate future submissions. A saner play: either (a) scope V1 as true wellness / non‑device CDS, or (b) commit to a regulatory path and build it into your roadmap and fundraising story.

3. What if users or doctors use my app in ways I didn’t intend? Am I liable?
   The FDA focuses on intended use, which is what you explicitly or implicitly claim. That said, if you quietly know users are relying on your tool for clinical decisions and you keep marketing it aggressively, pretending you “didn’t intend that” won’t save you. Design, onboarding, and messaging should steer people toward your documented intended use.

4. Does using AI automatically trigger FDA regulation?
   No. AI is just a technique. If you’re using AI to optimize UI, send generic nudges, or personalize wellness content, FDA doesn’t care. If you’re using AI to interpret ECGs, radiology images, or to recommend specific treatments, then yes, you’re clearly in SaMD territory. AI doesn’t trigger regulation; what the AI is doing does.

5. We’re just doing “risk scores” and showing guidelines. Is that regulated?
   It depends on how you do it. Transparent risk calculators that show the underlying equation, inputs, and references, and present themselves as informational tools for clinicians, can often be non‑device CDS. Black‑box risk scores that say “treat with X” or “high risk, act now” without clear rationale are much more likely to be considered devices.

6. If I get FDA clearance, am I protected from malpractice or product liability?
   No. FDA clearance means you met regulatory standards for safety and effectiveness under certain assumptions. It doesn’t immunize you from lawsuits if your product harms someone. But it does show you followed an established process, which generally looks better to courts, hospitals, and insurers than “we just winged it.”

7. When should I formally talk to the FDA?
   Once your intended use, target users, and high‑level feature set are stable, and you’ve done a basic landscape review of similar products. For a lot of SaMD, a pre‑submission (Q‑Sub) meeting is worth the time. Don’t go to FDA with a half‑baked idea; go with a clear story and specific questions about classification, predicate devices, and testing expectations.

---

Open your website copy and App Store draft today and highlight every phrase that implies diagnosis, treatment, or decision‑making. Then ask yourself, honestly: would I feel comfortable defending these words in front of an FDA reviewer?