GDPR in Healthcare: A Practical Guide to Global Compliance
.png)
.png)
Healthcare organisations worldwide must balance patient care with strict data privacy laws. The EU's General Data Protection Regulation (GDPR) has global implications for GDPR healthcare compliance, extending beyond the EU to any entity handling EU residents' personal data. In the healthcare context, GDPR treats health data as a special category, imposing extra safeguards and transparency measures. This practical guide explains when GDPR applies to healthcare, how it differs from HIPAA, and key compliance steps for protecting patient information. It is written for compliance leads, DPOs and healthcare professionals who need a working understanding of GDPR in healthcare rather than a legal treatise.
The GDPR's scope is broad. It governs any "controller or processor" operating in the EU (Article 3(1)) and even non-EU entities offering goods/services to EU individuals or monitoring their behavior (Article 3(2)). This means a US-based telemedicine provider or health app targeting EU users must follow GDPR rules. GDPR applies to all healthcare organisations processing EU individuals' data, regardless of location, and any entity within the EU or EEA.
GDPR's material scope covers "personal data related to the physical or mental health of a natural person" (Article 4(15)). This includes information from medical records, treatment histories, lab test results, genetic profiles, biometric data, and any data revealing someone's health status. Recital 35 further explains that health data encompasses "any information on disease, disability, risk of disease, medical history, clinical treatment or medical diagnosis". It covers everything from electronic health records to fitness tracker data if it reveals health information.
GDPR compliance extends to all entities handling the health data of EU persons. This includes hospitals, medical practices, health insurers, pharmacies, telehealth providers, public health authorities, research institutions, and even third-party vendors (e.g., cloud IT providers, patient portal software companies). Even if a healthcare organisation is covered by HIPAA in the US, it must also comply with GDPR when processing EU patient data. Conversely, entities not normally covered by HIPAA (like life insurers, employers, or mobile health apps) will still face GDPR obligations if they collect EU health data.
Many healthcare entities (especially global ones) must comply with both GDPR and HIPAA. Both of them ensure data protection in healthcare. HIPAA is a US federal law focused on safeguarding Protected Health Information (PHI), whereas GDPR is an EU/EEA regulation protecting all personal data (with additional protections for special categories like health data). Here are some of the key differences in GDPR vs HIPAA.
Under GDPR, controllers (e.g., hospitals) determine how and why data is used, while processors (e.g., a cloud provider handling EHRs) follow the controller's instructions. Both must put appropriate safeguards in place. The GDPR explicitly requires that processing by a processor be governed by a contract specifying each party's obligations (Article 28). Similarly, HIPAA requires covered entities to sign Business Associate Agreements with any vendor receiving PHI, ensuring the same safeguards apply.
GDPR also introduces the Data Protection Officer (DPO) role in healthcare (required for large-scale/sensitive processing). The DPO must operate independently (no instructions about their duties, protected from dismissal) and report to top management. Under HIPAA, while not called a DPO, covered entities must designate a Privacy Officer (for the Privacy Rule) and a Security Officer (for the Security Rule) to oversee compliance. Healthcare DPOs often work alongside IT security and clinical risk teams, reviewing contracts and SLAs with vendors, and ensuring DPIA coverage and transfer-impact assessments are performed.
GDPR: To process health data (Art. 9), explicit consent is one allowed basis, but not the only one. Article 9(2) permits processing without consent if necessary for healthcare provision or public health (e.g., "processing necessary for medical diagnosis, healthcare treatment or management of health" under law or contract). Still, organisations must document the legal basis (Art. 6 for general processing, plus an Art. 9 condition for special data). Consent under GDPR must be "freely given, specific, informed and unambiguous" and in healthcare contexts, obtaining it can be challenging (especially from incapacitated patients). Our guide to GDPR data consent covers the conditions in detail.
HIPAA: There is no GDPR-style "lawful basis" framework. Instead, HIPAA's Privacy Rule defines permitted uses/disclosures of PHI. For example, healthcare providers can share PHI with other providers for treatment without needing patient authorization. Patient "consent" in HIPAA (sometimes called authorization) is only required for uses beyond standard care (e.g., marketing communications, certain research uses). Thus, HIPAA generally allows more flexibility in routine care: consent isn't needed every time a patient's data flows for treatment and billing.
GDPR grants patients (data subjects) a suite of rights: access, rectification, erasure ("right to be forgotten"), restriction, data portability, and objection. Organisations must have processes to honor these rights, ensuring data protection in healthcare. By contrast, HIPAA grants patients a right to access and amend their records and to receive an accounting of disclosures, but it has no erasure or portability requirement. GDPR generally requires transparent communication. Notices must explain all data uses and the patient's rights. HIPAA requires a simplified Notice of Privacy Practices, but it need not explain rights like erasure or portability. Each GDPR right is examined in the healthcare context in the "Patient Rights Under GDPR in Healthcare" section below.
Both GDPR and HIPAA carry significant enforcement risk. Under GDPR, serious breaches or noncompliance can trigger fines up to €20 million or 4% of annual global turnover, whichever is higher (Article 83(5)), plus corrective orders by data protection authorities. Under HIPAA, civil penalties are tiered by culpability level, from 145 dollars to 73,011 dollars per violation, with an annual cap of 2,190,294 dollars per provision (inflation-adjusted amounts effective 28 January 2026). HIPAA violations can also lead to criminal charges with jail time (up to 10 years for willful, malicious acts). High-profile healthcare data breaches have led to multi-million-dollar settlements in both regimes, underscoring that patient privacy failures carry steep costs.
When processing patient or health data, healthcare entities must embed GDPR principles into operations:. The four requirements below are the ones supervisory authorities test first in a healthcare inspection.
GDPR Article 9 prohibits processing "special categories" including health data, unless one of the listed conditions applies. The key GDPR health data conditions for healthcare are:
Healthcare providers most often rely on the medical necessity condition for treatment and care, but they must document this basis. Any other use of patient data (e.g., marketing, unrelated research) will typically need explicit patient consent.
GDPR's foundational principles (Article 5) impose that organisations collect only the minimum health data needed for a specific purpose, and only use it for that purpose. For example, a pharmacy needs minimal patient identifiers and prescription history, but no more. Any collection of unnecessary details (e.g., extensive family history when not needed) violates data minimisation.
Purpose limitation means health data gathered for patient care cannot be repurposed (e.g., sold or used for marketing) without a further lawful basis. Data must not be kept longer than needed: GDPR requires defining clear retention schedules and routinely deleting or anonymising records when no longer necessary. For instance, hospitals might keep medical records for a set number of years per national law and then securely dispose of them. Retention periods for medical records are set by national law, not by the GDPR itself, so the schedule has to be built country by country; our guide to GDPR and data retention explains how.
Article 32 mandates appropriate technical and organisational measures to protect data. In healthcare, this means encrypting electronic health records, pseudonymising patient data for research, securing network access, and ensuring backups/disaster recovery. Article 32 specifically mentions pseudonymisation and encryption as examples. Thus, a HIPAA-compliant approach (e.g., access controls, audit logs, and encryption) aligns well with GDPR's security focus. Regular security audits, vulnerability assessments, and incident response drills are also expected under GDPR's accountability requirements.
Healthcare entities often rely on third-party vendors (EHR platforms, analytics services, telehealth providers). GDPR requires them to conduct due diligence on vendors' data protection practices and to sign GDPR-compliant contracts (Data Processing Agreements) that mandate security and compliance. Just as HIPAA requires Business Associate Agreements, GDPR requires clear processor agreements. Organisations should monitor vendor compliance (e.g., by requiring audit rights or certifications) and ensure the same obligations cover subprocessors. In short, Any handling patient data on the organisation's behalf must be held to GDPR standards. The clauses most often missing from healthcare contracts are listed in our article on GDPR processor agreements.
Patient rights are the point where GDPR healthcare compliance becomes visible to patients. They are the same eight rights that apply to any data subject, but four of them raise specific questions when the data is a medical record: access, rectification and erasure, restriction and objection, and portability. Each is explained below with the healthcare-specific limits that apply.
Patients have a GDPR medical records access right: they can obtain a copy of their health data and know why it is processed, who receives it and how long it is kept (Article 15). The response deadline is one month, extendable by two months for complex requests. Two healthcare specifics apply. First, Member State law may allow a health professional to review the record before release where disclosure could seriously harm the patient. Second, notes about third parties (a relative's medical history, for instance) may be redacted to protect their rights. Access requests are the most frequent GDPR request in hospitals, so a standard form, an identity check step and a tracking log are the minimum process.
Patients can have inaccurate data corrected (Article 16) and incomplete data completed. Rectification does not mean rewriting clinical judgement: a diagnosis the patient disagrees with is an opinion, not a factual error, and the right response is to add the patient's statement to the record rather than delete the entry. The right to erasure (Article 17) is limited in healthcare because most records are kept under a legal retention obligation or for public health and research purposes, which are explicit exceptions in Article 17(3). Erasure requests should therefore be assessed against the retention schedule, and the reasons for refusal explained to the patient in writing.
Restriction (Article 18) lets a patient freeze processing while accuracy is disputed or an objection is assessed; the data is kept but not used. Objection (Article 21) applies to processing based on legitimate interests or public task and to any direct marketing, which must stop immediately. It does not apply to processing that is necessary for treatment under Article 9(2)(h), so a hospital does not have to stop using a record needed for ongoing care. Objection to research use is common, and researchers should design studies so that a single participant's data can be withdrawn without invalidating the dataset.
Portability (Article 20) applies only where processing is based on consent or contract and is carried out by automated means. That excludes most hospital records, which rest on the medical necessity condition, but it does cover patient-facing apps, wearables and private telehealth services that process data on the basis of consent. The European Health Data Space will widen this in practice: from 2029, patients will have a right to access and share their electronic health data across borders in a common European format, whatever the lawful basis of the original processing.
Clinical trials and global research introduce special privacy considerations under GDPR:. Two questions dominate: which lawful basis the research relies on, and how data leaves the EU.
Clinical trials frequently involve health data processing at scale. GDPR for healthcare requires clinical research to respect patient rights (informed consent, withdrawal, data erasure in some cases) and often mandates Data Protection Impact Assessments (DPIAs) for high-risk studies. Consent forms should clearly explain data use, retention, and international data sharing. Ethical review boards now often require privacy safeguards (e.g., anonymisation for analysis). If a trial spans EU and non-EU sites, researchers must ensure GDPR rules cover all phases (e.g., consents in line with EU standards, appropriate data transfer mechanisms between sites). Informed consent to take part in a trial under the Clinical Trials Regulation is not the same as GDPR consent: the EDPB has confirmed that the GDPR basis is usually public interest or legitimate interest, with Article 9(2)(i) or (j) as the special-category condition. Our guide to Clinical Trial Compliance sets out the full picture.
Transferring personal health data outside the EU requires GDPR safeguards. Mechanisms include:
To turn theory into practice, healthcare organisations should take concrete steps:. The four below cover the documentation, risk assessment, people and incident-response pillars that every supervisory authority inspects.
Start by creating a GDPR patient data map. Document what patient data is collected, from where, how it flows (e.g., from clinics to labs to insurance), and who receives it. Article 30 requires maintaining a Record of Processing Activities (RoPA) that lists categories of health data, purposes, recipients, retention periods, and security measures. For each department (e.g., Radiology, Billing, Research), record the types of data processed and legal bases. This inventory is critical for audits and DPIAs.
Under Article 35, a Data Protection Impact Assessment (DPIA) is mandatory when processing health data on a large scale or with new technologies. Any high-risk processing (e.g., genetic profiling, patient tracking, or linking hospital records across countries) should trigger a DPIA. A DPIA should systematically describe the processing activity, assess its necessity and proportionality, identify privacy risks, and outline safeguards. For example, a hospital implementing a new AI diagnostic tool on patient data would perform a DPIA to ensure the risks (like re-identification) are mitigated. Regulators expect DPIAs for major projects involving patient data.
Human error is a major risk. Regular training on GDPR basics (data subject rights, secure handling of patient data, phishing awareness) is essential for all healthcare staff -, from doctors to admin to IT. Training should cover the differences between GDPR and HIPAA obligations, the importance of not over-collecting data, and procedures for patient data requests. Customised scenarios (e.g., "what to do if a patient withdraws consent" or "how to securely email test results") reinforce learning. Leadership must foster a privacy-conscious culture. GDPR for healthcare professionals works best when it is taught through clinical situations rather than legal articles: a ward round, a discharge letter, a referral to a specialist.
Healthcare organisations must have an incident response plan to address data breaches. Under GDPR, a personal data breach must be reported to the supervisory authority within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to individuals. If patient data is compromised, affected individuals must also be notified without undue delay where the risk is high. HIPAA's breach rule is longer (60 days for large breaches), but under GDPR, the clock is much shorter. Plans should include detection, containment, risk assessment (does it involve health data?), internal escalation, notification templates, and post-incident review. Testing this plan (e.g., simulations) is a best practice. Have a documented data breach response plan so your team can act swiftly to protect patients and comply with regulators. The next section goes deeper into how breaches happen in healthcare and how to report them.
Data breaches in healthcare attract more regulatory attention than in any other sector because the data is sensitive, the volumes are large and the harm to patients can be irreversible. Healthcare is consistently among the sectors with the highest number of breach notifications to EU supervisory authorities. This section covers the three things a GDPR patient data breach plan must get right: knowing how breaches happen, assessing and reporting them, and telling patients.
Assessing a breach means answering three questions within hours, not days: what data was affected, how many patients, and what could happen to them. For health data the answer to the third question is almost always "a risk", so notification to the supervisory authority within 72 hours (Article 33) is the default assumption. If the full picture is not known within 72 hours, notify in phases: the initial notification with what is known, then supplementary information as it arrives. Every breach, including those not notified, must be recorded in an internal breach register (Article 33(5)) with the facts, effects and remedial action. Organisations that also fall under HIPAA should run the two clocks in parallel, since the GDPR deadline arrives long before HIPAA's 60 days.
Patients must be informed without undue delay when a breach is likely to result in a high risk to their rights and freedoms (Article 34). Exposure of diagnoses, mental health notes, sexual health or genetic data almost always meets that threshold. The communication must be in clear, plain language and state the nature of the breach, the DPO's contact details, the likely consequences and the measures taken, including steps patients can take themselves. Communication can be avoided only where the data was encrypted and the key not compromised, where measures have removed the high risk, or where individual contact would take disproportionate effort, in which case a public communication is used instead. A pre-approved patient letter template, translated into the languages your patients speak, saves days when the clock is running.
Two topics sit slightly outside the core GDPR framework but come up in almost every digital health project: children's data and the ePrivacy rules on tracking.
GDPR recognises children as having special protection. For online information society services aimed at minors, the general rule is that consent of a parent or guardian is required for children under 16 (EU default; Member States can lower to 13) under Article 8. UK GDPR sets the threshold at 13. In pediatric settings, even beyond online services, healthcare providers should verify appropriate consent procedures for adolescents. For example, a mental health app targeting 15-year-olds in Germany would need parental permission under GDPR. Consent to medical treatment itself is governed by national health law, not Article 8, and the two should not be confused.
Separately from GDPR, the ePrivacy Directive regulates the confidentiality of electronic communications. Telehealth platforms must secure patient communications (no listening or recording without consent) and manage cookies/tracking. Any app or website that uses cookies to track users' health-related browsing requires consent under ePrivacy. Medical device connectivity also triggers ePrivacy rules. Healthcare organisations should treat ePrivacy compliance (cookie banners, opt-ins for marketing) as part of overall data protection. The draft ePrivacy Regulation that was meant to replace the Directive was withdrawn by the European Commission in early 2025, so the 2002 Directive and its national transpositions remain the applicable law.
AI in healthcare data processing is now governed by three overlapping instruments: the GDPR (which already applies), the EU AI Act (phasing in) and the European Health Data Space Regulation (applying from 2029). The practical consequence for a GDPR healthcare programme in a hospital or health-tech company deploying AI is that a single project may need a DPIA, an AI Act conformity assessment and, in future, an EHDS secondary-use permit.
What this means for you: run the DPIA and the AI Act risk classification together. The two assessments share most of their inputs, and doing them in one exercise avoids the common finding that the AI vendor was contracted before anyone checked whether the tool was high-risk.
A DPO has a multifaceted role for data protection in healthcare:. Public health bodies must appoint one, and private providers processing health data at scale almost always meet the Article 37 threshold.
Core tasks: According to GDPR Art 39, the DPO's tasks include informing and advising on compliance obligations, training and auditing staff, advising on DPIAs, and cooperating with Data Protection Authorities. In healthcare, this translates to things like running GDPR for healthcare professionals workshops on patient data rights, reviewing consent forms, and ensuring research protocols include data safeguards.
Many healthcare organisations already follow security standards like ISO 27001 or the NIST Cybersecurity Framework. GDPR can be integrated with these:
On the international front, organisations also need to consider other data protection laws. For example, Canada's PIPEDA has some parallels with GDPR. Reviewing differences (e.g., consent requirements under PIPEDA vs GDPR) ensures global strategies work everywhere.
For a cohesive approach, aligning GDPR requirements with existing information security measures and privacy practices makes compliance more efficient and less redundant.
Given the complexity of GDPR in healthcare, many organisations seek outside expertise. DPO Consulting is an expert partner helping organisations with GDPR compliance. GDPR healthcare compliance can feel overwhelming, particularly when it comes to ensuring your privacy team stays current with the latest legal requirements, internal procedures, and technical protocols. We are your trusted partner in building in-house expertise through practical, scalable training and coaching tailored to your healthcare needs. We begin with a comprehensive Compliance Audit Services engagement to identify gaps in your privacy program (records, policies, technical controls) and recommend fixes tailored to healthcare.
Our DPO Consulting team specialises in healthcare data privacy through our dedicated Health Sector GDPR Compliance practice. We can help you interpret GDPR articles in clinical contexts, integrate privacy with clinical risk management, and ensure you have processes (consent management, breach response, cross-border protocols) that withstand regulatory scrutiny. US organisations that also process EU patient data can pair this with our HIPAA Compliance Services so one programme covers both regimes. With expert support, you can focus on patient care while maintaining robust privacy compliance. Request a healthcare GDPR assessment to get a scoped plan within one call.
Yes, if a U.S. healthcare provider processes personal data of EU residents or markets services to them, GDPR applies. For instance, a U.S. hospital offering online appointments to EU patients must comply. Even if the hospital is not physically in the EU, GDPR's Article 3(2) captures any controller targeting or monitoring EU individuals.
Health data means any personal data about physical or mental health status. This includes medical records, diagnoses, test results, genetic information, or any information revealing health conditions. Anything you'd find in a patient's file (or that reveals illness or treatments) counts as health data.
Yes. For example, a multinational hospital chain may be subject to GDPR when handling EU patient data and HIPAA for US patient data. Even a single patient's data could be subject to both if they cross borders. When both apply, you must satisfy both sets of rules (often HIPAA's baseline security plus GDPR's extra requirements for consent and rights).
GDPR fines can reach the higher of €20 million or 4% of global annual turnover. HIPAA violations carry tiered civil penalties 145 to 73,011 dollars per violation) capped at 2,190,294 dollars per provision per year as of January 2026, plus possible criminal charges (jail time for willful violations). In both regimes, settlements and reputation damage can be even more costly.
You can start by describing the processing (what data, why, who, how long). Then assess necessity and proportionality (is this processing needed for patient care or research?). Identify risks to patients (e.g., re-identification, unauthorised access) and list measures to mitigate them (encryption, access controls, consent protocols). Document this assessment thoroughly.
Not necessarily. Under GDPR, explicit consent is one lawful basis, but not the only one. If processing is necessary for treatment or mandated by law, organisations can rely on those legal bases instead of fresh consent. HIPAA similarly allows PHI use for treatment/payment without authorization. However, any secondary use (e.g., research not covered by care) generally requires explicit patient consent under GDPR (or HIPAA authorization in the U.S.), unless a public interest or research condition applies.
You can use GDPR-approved mechanisms. Transfers to a country with an EU adequacy decision (or to a US DPF-certified organisation) can flow freely. Otherwise, implement Standard Contractual Clauses (SCCs) or Binding Corporate Rules with a Transfer Impact Assessment and extra safeguards (e.g., encryption at rest) as needed. For example, if sending research data from an EU hospital to a U.S. lab, ensure the lab is DPF-certified or sign SCCs and document the transfer rationale.
GDPR medical records retention has no fixed period; the regulation requires that health data be kept no longer than necessary for the purpose (Article 5(1)(e)). Retention is set by national health law, which typically requires medical records to be kept for many years after the last contact with the patient, and longer for minors or in certain specialities. Build the retention schedule from national law first, then apply GDPR to everything national law does not cover, such as appointment logs, marketing data and website analytics.
Article 32 expects measures appropriate to the risk, and GDPR health data security means, at a minimum: encryption of records at rest and in transit, role-based access with logging and periodic review, multi-factor authentication for remote and administrative access, pseudonymisation for research and analytics, tested backups, a patch and vulnerability management process, and staff training. Certification against ISO 27001 or ISO 27701 is not mandatory but is the clearest way to demonstrate the measures to a regulator.
A DPO is mandatory under Article 37 for public authorities and bodies (public hospitals and health agencies) and for any organisation whose core activities involve large-scale processing of special category data, which covers most private hospitals, clinic groups, laboratories, health insurers and digital health platforms. A single-practitioner practice is generally exempt, although some Member States, and several national medical bodies, recommend appointing one. Outsourcing the role is permitted and common where in-house expertise is thin.