Health Data Privacy Rules
Health data privacy regulations govern how organizations handle information tied to a person’s health status, care, or health-related services. The rules differ by jurisdiction and by the type of entity processing the data, so the same dataset can be treated differently depending on who holds it and why.
In the United States, HIPAA (Health Insurance Portability and Accountability Act) sets standards for “covered entities” such as health plans, health care clearinghouses, and most health care providers that transmit certain transactions electronically. HIPAA also covers “business associates” that handle data on behalf of those entities. Outside HIPAA’s scope, many health-related apps and websites fall under state privacy laws or under Federal Trade Commission (FTC) enforcement when practices look deceptive.
In the European Union, the GDPR (General Data Protection Regulation) applies broadly to “controllers” and “processors” handling personal data, including health data, which receives extra protection. GDPR concepts like lawful basis, data minimization, purpose limitation, and data subject rights show up in contracts and privacy notices, even when the organization is not a hospital.
Practical example: a patient portal run by a covered provider typically falls under HIPAA safeguards, while a fitness app that sells aggregated insights to advertisers may face different rules, even if it collects heart-rate or sleep data. That difference matters when you ask for deletion, object to processing, or evaluate how data can be shared with third parties.
Another practical example: a lab results export shared with a third-party telehealth vendor may trigger HIPAA business associate obligations in the U.S., while the same sharing in the EU often requires a clear controller/processor arrangement and a lawful basis for each purpose. The paperwork and the technical controls tend to follow those legal roles, not the user’s expectations.
Common Misunderstandings
People often assume that “health data” always means the same legal category everywhere. In the U.S., HIPAA’s definition of protected health information (PHI) is narrower than the everyday meaning of medical information, and it depends on whether the data is held by a covered entity or business associate. A health app’s data can still be sensitive, but HIPAA may not apply if the app is not acting for a covered entity.
Another misunderstanding involves consent. Under GDPR, consent is one lawful basis among several, and it must be freely given, specific, informed, and unambiguous. Under HIPAA, authorization requirements and permitted uses differ from GDPR’s consent model, and HIPAA also includes specific pathways for disclosures for treatment, payment, and health care operations.
Supporting technologies create real-world privacy risk. When apps use device identifiers, cloud analytics, or third-party SDKs, data can flow to vendors that are not obvious to the user. When a mobile app uploads logs for debugging, those logs sometimes include identifiers that can be linked back to a person, which then affects whether the data is treated as personal data under GDPR and whether it counts as PHI under HIPAA.
Data brokers and ad-tech networks add another layer. Even when an organization claims it “does not sell health data,” it may share segments, inferences, or location-linked signals that can reveal health-related patterns. The FTC has brought enforcement actions when privacy disclosures did not match actual data practices, and those cases often turn on what was promised in the privacy policy versus what happened in tracking and sharing.
Finally, people underestimate retention and re-identification. A dataset may be “de-identified” under one standard, but re-identification risk can remain if the organization retains key fields or combines data with other sources. GDPR treats pseudonymized data as still personal data, and HIPAA de-identification has specific methods and documentation requirements.
How To Reduce Exposure
Map Your Data Flows
Start by listing where health-related data originates: wearable sensors, symptom trackers, lab portals, pharmacy apps, and telehealth chat logs. Then trace where it goes: your device storage, the app’s servers, email notifications, and any third-party integrations. A practical method is to check the app’s privacy policy for named partners and to review in-app settings for “share with” toggles, which many apps label in plain language but hide behind multiple menus.
If you use a mobile browser, check whether the site loads third-party scripts. Tools like Chrome DevTools (for desktop) or browser “site information” panels (for mobile) can show domains contacted during a session. I once saw a health-adjacent app load analytics from a domain that was not listed in the privacy policy; the mismatch was minor in that case, but it changed how the data could be used.
For U.S. users, also note whether the data is held by a HIPAA-covered entity. If you receive records from a provider, you can ask for access and amendments through the provider’s HIPAA processes. If you only interact with an app that is not tied to a covered entity, your rights may come from state privacy laws and the app’s own terms.
Use Rights Requests Wisely
When you want access, correction, or deletion, send requests to the right organization. Under GDPR, you can request access, rectification, erasure, and restriction of processing, and you can object to certain processing. Under HIPAA, you can request access to PHI and request amendments, and you can request an accounting of disclosures in certain circumstances.
Keep requests specific. For example, ask for “all copies of my lab results and associated metadata” rather than “everything you have.” For deletion, ask whether the organization will delete backups and logs, because many systems retain data for security and legal reasons. In the EU, organizations may refuse erasure when processing is necessary for legal claims or public interest tasks, so the response should cite the legal basis.
Track your request dates and reference numbers. A small aside: in one workflow I reviewed, a company’s portal showed “Request ID” but the email confirmation arrived two days later; that gap mattered when the user needed to prove the timeline.
Harden App and Account Settings
Use strong authentication and reduce data sharing. Turn on multi-factor authentication where available, and review permissions for location, contacts, and health data access on your phone. On iOS, check Health app sharing settings; on Android, check app permissions and whether the app can read health data in the background.
Limit third-party connections. If a service offers integrations with other apps, decide whether you need the integration or whether you can export data manually. When you export, verify the file format and where it lands; CSV exports can include identifiers that are not obvious when you open them in a spreadsheet.
For U.S. users, also examine whether the app is “HIPAA-covered” by asking the provider relationship question. If the app is used through a provider’s portal, it may be acting as a business associate; if it is a standalone consumer app, HIPAA may not apply.
Read Notices With a Checklist
Privacy notices often mix legal terms with marketing language, so you need a structured reading approach. Look for: categories of data collected, purposes (treatment, analytics, advertising), sharing recipients, retention periods, and user rights. Then check whether the notice describes de-identification or aggregation and whether it explains how re-identification risk is managed.
Compare the notice to actual behavior. If the notice says “we do not share with advertisers,” but your browser shows ad-tech domains during use, you have a mismatch to investigate. In one audit I assisted with, the privacy policy mentioned “analytics,” while the network calls included multiple ad domains; the user’s trust dropped because the policy did not match the observed traffic.
When you see vague terms like “service providers” without names, treat that as a risk signal. GDPR requires more transparency about recipients or categories, and U.S. policies often list categories rather than names, so you may need to request details directly.
Educational Case Examples
Telehealth Through A Provider
A patient uses a telehealth service linked from a hospital’s patient portal. The hospital is a covered entity, and the telehealth vendor acts under a business associate agreement for PHI. The patient uploads a photo of a rash through the portal, and the vendor stores it for clinical documentation and billing support.
In this scenario, HIPAA protections typically apply to the PHI handled by the hospital and its business associate. The patient can request access to the medical record through the provider’s process, and the hospital should document disclosures for certain purposes. The patient still benefits from checking portal settings for notifications and from verifying who can access the record, because role-based access controls determine whether family members see the data.
Standalone Wellness App
A user installs a standalone sleep and stress app that syncs with a wearable. The app offers “insights” and shares aggregated trends with partners, while also running analytics and advertising measurement through third-party SDKs. The app’s privacy policy states that it may share “de-identified” data for research and marketing.
HIPAA may not apply because the app is not necessarily handling PHI on behalf of a covered entity. The user’s rights may come from state privacy laws and the app’s own deletion and opt-out mechanisms. The user can reduce exposure by turning off ad personalization, limiting data sharing permissions, and requesting deletion while asking whether backups and logs are included in the deletion scope.
Checklist For Decisions
| Decision Point | What To Look For | Why It Matters | Action You Can Take |
|---|---|---|---|
| Is HIPAA likely? | Covered entity or business associate relationship | Determines PHI rights and safeguards | Ask who operates the portal and who stores the data |
| Lawful basis (GDPR) | Consent vs contract vs legitimate interests | Affects your ability to object or erase | Request the basis and object where permitted |
| Third-party sharing | Named recipients or clear categories | Determines downstream access | Limit integrations; request recipient list |
| Deletion scope | Backups, logs, and retention rationale | Deletion may not be immediate | Ask for retention schedule and backup handling |
Step-by-step checklist for a single app or service: (1) identify the data types collected (symptoms, biometrics, identifiers), (2) check whether the service is tied to a provider portal, (3) review sharing recipients and analytics domains, (4) set permissions and authentication, (5) test export and deletion flows, and (6) keep a record of your requests and responses.
If a service offers a “download my data” feature, test it once. A file that arrives without timestamps or with missing identifiers can make later corrections harder, and it rarely matches what the UI promises.
Common Mistakes
One mistake is assuming that “de-identified” means “safe to share.” De-identification standards vary, and some methods still allow re-identification when combined with other datasets. GDPR treats pseudonymized data as personal data, and HIPAA’s de-identification methods require specific approaches and documentation.
Another mistake is ignoring retention and backup language. Many systems keep data for security monitoring, fraud prevention, and legal compliance. If you request deletion without asking about backups and log retention, you may receive a partial deletion response that still leaves traces.
People also over-trust consent screens. A consent toggle can change one processing purpose while leaving other tracking active through SDKs. If you rely on a single switch, you may miss that the app still collects telemetry for crash reporting or analytics.
Finally, readers sometimes share medical data in ways that bypass privacy controls. Forwarding screenshots of lab results through personal email or messaging apps can expose identifiers to unintended recipients and can create copies outside the provider’s access controls. A safer approach is to use the provider’s portal download features or secure sharing links when offered.
FAQ
Does HIPAA cover health apps?
HIPAA covers covered entities and their business associates. Many consumer health apps are not covered unless they handle data on behalf of a covered entity, so state privacy laws and the app’s own disclosures may apply instead.
What counts as “health data” under GDPR?
GDPR treats health data as special category data when it reveals information about a person’s physical or mental health. The classification depends on the content and context of the data, not only on the label used by the app.
Can I request deletion of my records?
Under GDPR, you can request erasure in many cases, but exceptions apply for legal claims and other lawful reasons. Under HIPAA, you can request access and amendments, while deletion rights are more limited and depend on the record type and legal retention requirements.
Why do privacy policies mention “de-identified” data?
Organizations use de-identification language to describe data that they claim cannot identify a person. The practical risk depends on the method used, whether re-identification is possible with other data, and whether the organization still retains linkable identifiers.
How do I spot risky sharing with third parties?
Check privacy notices for recipients and sharing purposes, then compare with observed network calls in your browser. If the notice omits ad-tech or analytics domains that appear during use, treat that as a mismatch worth clarifying with the company.
Author's Insight
Health data privacy rules hinge on roles: who controls the data, who processes it, and why it is processed. HIPAA’s scope depends on covered entities and PHI definitions, while GDPR’s scope depends on personal data handling by controllers and processors, with health data receiving extra protection.
In practice, the biggest user-facing differences show up in rights workflows, deletion scope, and how third-party tracking is disclosed. A privacy notice that names recipients and explains retention tends to be easier to evaluate than one that relies on vague categories.
When you request records or deletion, keep a timeline and capture the exact wording of responses. That evidence helps when you need to escalate a complaint to a regulator or a data protection authority.
I also recommend treating app permissions and third-party SDKs as part of the privacy system, not just a phone setting. A privacy policy can be accurate while the in-app integrations still create unexpected data flows.
Key Takeaways
- Identify the legal scope first: HIPAA depends on covered entities and PHI, while GDPR depends on personal data processing by controllers and processors.
- Map data flows beyond the app UI: third-party SDKs, analytics domains, and exports can change what gets shared.
- Use rights requests with specificity and ask about deletion scope, including backups and logs.
- Compare privacy notices to observed behavior, especially when “de-identified” or “no advertising” claims appear.
- Reduce exposure with account hardening, permission reviews, and cautious sharing of screenshots or exports.