HIPAA and FDA in Healthcare App Development: Which Rules Apply to Your App

HIPAA governs patient data privacy; the FDA governs whether your software counts as a regulated medical device. They answer different questions, and many digital health apps have to satisfy both, which is why treating them as an either/or choice backfires.

The main difference is that HIPAA protects patient data privacy and security, while the FDA decides on device approval. An app can trigger one of these, both, or neither, depending on what it does and what claims it makes. By the end of this article, you'll know which one applies to your app, where they overlap, and what each changes in your build.

Executive Summary

Digital health app compliance works best as an early architecture decision. It shapes your data model, access controls, claims language, and release timeline from day one. Get the wrong axis, or miss one, and the cost shows up fast as an over-engineered wellness app, or a clinical tool missing the safeguards regulators expect. Resolved early, it costs a fraction of what a retrofit does later.

HIPAA and the FDA Answer Two Different Questions

HIPAA covers who can access patient data, how it is transferred, and what happens if it is leaked. The FDA, on the other hand, determines whether your software qualifies as a regulated medical device and what you need to do before it reaches the market. 

However, neither one asks the other's question. And that's exactly why founders who frame this as "HIPAA or FDA" tend to get stuck. Generic "healthcare app compliance" guides that lump both together rarely help either, since they answer a question nobody actually asked.

There are two separate axes running through the same product:

• The privacy axis covers protected health information (PHI), no matter what your app does with it. 

• The device axis covers what your app claims to do medically, no matter how carefully you handle data. 

A meditation app and a diagnostic tool can hold identical amounts of PHI. Only one of them will ever see an FDA reviewer.

The table below shows where each regime starts, what triggers it, and what's at stake if you get it wrong:

When Does HIPAA Apply to Your App?

Your app falls under HIPAA the instant it creates, stores, or transmits protected health information (PHI). That's true whether you're building directly for a covered entity or acting as its business associate. Team size and project stage don't matter here. The obligation starts with the data itself, which is the baseline for HIPAA-compliant app development from day one.

PHI covers more than you might expect. A name linked to an appointment time counts and so does a device ID tied to a health metric, or a support ticket that mentions a symptom. And none of that requires a diagnosis or lab result to qualify.

This covers entities such as healthcare providers, health plans, and clearinghouses. If you build for one of them, or process data on their behalf, you're a business associate. That status requires a signed Business Associate Agreement (BAA) before any PHI moves, including through third-party APIs and LLM providers that touch that data.

Core obligations follow from there, mapping directly onto the HIPAA Security Rule as the baseline standard for healthcare data privacy. That means encryption at rest and in transit, role-based access control, audit logging, and a breach notification process that holds up under pressure. 

These obligations carry real financial weight. HHS raised the maximum civil penalty for the most serious violation category to $2.19 million per violation type, per year, effective January 2026. Add the cost of a breach on top: healthcare incidents average $7.42 million, the highest of any industry IBM tracks.

For the build, your data model, logging strategy, and vendor contracts need to account for PHI from the start.

When Does the FDA Get Involved?

Once your software serves a medical purpose, it becomes FDA SaMD, short for Software as a Medical Device. Intent and claims decide this, not the hardware. A step counter and an arrhythmia detector can share identical sensors; regulation attaches to the app that claims to detect a heart condition, not to the chip inside it.

The line sits between general wellness and clinical claims. A fitness tracker that encourages a healthy lifestyle, with no diagnostic or treatment claim, generally isn't regulated. The same tracker becomes SaMD the moment you tell users it can detect a specific condition.

In January 2026, the FDA narrowed its oversight of low-risk digital health products. AI-enabled wearables and lifestyle trackers now have clearer pathways to stay in the general wellness category than the 2019 guidance allowed.

SaMD classification depends on intended use and indications for use, a topic this article can't cover in depth. Risk runs from Class I (low risk) to Class III (high risk), and your pathway to market—510(k), De Novo, or PMA–follows from there. Like the EU MDR, the SaMD classification framework uses a risk-based approach to determine the appropriate regulatory pathway, even though products are classified independently under each regulatory system. 

A clinical decision support tool shows where this gets specific. Software that summarizes patient data for a clinician to review and act on independently often falls outside device regulation under the FDA's 2026 CDS guidance. That changes once the software recommends a specific diagnosis or treatment and the clinician has no real opportunity to review it first.

