GDPR, HIPAA, and Consumer Health Data: A Practical Privacy Map

Calling information “health data” does not reveal which privacy rule applies. A laboratory result in a hospital record, a symptom typed into a consumer app, a medication purchase inferred from browsing, and a fitness score transferred from Europe to a U.S. cloud service can all describe health. They may sit in four different legal structures.

The useful question is therefore not “Is health data protected?” It is: who is doing what with which data, for whom, where, and in what legal role? The answer may bring in the European Union’s General Data Protection Regulation (GDPR), the U.S. Health Insurance Portability and Accountability Act (HIPAA) Rules, the Federal Trade Commission (FTC) Act and Health Breach Notification Rule, state consumer-health statutes, or several of them at once.

Privacy rules, agency positions, litigation, and implementation dates change; every operational decision needs a fresh status check.

Start with a six-part data map#

Before you compare statutes, map the processing operation. A useful record answers six questions.

1. What information is involved? Include direct clinical facts, device readings, genetic and biometric data, precise location, advertising identifiers, inferred conditions, and combinations that can identify someone.
2. Who touches it? List the clinic, plan, employer, app company, research sponsor, analytics vendor, cloud provider, advertiser, data broker, and each subcontractor.
3. Why and how is it used? Separate care, payment, operations, research, product delivery, safety, personalisation, advertising, model development, and sale. One dataset can support multiple processing purposes, each needing analysis.
4. Whose behalf is each party acting on? A vendor may follow another party’s documented instructions for one service and decide its own purposes for another. That can change its legal role.
5. Where are the people and organisations? Establishment, targeting, monitoring, residence, collection location, and international transfer routes can all matter.
6. Which version of each rule is legally operative? A press release, proposal, final rule, court order, compliance date, and enforcement guidance are not interchangeable.

This map prevents a common error: treating a contract label or a privacy-policy sentence as the conclusion. Legal roles usually depend on facts. A company cannot make itself merely a “processor” by contract if it actually determines an independent purpose for the data.

GDPR: health data receives an additional layer#

GDPR applies to the “processing” of personal data, a broad concept. It includes collection, use, and storage. It includes disclosure, alteration, and deletion. Data concerning health is a “special category” under Articles 4 and 9 because misuse can create unusually serious risks. Genetic data and biometric data used for unique identification are also special categories.

That classification adds a layer; it does not create a self-contained permission. A controller processing health data should document:

• compliance with the Article 5 principles, including purpose limitation, data minimisation, accuracy, storage limitation, security, fairness, and transparency;
• an Article 6 lawful basis for the processing; and
• an Article 9(2) condition that lifts the general prohibition on processing the special category.

The European Data Protection Board’s official small-business guidance makes the sequence explicit: identify the Article 6 basis, identify the additional Article 9 condition, and record the risks and safeguards. The European Commission’s legal-grounds guide also notes that Member State law may add conditions for genetic, biometric, and health data under Article 9(4).

Article 6 and Article 9 work together#

Article 6 lists six families of lawful basis: consent, contractual necessity, legal obligation, vital interests, a task in the public interest or exercise of official authority, and legitimate interests subject to a balancing test. The right choice is tied to the real purpose and necessity of the processing. It should not be selected only because it is administratively convenient.

Article 9(2) provides narrower conditions for special-category data. Depending on the facts and applicable EU or Member State law, these may include explicit consent; employment and social-protection obligations; vital interests when a person cannot consent; legal claims; substantial public interest; health or social care and system management; public health; and scientific research or statistics with required safeguards.

For example, a hospital’s necessary use of a patient’s data for diagnosis and treatment may rely on an appropriate Article 6 basis under applicable law together with Article 9(2)(h), rather than asking the patient to “consent” to every essential clinical record operation. A public-health authority may use a public-interest basis with Article 9(2)(i) where law provides the necessary foundation and safeguards. Research may involve Article 9(2)(j), Article 89 safeguards, and national law. But that label does not erase purpose, transparency, minimisation, or rights analysis.

Explicit consent can satisfy Article 9(2)(a) and may pair with Article 6(1)(a), but it must meet GDPR’s standards. It must be freely given, specific, informed, unambiguous, and explicit for special-category processing; withdrawal must be possible. Power imbalance or making an unnecessary data use a condition of service can make consent invalid. Clinical informed consent to a procedure, research ethics consent, and GDPR consent are related in practice but answer different questions. One form should not be assumed to satisfy all three.

Controller and processor describe functions#

Under GDPR, a controller determines the purposes and means of processing. A processor processes personal data on the controller’s behalf. Organisations that jointly determine purposes and means may be joint controllers. The European Commission’s controller-and-processor explanation emphasises that the same entity can hold different roles for different operations.

