If you're building anything on top of HealthKit, Google Fit, or a direct wearable API integration, there's a compliance assumption worth checking before you ship: HIPAA almost certainly doesn't apply to the data you're pulling.
The Covered Entity Problem
HIPAA only regulates "covered entities" — hospitals, doctors, health insurers, and their direct business associates. A consumer wearable API (Apple HealthKit, Google Fit, Fitbit Web API, Oura API, Whoop API) doesn't make your app a covered entity just because it's handling heart rate or sleep data. Unless you're building specifically for a healthcare provider under a signed business associate agreement, you're outside HIPAA's scope entirely, according to a legal breakdown from the Law Office of Jeffrey Hall.
That means the usual HIPAA checklist — encryption at rest, audit logs, minimum necessary access — is good practice, but it's not a legal requirement for most consumer-facing health apps. Nobody is going to fine you under HIPAA for over-collecting sleep data. That's the trap, not the reassurance.
What Actually Regulates This Data
| Regulation | Applies to consumer wearable apps? |
|---|---|
| HIPAA | No (unless working with a covered entity) |
| GDPR (EU users) | Yes, as sensitive personal data |
| CCPA (California users) | Yes |
| Washington My Health My Data Act | Yes, if any WA users |
| App store health data policies | Yes |
The most interesting one for engineers is Washington's My Health My Data Act (RCW 19.373), passed in 2023. It's the first US state law written specifically to close the HIPAA gap for consumer health data, and it applies to any business with Washington users, not just Washington-based companies. If your app has any US user base, you likely have Washington users. The Act requires:
- A separate, prominently linked Consumer Health Data Privacy Policy (not folded into your general privacy policy)
- Explicit opt-in consent before collection or sharing, not just a terms-of-service checkbox
- A functioning deletion request path across all systems, including backups
- Written authorization retained for six years if you ever sell health data
Full text is at RCW 19.373 if you're scoping compliance work.
Practical Implementation Notes
Data retention. If your backend keeps synced health metrics after a user deletes their account, you're not just accumulating liability, you're likely violating deletion-right requirements in at least one jurisdiction your users touch. Build a real deletion pipeline that hits backups, not just the primary table.
Third-party SDKs. If you're piping HealthKit data into an analytics SDK, an ad network, or a crash reporter, check that SDK's data handling terms specifically. "Anonymized" health data has been shown to be re-identifiable at high accuracy when cross-referenced with other datasets, which is a real risk if you're forwarding granular biometric streams anywhere.
Consent UX. A single "Allow Health Access" iOS permission prompt is not equivalent to the affirmative, specific consent required under Washington's law or GDPR. If you're monetizing health data in any way (even aggregated), build a separate consent flow for that specific use.
Employer/insurer integrations. If you're building a wellness-program integration that feeds data to an employer or insurer, treat that data flow as high-risk by default. There's no HIPAA wall preventing that data from eventually informing risk decisions, and the legal exposure sits with whoever built the pipe.
What I Actually Found
Most developer documentation for these APIs focuses entirely on the technical integration and barely mentions the regulatory landscape. Apple's HealthKit guidelines are the exception — they're genuinely strict about app review for health data access. Google Fit and most third-party wearable APIs leave compliance almost entirely up to you.
If I were architecting a new wearable-data feature today, I'd default to treating every user as if they were covered by Washington's My Health My Data Act, since it's currently the strictest applicable standard and building to it covers most other jurisdictions by default.
Full write-up with the consumer-facing angle and more on the legal background: https://lucas8.com/wearable-health-data-hipaa-gap
Top comments (0)