Understanding that exact line is key to determining if your digital health product is a medical device. 

How classification looks in practice: Eargo's FDA Class II hearing aids

Eargo shows where this line falls in practice. Its hearing aids are FDA Class II devices, sold direct to consumers and marketed around everyday hearing wellness. That wellness framing does not move them off the device side; the clearance still governs what the product can claim and how it reaches the market. 

We built the companion iOS, Android, and web apps that connect to those devices across three hardware generations, working alongside Eargo's audiologists and folding clinical study findings into each release. When software sits against a cleared device like this, the device question shapes the build directly: what the app is allowed to claim, how much clinical input sits behind each change, and what documentation ships with it.

HIPAA vs. FDA: How Dual Regulation Actually Works

Software that falls under FDA oversight is rarely PHI-free. The two regimes tend to stack on top of each other. Founders who resolve the FDA question often assume HIPAA is a separate, optional question. That assumption misses half the picture.

The wellness app trap catches more teams than it should. A single marketing claim, one line in an app store listing promising to detect or diagnose something, can flip a general-wellness app into SaMD overnight. That flip adds FDA obligations immediately. It also usually means the app was already handling enough PHI to trigger HIPAA. Except nobody built for it, since the product started life as a wellness tool.

Timing matters too, since the two regimes move on different clocks. Your privacy work begins the moment your first commit touches PHI, long before you've settled on what the product claims to do. The device question gets settled later, once you define intended use, often closer to launch. Build for HIPAA from day one regardless of where you land on the FDA question.

How to Tell Which Applies to You

Most cases come down to two questions: is PHI involved anywhere in the app, and does any part of it make a clinical claim? 

Your answers place you into one of three buckets, shown below:

Run through these checks for your app and answer yes or no to each:

1. Does your app create, store, or transmit any data that identifies a person and relates to their health?

2. Do you share that data with, or collect it on behalf of, a healthcare provider, health plan, or clearinghouse?

3. Does your app claim to diagnose, treat, cure, prevent, or mitigate a specific disease or condition?

4. Does your app make treatment or clinical decisions without a clinician reviewing and confirming them first?

5. Do you use any third-party API or AI model that processes the health data described in questions 1 or 2?

Your result:

• Yes to 1 or 2, no to 3 and 4: you're HIPAA-only. Start on your BAAs and technical safeguards now.

• Yes to 1 or 2, and yes to 3 or 4 (which covers most cases): you're FDA + HIPAA. Plan for both from day one.

• No to all: you're neither yet, but revisit this checklist every time you add a feature or a marketing claim.

Confirm your answers against the FTC's Mobile Health Apps Interactive Tool before you finalize your architecture. It's free, and it checks HIPAA, FDA, and FTC rules in one pass.

What About the EU?

Europe splits along the same two axes:

• GDPR plays HIPAA's role on the privacy side. 

• EU MDR plays FDA's role on the device side. 

Build for both US and EU markets, and you're managing four frameworks at once, with the overlap logic above applying independently on each side.

One thing trips teams up more than anything else: a risk class in the US doesn't carry over to the EU. An FDA Class II clearance won't predict where the same product will fall under the EU MDR, and vice versa. Each classification stands on its own.

Moving a product between US and European markets requires a clear understanding of the SaMD classification guide and its interaction with broader framework standards. Likewise, handling patient data internationally means structuring your operations around strict healthcare data privacy standards on both sides of the Atlantic.

What Each Axis Changes in Your Build

Treat compliance as an architecture decision, and both axes turn into design inputs early in the process, well before they'd otherwise surface as obstacles.

HIPAA-compliant app development starts in your data layer. That means how PHI gets encrypted, who can query it, and how every access gets logged from the first commit.

The FDA directly shapes medical device software development. It decides what your UI is allowed to claim, and how much clinician oversight sits between your software and a decision. It also decides whether your release process needs the FDA's required documentation and controls built in before you ship.

Knowing which axis applies before the first commit is what keeps that cost off the table.

Figuring out which rules apply to your app is the first decision. Building the architecture that satisfies them is the next one. If you're at that stage, talk to Monterail's healthcare team about how we approach HIPAA and FDA compliance as a built-in part of the build process.