Article 28 requires a controller-processor contract or other legal act with specified terms. The processor must act on documented instructions, maintain confidentiality and security, control subprocessors, assist with relevant compliance, and address return or deletion. Processors also have direct GDPR duties. If a service provider reuses clinical data for its own unrelated advertising or product-development purpose, that independent decision may make it a controller for that use, regardless of what its contract calls it.

Controllers remain accountable for core choices: lawful basis, transparency, and rights. They are accountable for retention, data-protection-by-design, and security. They are accountable for breach response and, where high risk is likely, a data protection impact assessment. Vendor diligence and a signed data-processing agreement help, but neither proves that the underlying purpose is lawful.

HIPAA: coverage depends on the entity and relationship#

HIPAA’s Privacy, Security, and Breach Notification Rules use a more sector-specific structure. The Privacy Rule applies to covered entities: health plans, health care clearinghouses, and health care providers that transmit health information electronically in connection with transactions for which HHS adopted standards. A clinician is not covered merely because a laptop or email is used; the defined provider and transaction tests matter.

A business associate is generally a person or entity that creates, receives, maintains, or transmits protected health information (PHI) on behalf of a covered entity for covered functions, or provides specified services involving PHI. Business associates and relevant subcontractors have direct obligations, and the relationship normally requires a compliant business associate agreement. Merely selling software without access to PHI does not by itself create that role.

These labels are not translations of GDPR roles. A hospital can be a HIPAA covered entity and a GDPR controller. A cloud company may be both a HIPAA business associate and GDPR processor. But another vendor could be a business associate for one workflow and an independent GDPR controller for a separate purpose. Each classification needs its own facts and legal test.

The three HIPAA rules answer different questions#

The Privacy Rule protects individually identifiable health information held or transmitted by a covered entity or business associate, in electronic, paper, or oral form. It limits uses and disclosures, permits or requires defined uses, and gives individuals rights including access and amendment. Treatment, payment, and health care operations are important permitted pathways, but never let “HIPAA allows it” stand in for the exact provision you are relying on.

The Privacy Rule’s minimum-necessary principle generally requires reasonable efforts to limit PHI to what the purpose needs. It has defined exceptions, including disclosures to or requests by a health care provider for treatment and disclosures to the individual. A blanket “minimum necessary always applies” statement is therefore inaccurate.

The Security Rule is narrower by data format: it protects electronic PHI, or ePHI. Covered entities and business associates must use administrative, physical, and technical safeguards to protect confidentiality, integrity, and availability. Risk analysis, access controls, and workforce practices are operational requirements. So are incident procedures, contingency planning, and evaluation. So are documentation and business-associate arrangements, and none is a one-time certification exercise.

The Breach Notification Rule addresses breaches of unsecured PHI. Covered entities may need to notify affected people, HHS, and, for some large breaches, the media; business associates notify the covered entity. HHS states that breaches affecting 500 or more people must be reported to the Secretary without unreasonable delay and no later than 60 calendar days after discovery. Smaller breaches are reported to HHS no later than 60 days after the end of the year in which they were discovered, although individual-notice duties have their own timing. Incident teams should use the actual rule and current HHS instructions, not reduce every HIPAA deadline to a single “60-day rule.”

The consumer-app gap is a boundary, not a law-free zone#

HIPAA does not protect every piece of health-related information everywhere it travels. HHS explains that when a person directs a covered entity to send ePHI to an independent app that is neither a covered entity nor business associate, the information in that app is no longer protected by the HIPAA Rules. If the app is provided by or on behalf of the covered entity and handles ePHI for it, the app developer may instead be a business associate.

That distinction means two visually similar apps can have different HIPAA status. The hospital’s patient app may be part of a HIPAA-regulated service, while a consumer-downloaded symptom tracker may not be. A developer’s statement that an app is “HIPAA compliant” is incomplete unless it explains the role and processing context.

Outside HIPAA, important obligations remain. Section 5 of the FTC Act can reach unfair or deceptive privacy and security practices. An app that promises not to share health information and then sends it to an advertising platform may face FTC scrutiny even when HIPAA does not apply. State consumer-protection, privacy, and biometric laws may add duties. So may genetic, data-breach, and health-data laws. GDPR may apply if its territorial test is met.

The FTC Health Breach Notification Rule#

The FTC Health Breach Notification Rule, 16 CFR Part 318, applies to defined vendors of personal health records, PHR-related entities, and third-party service providers that are not acting within HIPAA coverage for the information at issue. A personal health record under this rule is an electronic record of identifiable health information that has the technical capacity to draw information from multiple sources and is managed, shared, and controlled by or primarily for the individual.

The FTC’s amendments effective 29 July 2024 clarified the rule’s reach to health apps and similar technologies. They also clarified that an unauthorised disclosure can be a “breach of security”; a malicious network intrusion is not required. The FTC’s current compliance guide uses disclosure to an ad network without authorisation as an example.

