Tracing consumer health-app PHI from device to cloud — covered-entity boundaries, BAAs, encryption, and audit trails
Consumer health apps generate an extraordinary volume of intimate data: heart rate, sleep stages, menstrual cycle timing, symptom logs, mental-health check-ins. The instinct is to assume all of it is "medical" and therefore HIPAA-protected. It usually is not. HIPAA does not classify data by how sensitive it looks — it classifies data by who touched it and why.
HIPAA's Privacy Rule defines Protected Health Information narrowly: individually identifiable health information created, received, maintained, or transmitted by a covered entity or its business associate in connection with treatment, payment, or health care operations.
The exact same heart-rate reading is PHI when it flows through a hospital's Epic MyChart patient portal, because a covered provider generated it. The identical reading logged in a standalone consumer app — Apple Health, Fitbit, MyFitnessPal, Flo — is not PHI, because no covered entity is involved anywhere in the chain. This single distinction is the most consistently misunderstood point in digital health, and it is the first branch an auditor must resolve before anything else.
When PHI does exist, HIPAA's de-identification Safe Harbor (45 CFR §164.514(b)(2)) requires removing 18 specific identifier categories — names, geographic subdivisions smaller than a state, all dates tied to an individual, phone/fax numbers, emails, device identifiers, biometric identifiers, full-face photos, and any other unique identifying number or code.
A competing "Expert Determination" method allows a qualified statistician to certify a very small re-identification risk using a different methodology. Auditors verify which method (if either) an app actually applies before data is shared with analytics vendors — many apps that claim data is "anonymized" have in practice only pseudonymized it, leaving device ID or advertising ID intact, which re-identifies a user trivially when cross-referenced with ad-tech graphs.
A rigorous PHI data-flow audit walks four questions in order: (1) Did a covered entity — a health plan, clearinghouse, or provider — build or commission this data relationship? (2) Is the data used for treatment, payment, or health-care operations, or purely for consumer engagement/advertising? (3) Is there a signed Business Associate Agreement governing any vendor touching the data? (4) Does the data ever cross into a covered entity's system of record, such as an EHR feed via FHIR/HL7?
Answering "no" to all four does not mean the data is unregulated — it means jurisdiction shifts away from HHS and toward the FTC and state privacy law, which is the subject of Stage 2.
Flo Health, the period-and-fertility tracking app, told users their data was private — yet for years its SDKs sent the timing of periods and stated pregnancy intentions to Facebook and Google. Because Flo has no covered-entity relationship, the FTC pursued it under Section 5 of the FTC Act for deceptive practices, not HIPAA, settling in 2021 with a requirement for independent privacy reviews.
Once the data flow is mapped, every party that touches it must be sorted into one of three buckets: covered entity, business associate, or neither. This classification — not the sensitivity of the data — determines which federal regime, if any, governs the app.
HIPAA applies only to (a) health plans — insurers, HMOs, employer group plans; (b) health care clearinghouses that translate claims data between formats; and (c) health care providers who transmit any information electronically in connection with a HIPAA "standard transaction," such as an eligibility check or claim.
A hospital system that licenses or builds a patient-facing app is a covered entity for that app's data. A standalone startup with no provider or payer relationship is not — no matter how clinical its features look.
The Health Information Technology for Economic and Clinical Health (HITECH) Act of 2009 extended direct HIPAA liability to Business Associates — any person or entity that creates, receives, maintains, or transmits PHI while performing a function on behalf of a covered entity: cloud hosting, EHR software, data analytics, medical billing, transcription.
Before any PHI can move, 45 CFR §164.504(e) requires a Business Associate Agreement (BAA) specifying permitted uses, mandatory safeguards, breach-reporting obligations, subcontractor flow-down requirements, and PHI return/destruction at termination. A narrow "conduit exception" exists for entities that merely transmit data without accessing it (e.g., a telecom carrier) — cloud storage and SaaS analytics vendors almost never qualify for it.
If a user self-enrolls in a wellness app with no employer health plan, insurer, or clinician in the loop — Flo, MyFitnessPal, most consumer Fitbit/Garmin use, AncestryDNA, 23andMe — there is no covered entity anywhere in the relationship, so HIPAA simply does not attach.
Jurisdiction instead falls to: the FTC Act §5 prohibition on unfair or deceptive practices; the FTC Health Breach Notification Rule (16 CFR Part 318), formally extended in 2024 to cover health apps and connected devices handling identifiable health data even without a HIPAA nexus; and a growing patchwork of state law — California's Confidentiality of Medical Information Act (CMIA), Washington's My Health My Data Act (2023), and Illinois's Biometric Information Privacy Act (BIPA) for biometric identifiers like heart-rate waveforms.
BetterHelp, an online therapy platform, agreed to pay $7.8 million to the FTC in 2023 for sharing mental-health intake questionnaire data with Facebook, Snapchat, Pinterest, and Criteo despite explicit confidentiality promises — the first FTC settlement returning money directly to consumers over health-data misuse, brought entirely outside HIPAA.
| Product | Indication | Trial Design | Key Result |
|---|---|---|---|
| Hospital-branded patient portal | Built/licensed by a provider (covered entity) | HIPAA Privacy & Security Rules apply directly | BAA required for every vendor touching data |
| Employer wellness program app | Sponsored by a group health plan | HIPAA applies to the plan-sponsored data flow | Separate consent needed for employer access |
| Standalone consumer fitness/period app | Self-enrolled, no provider/plan link | FTC Act §5 + Health Breach Notification Rule | State health-privacy laws (CMIA, MHMDA, BIPA) |
| Direct-to-consumer genetic testing | 23andMe, AncestryDNA-style services | Outside HIPAA; GINA covers only insurance/employment | Governed by state genetic-privacy statutes |
Whether or not HIPAA applies, every credible health app is expected to encrypt data in motion. The harder audit question is not "is the pipe encrypted?" but "how many pipes exist, and where does each one actually terminate?"
The HIPAA Security Rule labels transmission encryption (45 CFR §164.312(e)(2)(ii)) an "addressable," not "required," specification — meaning a covered entity may adopt an equivalent alternative safeguard if it documents why encryption is unreasonable in context. In practice, no credible alternative exists for internet-transmitted ePHI, and OCR treats unencrypted transmission as a near-automatic finding in enforcement actions. Auditors verify TLS 1.2 or higher on every external connection, valid certificate chains, and rejection of downgrade attempts.
A perfectly configured TLS connection only guarantees that data cannot be read in transit — it says nothing about where the data is being sent. Ad-attribution SDKs (Meta Pixel/Graph API, Google Ads, Branch, AppsFlyer) and crash-analytics SDKs are compiled directly into the app binary and often fire an event — complete with device identifiers and screen names like "period_logged" or "medication_added" — the moment a user takes an action, over their own independently encrypted channel straight to the ad network's servers.
This is why GoodRx, the prescription discount app, could be TLS-compliant on its primary API while simultaneously sending drug names and health conditions to Facebook and Google through embedded pixels — the leak happens above the transport layer, inside application logic, invisible to a network-only security review.
A defensible design enforces TLS 1.2/1.3 everywhere, certificate pinning on mobile clients, mutual TLS between the app backend and any business associate, and encrypted tunnels for HL7v2/FHIR feeds into a provider's EHR. Critically, it also applies data minimization before an event ever reaches a third-party SDK — stripping identifiers and clinical field names from analytics payloads so that even a compromised or overly curious ad SDK receives nothing clinically meaningful.
GoodRx's 2023 FTC settlement was the first-ever enforcement of the Health Breach Notification Rule: despite TLS-encrypted transmission throughout, the company shared drug purchases and health conditions with Facebook and Google Ads for years, paid a $1.5M penalty, and was permanently barred from sharing health data for advertising purposes.
Once data lands in a database or backup, the audit shifts from the network to the storage layer: is the data unreadable without a key, who holds that key, and can every person who can technically query the table actually justify why they need to?
Databases, object storage, and backups should use AES-256 encryption, with keys held in a dedicated Hardware Security Module or cloud KMS — never embedded in application code or environment variables checked into source control. Envelope encryption (a data key wrapped by a master key) lets keys be rotated without re-encrypting entire datasets. Auditors verify backup snapshots and database replicas inherit the same encryption posture as the primary — a frequent gap is an encrypted production database with an unencrypted disaster-recovery replica.
The Security Rule's access-control standard (45 CFR §164.312(a)) requires a unique login per user (no shared service accounts), automatic session logoff, and role-based access mapped to job function — a billing associate should not be able to query clinical notes, and a data scientist should see de-identified cohorts, not raw identifiers. An emergency access ("break-glass") procedure must exist for legitimate urgent access outside normal roles, and every break-glass event should generate its own audit entry for later review.
AWS, Azure, and Google Cloud all offer HIPAA-eligible services and will sign a BAA, but the cloud provider secures only the underlying infrastructure — the customer is solely responsible for configuring encryption, network isolation, and access policy correctly on top of it. A large share of publicized healthcare breaches trace back not to a broken algorithm but to a misconfigured storage bucket left publicly accessible.
HCA Healthcare's 2023 breach affected roughly 11 million patients after data was exposed via an external storage location — a storage misconfiguration incident, not a broken cipher — making it one of the largest reported healthcare data breaches of 2023 and a textbook case for why encryption at rest must be paired with correctly configured access policy, not treated as a substitute for it.
The final layer of a compliant data flow is the one that assumes everything upstream will eventually fail: an immutable record of who touched what, when — and a clock that starts ticking the moment a breach is discovered.
Compliant logging records who accessed a record, the exact timestamp, source IP/device, and the action taken — view, edit, export, print, or delete — written to storage the accessing user cannot modify. HIPAA's documentation-retention clause (45 CFR §164.316(b)(2)) is commonly read to require six years of retention for compliance-related records, and mature programs feed these logs into a SIEM for real-time anomaly correlation, such as one account querying an unusual volume of records outside business hours.
Under the Breach Notification Rule (45 CFR §164.400–414), the 60-day clock starts on the date a breach is discovered, not the date it occurred. Affected individuals must be notified without unreasonable delay and no later than 60 days; HHS must be notified immediately if 500 or more individuals in a jurisdiction are affected (triggering public listing on the OCR breach portal), or via an annual log for smaller breaches; and local media must be notified if 500+ individuals in a single state or jurisdiction are affected. A business associate discovering a breach must notify its covered entity without unreasonable delay, and in no case later than 60 days.
OCR enforces through a four-tier civil penalty structure ranging from roughly $141 to $2.13 million per violation category per year (2024 inflation-adjusted figures under 45 CFR §160.404), and most significant investigations resolve through a Resolution Agreement paired with a Corrective Action Plan — typically one to three years of independent monitoring, mandatory risk assessments, and workforce retraining, on top of any monetary settlement.
23andMe's 2023 credential-stuffing breach exposed data — including DNA-relative matches — for roughly 6.9 million users, but because 23andMe is a direct-to-consumer genetic testing company with no covered-entity relationship, none of HIPAA's 60-day notification or audit-trail obligations applied. The incident was instead handled under state breach-notification statutes and consolidated class-action litigation, which 23andMe settled for $30 million in 2024 — a real-world case study in a serious health-data breach falling entirely outside HIPAA's enforcement regime.