Does HIPAA Apply to My Health App?

Probably not, and that is rarely the relief founders think it is. HIPAA reaches you only through a covered entity: you are a covered entity yourself, or you handle protected health information on behalf of one as a business associate. Sell direct to consumers with no health plan, clearinghouse, or provider on the other side of the transaction and neither applies. What applies instead is the Federal Trade Commission's Health Breach Notification Rule at 16 CFR part 318, whose amendments took effect July 29, 2024 per the DATES block of 89 FR 47028, and which by its own terms covers "foreign and domestic vendors of personal health records, PHR related entities, and third party service providers ... that maintain information of U.S. citizens or residents." The contrarian half: the FTC rule is harder to escape than HIPAA, not easier. It presumes unauthorized acquisition from unauthorized access, has no low-probability-of-compromise off-ramp, and the FTC has already treated an advertising-pixel disclosure as a reportable breach and collected a $1.5 million civil penalty for the failure to report it.

Here is the test for each rule, the two-source condition almost everyone misses, and what changes about the way you build.

Key takeaways

• HIPAA reaches you through a covered entity. No covered entity in the chain, no HIPAA, regardless of how sensitive your data is.
• The FTC rule covers what HIPAA does not, and 16 CFR 318.1 says so explicitly: it "does not apply to HIPAA-covered entities, or to any other entity to the extent that it engages in activities as a business associate of a HIPAA-covered entity."
• The gate for the FTC rule is the personal health record definition, and its hardest condition is technical capacity to draw information from more than one source. The FTC's own worked examples turn on exactly that.
• A "breach of security" under the FTC rule includes unauthorized disclosure, which is how sharing data with ad platforms became a reportable breach. Unauthorized acquisition is presumed from unauthorized access unless you hold reliable evidence otherwise.
• Many companies are in both regimes at once, in different parts of the business. The rules are written so you are never in both for the same activity.

The HIPAA test, in one paragraph

A covered entity is a health plan, a health care clearinghouse, or a health care provider that transmits health information electronically in connection with a covered transaction. A business associate creates, receives, maintains, or transmits protected health information on behalf of one of those. That is the entire reach. A meditation app, a fitness tracker, a period tracker, a direct-pay telehealth service that bills no insurance, a symptom checker: none of these is a covered entity by virtue of holding health data, and none becomes a business associate without a covered entity to be an associate of.

If a hospital, health plan, or another vendor serving one is your customer, stop here and read our BAA decision guide instead, because you are in HIPAA and the questions are different ones. If your customer is the individual, keep reading.

The FTC test, and the condition that decides most cases

Three roles are covered by the rule. A vendor of personal health records is an entity, other than a HIPAA-covered entity or one acting as a business associate, "that offers or maintains a personal health record." A PHR related entity offers products or services through the website or online service of such a vendor, or through the online service of a HIPAA-covered entity offering personal health records, or "accesses unsecured PHR identifiable health information in a personal health record or sends unsecured PHR identifiable health information to a personal health record." A third party service provider provides services to either of the first two and touches unsecured PHR identifiable health information as a result.

All three hang off one definition. A personal health record is "an electronic record of PHR identifiable health information on an individual that has the technical capacity to draw information from multiple sources and that is managed, shared, and controlled by or primarily for the individual."

The multiple-sources clause is the whole game, and the FTC worked it through with examples in the preamble to the 2024 amendments. Take them in order, because they are the clearest statement of the boundary anyone has published.

An app that only publishes information about medical conditions, with no way for a consumer to record anything, is not a personal health record: there is no electronic record of information about an individual. Add a symptom tracker behind a login and it becomes an electronic record of PHR identifiable health information, because the consumer supplies the data, the login identifies them, and the entity providing an online tracking service is itself furnishing a health care service under the rule. But the FTC says it is still not a personal health record "to the extent the site does not have the technical capacity to draw information from multiple sources (i.e., if the consumer is its only source of information)."