Covered vendors and PHR-related entities generally must notify affected people and the FTC, and sometimes the media. Notice to individuals must be without unreasonable delay and no later than 60 calendar days after discovery. For breaches involving 500 or more people, FTC notice is due at the same time as individual notice; smaller events are reported to the FTC annually within the rule’s timetable. Service providers notify the relevant vendor or PHR-related entity. Exact role, data type, security status, affected population, and notice content all need documentation.

The rule does not cover every consumer health dataset. The multiple-source capacity and other definitions matter. But failing that test does not remove the FTC Act or state law. The FTC’s updated Mobile Health App Interactive Tool is a useful starting screen, not a legal determination.

State consumer-health privacy fills parts of the gap#

U.S. state law is not uniform. Washington and Nevada illustrate why your national product needs a state-by-state data map rather than a single “not HIPAA” branch.

Washington’s My Health My Data Act, Chapter 19.373 RCW, broadly defines consumer health data to include information linked or reasonably linkable to a consumer that identifies physical or mental health status. Its examples include symptoms, diagnoses, medication, reproductive and sexual health, gender-affirming care, biometric and genetic data, precise location indicating an attempt to obtain health services, and data inferred from non-health information.

The Washington law requires a conspicuous consumer health-data privacy policy, consent or a request-based necessity for covered collection and sharing, consumer access and deletion processes, security practices, processor contracts, separate authorisation for sale, and restrictions on geofencing around health-care facilities. Its main requirements have applied since 31 March 2024, with a 30 June 2024 date for small businesses. It is enforceable under Washington’s Consumer Protection Act, including a private-action pathway through that Act. Defined exemptions still need to be applied carefully to the entity, data, and conduct.

Nevada’s consumer-health provisions, NRS 603A.400 through 603A.550, also regulate broadly defined consumer health data, including some inferred information and health-related precise geolocation. They address privacy notices, affirmative and voluntary consent for collection, and separate consent for sharing. They address consumer requests, security, and processors. They address sale authorisation and geofencing. Nevada’s scope and exemptions are not identical to Washington’s; for example, the Nevada chapter states an exemption for persons or entities subject to HIPAA. That difference alone shows why copying one state’s analysis into another is unsafe.

Other state privacy and sectoral laws may also apply. The operational lesson is not to memorise two statutes. It is to maintain a jurisdiction matrix that records residence and collection triggers, definitions, entity- or data-level exemptions, consent design, sensitive-data rules, sale and sharing definitions, consumer rights, processor terms, geofencing, retention, appeal, enforcement, and effective dates.

Cross-border work requires two separate GDPR questions#

If you run a U.S. health company, “we have no European office” does not end the GDPR analysis. Article 3 can apply based on an establishment in the EU/EEA, or to a non-EU organisation’s relevant processing connected to offering goods or services to people in the Union or monitoring their behaviour there. The EDPB’s final territorial-scope guidelines explain that the tests are contextual. Website accessibility alone is not the same as targeting, and not every operation of a global company is automatically in scope.

Territorial scope and international transfer are then separate questions:

• Does GDPR govern this processing? Apply Article 3 to the establishment, targeting, and monitoring facts.
• Is personal data being transferred to a third country? If so, apply Chapter V even when the importer also has direct GDPR obligations.

Transfers may rely on an adequacy decision, appropriate safeguards such as the European Commission’s Standard Contractual Clauses, binding corporate rules, or a narrowly construed derogation. SCCs are not simply a document to sign and forget. The parties may need to evaluate the destination’s law and practice, the transfer, and supplementary safeguards. Data location, remote administrative access, support access, onward transfers, and subprocessors belong in the map.

HIPAA does not contain GDPR’s general Chapter V transfer architecture. A HIPAA-regulated organisation can use an overseas service provider only if the HIPAA relationship, agreement, risk management, safeguards, and other applicable restrictions are satisfied. State law, contractual commitments, and research approvals can still change the answer. So can procurement rules, national localisation rules, and GDPR.

A practical comparison#

The table is a navigation aid, not a crosswalk. Similar words can conceal different legal tests. “Processor” in a state law, GDPR, and a commercial contract may not mean the same thing.

Scroll horizontally to inspect the full figure. A complete text version follows.

Read the figure in text

The map begins with one data flow and asks four groups of questions: who decides and processes; what data and context are involved; which legal or contractual boundaries can apply; and what happens during collection, access, sharing, retention, security, deletion, breach response, and redress.

Status check: final, proposed, vacated, and under consultation#

Privacy analysis can fail even when the right topic is identified if the wrong legal status is assigned.

HIPAA Security Rule cybersecurity proposal#

