Is Fitness Data PHI? PII, PHI, and Health Data Untangled

You built a fitness app, it reads heart rate and steps, and someone asked whether that makes it "PHI." The short answer: usually not. PHI is a specific HIPAA term, and most direct-to-consumer fitness data is not PHI at all. But that is not the same as "unregulated" — the identical reading is often GDPR "health data" for your EU users and "consumer health data" under newer US state laws. The label that applies depends on who holds the data and why, not on the data type alone. This page untangles the terms so you know which rules actually reach your app. It is general engineering guidance, not legal advice — confirm your own obligations with a qualified professional.

The one insight that clears up most of the confusion

A single heart-rate reading can be PHI in one place and not PHI in another. Inside a hospital's patient app, that reading is Protected Health Information and HIPAA applies. In a standalone consumer workout app, the exact same reading is not PHI — but it is very likely GDPR special-category "health data" for EU users and "consumer health data" under laws like Washington's My Health My Data Act.

Nothing about the number changed. What changed is the relationship and purpose: HIPAA attaches to data held by a health care provider, health plan, or clearinghouse (a "covered entity") or a vendor working on its behalf (a "business associate"). Outside that relationship, health-related data simply is not PHI — even when it came from a medical source originally. So "is fitness data PHI?" is the wrong question to ask in isolation; the real question is "which framework covers this data in my context?"

The four labels — and why they are not interchangeable

People use PII, PHI, "health data," and "consumer health data" as if they were synonyms. They are not. Each comes from a different body of law and pulls in different obligations.

The takeaway: "not PHI" does not mean "not regulated." For a consumer fitness app, the obligations that actually bite usually live in GDPR, state consumer-health laws, the FTC Health Breach Notification Rule, and app-store policy — not HIPAA. See the HIPAA page for when HIPAA does reach you, and the GDPR page for the EU side.

Washington MHMDA and how broad "consumer health data" really is

The state term worth understanding first is Washington's My Health My Data Act (MHMDA), because its "consumer health data" definition is deliberately wide. It covers personal information linked or reasonably linkable to a consumer that identifies their past, present, or future physical or mental health status — expressly including bodily functions, vital signs, symptoms, or measurements, health conditions and treatment, and even precise location that suggests an attempt to seek health services.

That definition plainly sweeps in wearable and workout metrics — heart rate, sleep, activity — that HIPAA would never touch in a consumer context. A few practical notes (verify current specifics, as this area is moving fast in 2026):

• MHMDA took effect March 31, 2024 (later for small businesses). It generally reaches conduct affecting Washington residents regardless of where your company sits.
• It requires opt-in consent to collect or share consumer health data beyond what is necessary to deliver what the user asked for, and a separate, distinct authorization to sell it.
• It includes a geofencing ban near facilities that provide in-person health care (the statute uses a roughly 2,000-foot radius — verify), and that ban has no consent exception.
• It carries a private right of action via Washington's Consumer Protection Act, which makes it a real litigation risk. Nevada's similar law is enforced by the state Attorney General only (no private right of action). California's CCPA/CPRA treats health data as "sensitive personal information" with its own opt-out and limit-use rights. Treat these as broader than HIPAA, not "HIPAA-lite."

What this means for a fitness app

The practical rule falls out of all of the above: treat wearable, workout, biometric, and inferred-health data as sensitive by default, regardless of whether it is technically "PHI." If you build to that standard, you satisfy GDPR and state consumer-health laws even when HIPAA does not apply to you.

• Do not claim "HIPAA compliant" as a standalone consumer app. It is usually inapplicable and can mislead users. If you are deployed on behalf of a provider or health plan (a B2B2C setup with a business associate agreement), that is a different situation — see the HIPAA page.
• Assume GDPR reaches you if EU users can use your app. Fitness metrics are special-category data there, which generally means explicit consent.
• Scope for state consumer-health laws. If you have users in Washington, Nevada, Connecticut, or California, their fitness data likely qualifies as consumer health / sensitive data with opt-in consent and separate sale rules.
• Do not forget precise geolocation. It is sensitive under California law and can become "consumer health data" under MHMDA when it implies health-seeking.
• Apply the sensitive-by-default engineering posture: clear consent, data minimization, encryption, access control, and deletion. Whether you keep data on the device or in the cloud changes your exposure — see on-device vs cloud health data.

A short, honest note on the limits here

The single most common mistake is reasoning "it's not PHI, so I'm fine." That skips the frameworks that actually govern consumer fitness data. The second most common is the reverse — slapping "PHI" on every health value and assuming HIPAA everywhere, which is also wrong because PHI is context-dependent.

This is general guidance, not legal advice, and the state landscape is changing quickly in 2026. Exact definitions, effective dates, geofencing distances, and penalties vary by jurisdiction and get amended — verify them against the current primary sources, and get advice from a qualified professional for your specific product, users, and data flows.