Now add one integration. In the FTC's third example the same symptom tracker also collects geolocation through an API, and that is enough: it "has the technical capacity to draw information from multiple sources (consumer inputs and collection of geolocation data through the API)," so it is a personal health record. In the fourth example the second source is a data broker, with the same result.

Read that as an engineering rule, because that is what it is. A single-source app is outside. The moment a second source appears, whether that is an SDK pulling device signals, a wearable integration, a partner API, or a purchased data feed, you are inside. Very few products stay single-source past their first integration, and nobody files a design-review ticket saying "this SDK moves us into a federal breach notification rule."

The FTC also drew a boundary on the other side. A general retailer offering an app to buy and view purchases of food, toys, garden supplies, health products, or maternity clothes is not, by itself, a vendor of personal health records, because that app is "only tangentially related to health," even though some of those purchases reveal health information. To be covered, the offering has to relate "more than tangentially to health."

Why the FTC rule is the stricter one

Three differences matter, and each cuts against the intuition that escaping HIPAA is a win.

No risk-assessment off-ramp. HIPAA lets you rebut the breach presumption by demonstrating a low probability that the information was compromised, through the four-factor analysis. The FTC rule has no equivalent. It defines a breach of security as "acquisition of such information without the authorization of the individual" and then adds a presumption running the other way: "Unauthorized acquisition will be presumed to include unauthorized access ... unless the vendor of personal health records, PHR related entity, or third party service provider that experienced the breach has reliable evidence showing that there has not been, or could not reasonably have been, unauthorized acquisition of such information." Access presumes acquisition, and only affirmative evidence rebuts it.

Disclosure counts as a breach. The same definition states that a breach of security "includes an unauthorized acquisition of unsecured PHR identifiable health information in a personal health record that occurs as a result of a data breach or an unauthorized disclosure." An unauthorized disclosure is a breach. This is the theory under which routine ad-tech instrumentation became a reportable event, and it is the single most expensive misunderstanding in consumer health software.

Discovery is constructive, and the clocks are firm. Under 318.3(c) a breach is treated as discovered on the first day it is known "or reasonably should have been known," to any person other than the one who committed it. Notification to individuals and to media runs "without unreasonable delay and in no case later than 60 calendar days after the discovery," per 318.4(a). Notice to the FTC for breaches involving 500 or more individuals is "contemporaneous with" the individual notice, not sixty days later; smaller breaches go into an annual log filed within 60 days of year end. And 318.4(c) puts the burden of demonstrating that all notifications were made, including the necessity of any delay, on you.

The case that made this real

In February 2023 the FTC brought its first enforcement action under the rule, against GoodRx. Per the FTC's announcement, the company agreed to a $1.5 million civil penalty "for failing to report its unauthorized disclosure of consumer health data to Facebook, Google, and other companies." The conduct the FTC described was not a hacker: it was sharing users' prescription medications and health conditions with advertising companies and platforms including Facebook, Google, Criteo, Branch, and Twilio, and using that data to target its own users with medication-specific ads.

One item in the FTC's list of allegations is worth flagging for anyone tempted by a compliance badge. The Commission said the company "displayed a seal at the bottom of its telehealth services homepage falsely suggesting to consumers that it complied with" HIPAA. There is no HIPAA certification to hold, as we have written elsewhere, and displaying something that implies one is a representation the FTC can and did treat as deceptive.

When you are in both regimes

Dual status is common and the rules are drafted to prevent overlap rather than to create it. 16 CFR 318.1 excludes HIPAA-covered entities and excludes any entity "to the extent that it engages in activities as a business associate of a HIPAA-covered entity." The phrase "to the extent" is doing the work: a company running an enterprise product for hospitals and a consumer app on the same infrastructure is a business associate for the first and, quite possibly, a vendor of personal health records for the second.

The practical implication is that you need one incident process with two branches, and the branch is chosen by which product the data came from. It also means your data-flow map has to keep the two populations separable, because an incident that spans both is the worst version of this: two determinations, two clocks, two regulators, one shared logging pipeline that cannot tell you which users were affected.