HHS issued a notice of proposed rulemaking in December 2024, published in January 2025, that would make substantial cybersecurity changes. It is a proposal, not a final rule. HHS expressly states: “While the Department is undertaking this rulemaking, the current Security Rule remains in effect.” You can compare the proposal with your security programme, but do not describe every proposed control as a current HIPAA requirement unless another existing provision separately requires it.

HIPAA reproductive-health privacy litigation#

HHS’s current fact sheet states that on 18 June 2025 a federal district court declared unlawful and vacated most of the 2024 HIPAA Privacy Rule to Support Reproductive Health Care Privacy. Certain Notice of Privacy Practices provisions were also vacated, while remaining NPP modifications were undisturbed and had a 16 February 2026 compliance date. A summary that still presents the original 2024 prohibition as fully operative is outdated. Because further agency action or litigation can change the position, check the current HHS page, the court record, and qualified counsel before you rely on this area.

FTC Health Breach Notification Rule amendments#

The FTC’s 2024 amendments are a final rule in effect since 29 July 2024. They should not be described as a pending proposal. The current text and FTC compliance materials, rather than the earlier 2023 notice of proposed rulemaking, should drive an incident assessment.

EDPB scientific-research guidance#

EDPB Guidelines 1/2026 on scientific research were released for public consultation, with feedback closing 25 June 2026. As of this article’s 16 July 2026 source check, the EDPB page labels the process closed for feedback rather than presenting a final adopted version. It can reveal the regulator’s developing analysis, but it should be labelled consultation material and not substituted for the GDPR, applicable Member State law, or final EDPB guidance.

Build one evidence file for each processing purpose#

A defensible privacy programme converts the legal map into evidence. For each material health-data purpose, maintain a record containing:

• a data-flow diagram showing collection, derivation, storage, access, sharing, sale, deletion, and international transfers;
• data and person classifications, including direct, inferred, pseudonymised, de-identified, and anonymous categories;
• the role of every party under each potentially applicable framework;
• the GDPR Article 6 basis and Article 9 condition, where applicable, with necessity and balancing analysis;
• the exact HIPAA permission, authorisation, or required disclosure and minimum-necessary analysis, where applicable;
• consent and withdrawal design, including whether collection, sharing, and sale require separate choices;
• privacy notices that match actual data flows and do not overstate HIPAA or certification status;
• retention and deletion rules, including backup and downstream instructions;
• Article 28, business-associate, state-processor, and subprocessor terms matched to real operations;
• security risk analysis, access controls, encryption, logging, incident response, recovery, testing, and accountable owners;
• international transfer mechanism, transfer assessment, and onward-transfer controls; and
• a dated legal-status register recording proposals, final rules, court orders, guidance, effective dates, and the next review date.

The strongest control is often architectural: do not collect a health signal that the service does not need; do not send it to an advertising endpoint; do not retain raw data after a derived result will suffice; do not let a vendor repurpose it; and do not infer sensitive traits merely because the model can. Data minimisation reduces compliance burden and the human consequences of a failure.

Questions to ask before launch#

Your launch review should answer these questions without relying on slogans:

• Can the team name every health inference, identifier, SDK event, log, prompt, and model output the product creates?
• Is each vendor’s role based on actual instructions and purposes, not just a template label?
• Does the Article 6 and 9 analysis cover each purpose separately?
• Has the team distinguished HIPAA PHI from health-related data outside HIPAA?
• Do the privacy notice, consent screen, app-store disclosure, and network traffic tell the same story?
• Can a person access, correct, delete, withdraw, or appeal where the applicable law requires it?
• Can deletion propagate to processors, backups, derived profiles, and trained or indexed systems where legally and technically required?
• Are advertising, analytics, location, and session-replay tools blocked from sensitive flows unless a documented analysis permits them?
• Has every cross-border access path and subprocessor been included?
• Can the incident team identify applicable clocks and regulators within hours, not weeks?
• Has someone verified that every cited rule is final and operative today?

No single badge answers those questions. “HIPAA compliant,” “GDPR ready,” a business associate agreement, an SCC module, encryption, or a consent checkbox can each be useful. None is a complete privacy system. The reliable approach is a purpose-by-purpose map, correctly classified roles, and layered legal grounds. It is minimised data, verifiable controls, and a dated record of what the law actually requires.

A measured conclusion#

GDPR and HIPAA are often compared because both can govern health information, but their boundaries are different. GDPR starts broadly with personal-data processing and adds protection for health data. HIPAA starts with specified U.S. health-sector entities and relationships. The FTC and state laws address important territory beyond HIPAA, while GDPR can follow relevant processing across borders.

If you are the person using a health service, the practical message is to check who provides it and what role the app plays before assuming HIPAA applies. If you run one, the message is more demanding: classify the data, party, and purpose separately. Classify geography and rule status separately too, then preserve the evidence. That is slower than applying a label, but it is the difference between privacy language and privacy governance.