The honest caveat

If you are pre-launch or single-source, do not buy a compliance program yet. Establish in writing which regime you are in, keep the answer with your architecture docs, and revisit it the next time someone proposes an integration. That is a one-page artifact, and a founder who has read this far can write it.

Where an outside firm earns a fee is narrower. It is the moment you cross into multi-source and nobody notices, which is why the useful engagement is a data-flow map and a design-review gate rather than a policy binder. It is dual-status companies, where the interesting work is keeping two populations separable in one system. And it is the ad-tech and analytics audit, which is uncomfortable and cheap and pays for itself the first time it finds a pixel on an authenticated page. What we would not sell you is a HIPAA readiness project for a product that has no covered entity anywhere near it; that is the single most common piece of misdirected spend we see in consumer health, and vendors sell it because "HIPAA compliant" is easier to put on a landing page than "compliant with 16 CFR part 318."

Where Top Floor fits

We do the applicability determination, the data-flow mapping, and the third-party and pixel inventory under Compliance as a Service, the HIPAA side for whichever part of your business genuinely has a covered entity behind it under our HIPAA practice, and consumer privacy programme work under our US privacy practice. We are not your lawyers, and the notification decisions here have real legal consequences; what we produce is the technical record those decisions rest on.

How to decide this week

List every source of data in your product other than the user. SDKs, partner APIs, wearable integrations, purchased feeds, anything. If that list is empty you are probably outside the personal health record definition today, and the list is also the exact set of changes that would move you inside.

Then open your tag manager and your authenticated pages together. Every third-party script firing where a user's health context is visible is a candidate unauthorized disclosure under the FTC's own definition, and finding them is an afternoon of work rather than a project.

Finally, write one sentence naming your regime and file it where your architecture decisions live. Companies do not get this wrong because the analysis is hard. They get it wrong because nobody wrote the answer down, and by the time it matters the person who knew has left.

Frequently asked questions

Does HIPAA cover a direct-to-consumer health app?

Usually not. HIPAA reaches you only as a covered entity (a health plan, clearinghouse, or provider transmitting health information in covered transactions) or as a business associate handling protected health information on behalf of one. An app sold directly to individuals, with no health plan or provider in the chain, is neither, no matter how sensitive its data is. That does not leave you unregulated: the FTC's Health Breach Notification Rule at 16 CFR part 318 covers vendors of personal health records, PHR related entities, and their service providers, and by its own terms it applies precisely where HIPAA does not.

What makes an app a "personal health record" under the FTC rule?

It must be an electronic record of PHR identifiable health information about an individual, it must have the technical capacity to draw information from multiple sources, and it must be managed, shared, and controlled by or primarily for the individual. The multiple-sources condition decides most cases. In the FTC's own worked examples, a symptom tracker whose only source is the consumer is not a personal health record; the same tracker becomes one once it also collects geolocation through an API, or draws data from a data broker. In practice, your first third-party integration is the moment the rule attaches.

Is sharing data with advertising platforms a reportable breach?

Under the FTC rule it can be. The definition of "breach of security" at 16 CFR 318.2 expressly includes unauthorized acquisition that occurs as a result of an unauthorized disclosure, and unauthorized acquisition is presumed from unauthorized access unless you hold reliable evidence to the contrary. That is the basis on which the FTC brought its first action under the rule, against GoodRx, which agreed to a $1.5 million civil penalty in February 2023 for failing to report disclosures of consumer health data to Facebook, Google, and others. Ad-tech instrumentation on authenticated health pages is the highest-frequency version of this risk.

Can a company be under both HIPAA and the FTC rule?

Yes, for different parts of its business, but never for the same activity. 16 CFR 318.1 excludes HIPAA-covered entities and excludes any entity to the extent it acts as a business associate of one, so an enterprise product sold to hospitals sits under HIPAA while a consumer app from the same company can sit under the FTC rule. The operational consequence is that you need one incident process with two branches, and a data model that lets you say which population an incident touched. An incident that spans both is the expensive case.