GDPR compliance in healthcare: a practical guide for clinicians

GDPR obligations fall on every clinician who handles patient data, not just information governance teams. Routine activities like writing clinical notes, sending referrals, and using an AI medical assistant all carry specific legal responsibilities that clinicians need to understand in practical terms.

Why healthcare data receives stronger GDPR protection

Under Article 9 of the General Data Protection Regulation (GDPR), health data is classified as a "special category" of personal data, attracting a higher level of legal protection than standard personal information such as a name or address. The classification reflects the particular sensitivity of medical information and the potential for serious harm, including discrimination, stigma, or financial disadvantage, if it's disclosed without authorisation.

Processing health data requires satisfying not only a lawful basis under Article 6 (which applies to all personal data) but also a separate, additional condition under Article 9(2). Meeting both requirements simultaneously is a foundational compliance obligation that applies to every clinical encounter. The European Data Protection Supervisor has consistently emphasised that special category status also requires organisations to build privacy protections into their systems from the outset and maintain robust safeguards throughout the data lifecycle, including in innovation-driven processes such as clinical trials and mobile health applications.

A peer-reviewed comparative analysis published in 2025 confirmed that GDPR imposes comprehensive accountability measures for medical data, and found that health information is subject to additional ethical and professional safeguards beyond those required under comparable frameworks such as the United States' Health Insurance Portability and Accountability Act (HIPAA). Of the frameworks compared, GDPR's dual-basis requirement is the more demanding, and the one most likely to catch clinical organisations off guard.

When patient consent is and isn't required

One of the most persistent misconceptions in clinical settings is that GDPR requires explicit patient consent for all data processing. In direct care, that's not the case. Most clinical data processing relies on one of the following bases:

• Article 9(2)(h) GDPR covers processing necessary for medical diagnosis, the provision of health or social care or treatment, or the management of health or social care systems. This is the principal basis for routine clinical documentation, referrals, and multidisciplinary team discussions.

• Article 6(1)(c) covers processing necessary to comply with a legal obligation, for example mandatory reporting of notifiable diseases.

• Article 6(1)(e) covers processing necessary for a task carried out in the public interest, which applies primarily to NHS and publicly funded healthcare organisations.

As heyData's compliance guidance for medical practices notes, medical necessity and legal obligation are valid and appropriate alternatives to consent in the majority of direct care scenarios. Clinicians don't need to obtain a separate GDPR consent form before writing a clinical note or sending a discharge summary to another treating clinician.

Consent under GDPR must be freely given, specific, informed, and unambiguous. In a clinical relationship, there's an inherent power imbalance. Patients may feel unable to refuse without it affecting their care, which makes consent a poor primary lawful basis for routine treatment data. It is the appropriate basis for research not covered by a separate ethics framework, for marketing or commercial communications, for sharing identifiable data with third parties outside the direct care team for purposes unrelated to treatment, or when deploying optional digital health tools that process personal data beyond what is clinically necessary.

What counts as a GDPR breach in a clinical context

GDPR defines a personal data breach as any accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. In healthcare, breaches often don't result from external cyberattacks. They arise from everyday clinical workflows:

• Sending a patient letter to the wrong address, or attaching the wrong patient's records to an email

• Leaving a clinical workstation logged in and unattended in a shared environment

• Discussing identifiable patient information in corridors, waiting areas, or over the phone where others can overhear

• Forwarding patient data to a third party, including a family member, without a documented lawful basis

• Using consumer-grade platforms such as standard Zoom or WhatsApp accounts, which are rarely acceptable for transmitting identifiable clinical information. They would need to be specifically configured with a data processing agreement and other safeguards that meet GDPR requirements before use.

Breaches that are likely to create a risk to individuals must be reported to the relevant supervisory authority within 72 hours of the organisation becoming aware of them. Breaches that pose a high risk must also be communicated directly to those affected. GDPR Register's healthcare guidance notes that the 72-hour clock starts when the organisation, not necessarily the individual clinician, first becomes aware of the breach, which means prompt internal reporting is essential.

Sharing patient data: referrals, discharge summaries, and third parties

Sharing patient data within a direct care team, including between GPs, specialists, nurses, and allied health professionals, is generally lawful under Article 9(2)(h), provided the sharing is necessary for and proportionate to the clinical purpose. The guiding principle is 'need to know': only the information relevant to the receiving clinician's role should be shared.

• A referral letter should contain the clinical information the receiving specialist needs, not the patient's entire medical history.

• A discharge summary should go to the GP and relevant care team members, not be distributed more broadly without clinical justification.

• Sharing records with a patient's employer, insurer, or solicitor requires explicit patient consent or a separate legal basis.

When sharing data with third-party systems, including medical record systems, diagnostic laboratories, or telemedicine services, a Data Processing Agreement (DPA) must be in place before any data is transferred. This is a contractual requirement under Article 28 GDPR, and its absence is a compliance failure regardless of whether a breach actually occurs. Patient notification is generally not required for sharing within the direct care team, provided the organisation's privacy notice accurately describes how data is used for treatment purposes.

GDPR obligations when adopting AI medical assistants and clinical tools

Deploying AI medical assistants, ambient voice technology (AVT), and other third-party clinical software introduces specific GDPR obligations that need to be addressed before adoption, not after. Any tool that processes patient data on behalf of a healthcare organisation is a data processor under GDPR, which means the healthcare organisation, acting as data controller, must ensure that:

• a DPA is in place with the vendor

• the vendor processes data only on documented instructions

• appropriate technical and organisational security measures are in place, including encryption, access controls, and audit logging

• data residency is clearly established, particularly relevant for EU-based organisations where a vendor processing data on servers outside the European Economic Area (EEA) may trigger additional transfer safeguards

Early research into privacy-preserving AI deployment in clinical settings shows promising results for local, offline AI systems that can reduce the risks associated with cross-border data transfers in cloud-based processing, though clinical validation is still ongoing.

Before adopting any AI clinical tool, clinicians and their organisations should ask:

• Where is patient data processed and stored? Is it within the EEA, or does processing involve transfers to countries outside it?

• Does the vendor hold ISO 27001 certification (an internationally recognised standard for information security management) or an equivalent recognised security standard?

• Has a Data Protection Impact Assessment (DPIA) been completed? GDPR requires a DPIA, a structured assessment of privacy risks, for any processing likely to result in high risk. Large-scale processing of health data by AI systems falls squarely into this category.

• What is the vendor's data retention and deletion policy? Can data be deleted on request, and is this documented?

• Is the tool registered as a medical device where applicable under the EU Medical Device Regulation (MDR)?

Drata's guidance rightly treats the Data Protection Impact Assessment as a living document, to be reviewed whenever processing changes materially: completed at procurement, then revisited as systems evolve, rather than filed away after the initial assessment. In environments operating under time and resource pressures, the most rigorous scrutiny should go to tools that process the most sensitive data at the greatest scale, because that is where the actual risk sits.

Patient rights clinicians are likely to encounter

Patients have a defined set of rights under GDPR that healthcare organisations are legally obliged to facilitate. The rights most commonly encountered in clinical practice are:

• Right of access (Subject Access Request): Patients are entitled to receive a copy of their personal data, including clinical records, within one month of making a request. Organisations can extend this by a further two months for complex or numerous requests. Third-party information, such as details about another patient, should be redacted before disclosure.

• Right to rectification: Patients can request correction of inaccurate personal data, for example a factual error in a record. This doesn't entitle a patient to have a clinician's professional opinion or clinical judgement changed.

• Right to erasure: This right is significantly limited in healthcare. Under Article 17(3)(b) and (c), it doesn't apply where processing is necessary for the provision of healthcare or where the law requires retention. Patients can't require deletion of their medical records during the applicable retention period.

• Right to data portability: Under Article 20, this right applies only where processing is based on consent or contract. Most clinical record processing relies instead on the legal-obligation or public-interest healthcare bases (Article 6(1)(e), 9(2)(h)), to which portability doesn't apply.

Data minimisation in clinical documentation

Article 5(1)(c) GDPR sets out the principle of data minimisation: personal data must be adequate, relevant, and limited to what is necessary. For clinicians, this means recording what's needed to support safe, continuous care rather than biographical detail that isn't clinically relevant. It also means avoiding the routine inclusion of third-party information unless it's directly relevant to the clinical picture, and using structured templates that prompt for relevant fields rather than free-text entries that may capture unnecessary personal information. Data minimisation, alongside purpose limitation, is one of the principles most commonly overlooked in clinical settings, particularly in organisations moving from paper-based to digital records, and individual clinician behaviour has the most direct bearing on whether it is observed in practice.

Retention periods for clinical records across Europe

GDPR doesn't prescribe specific retention periods for clinical records. National healthcare law determines these. Illustrative requirements include:

• England (NHS): Adult hospital records must generally be retained for a minimum of eight years after the conclusion of treatment. GP records must be kept for ten years after a patient's death.

• Germany: Ten years for medical records under §630f of the Civil Code (BGB), with criminal liability under §203 of the Criminal Code (StGB) for unlawful disclosure by healthcare professionals.

• France: Twenty years from the last care episode under the Code de la Santé Publique.

• Netherlands: Twenty years from the date of recording under the Medical Treatment Contracts Act (WGBO).

Kiteworks' 2026 analysis has documented corrective actions by national health regulators across Europe arising from compliance gaps that GDPR alone doesn't address, a reminder that clinicians need to understand national law alongside the Regulation itself.

Controller vs. processor: who is responsible for what

The data controller, typically the NHS trust, GP practice, hospital, or private clinic, determines the purposes and means of processing personal data and bears primary legal responsibility for GDPR compliance. The data processor, which includes medical record system vendors, diagnostic laboratories, AI tool suppliers, and telemedicine platforms, handles personal data on behalf of the controller and must act only on documented instructions under binding contractual obligations set out in Article 28 GDPR.

The distinction has real practical consequences. If a processor suffers a breach, the controller may still be held liable if it failed to carry out adequate due diligence. Processors may also engage sub-processors, for example a cloud infrastructure provider used by an AI vendor, but only with the controller's authorisation, and the processor remains liable for the sub-processor's compliance. Accountable HQ's 2026 checklist recommends that organisations maintain an up-to-date vendor register and carry out periodic reviews of all active DPAs, including clear procedures for offboarding vendors to ensure data is deleted or returned when a contract ends.

Day-to-day compliance: practical steps for individual clinicians

GDPR compliance in clinical practice doesn't require legal expertise. It requires consistent habits and an awareness of where risk arises.

• Always log out of or lock clinical workstations when you step away, even briefly. Never share login credentials. Use only organisation-approved devices and networks to access patient records.

• Share only the minimum necessary information when referring or communicating with colleagues. Don't use personal email accounts or consumer messaging apps to transmit patient data. Verify the recipient before sending any patient communication, as misdirected correspondence is one of the most common breach types in healthcare.

• Patients can make Subject Access Requests verbally or in writing. Log and escalate these promptly because the one-month response clock starts immediately. Requests for deletion can generally be declined for clinical records during the statutory retention period, but the organisation must respond formally.

• Before adopting any third-party software that processes patient data, confirm that a DPA is in place and that a DPIA has been completed. Ask vendors directly about data residency, sub-processors, and security certifications. If they can't answer these questions clearly, escalate to your information governance team or Data Protection Officer.

• Familiarise yourself with your organisation's privacy notice and data retention policy. Participate in data protection training, including scenario-based exercises covering breach identification and response. If you're uncertain whether a specific activity is lawful, seek guidance from your Data Protection Officer before proceeding.

The regulatory landscape continues to develop. The European Health Data Space framework is introducing new instruments for data sharing and governance that will interact with existing GDPR obligations in ways that national regulators and courts are still working through. Staying informed at both EU and national level is increasingly part of responsible clinical practice.

Frequently asked questions

▶ Why does health data receive stronger protection under GDPR than other personal data?

The dual-basis requirement is the practical consequence. Standard personal data needs only an Article 6 lawful basis. Health data needs that plus a separate Article 9(2) condition satisfied simultaneously. Missing either one is a compliance failure, regardless of how legitimate the clinical purpose is.

▶ Do clinicians need patient consent before writing clinical notes or sending a referral?

No. Article 9(2)(h) covers routine clinical documentation, referrals, and multidisciplinary communication without requiring separate consent. Consent becomes the right basis for research, marketing, or sharing identifiable data with parties outside the direct care team for purposes unrelated to treatment.

▶ What counts as a GDPR breach in a clinical setting?

Most healthcare breaches come from workflow habits rather than cyberattacks. Misdirected correspondence, unattended logged-in workstations, overheard conversations, and consumer messaging apps are the common culprits. If a breach is likely to create risk to individuals, it must be reported to the supervisory authority within 72 hours of the organisation becoming aware of it.

▶ What GDPR obligations apply when sharing patient data with other clinicians?

Sharing within a direct care team is lawful under Article 9(2)(h) where it is necessary and proportionate. In practice, apply the 'need to know' principle: a referral letter should carry what the receiving specialist requires for that episode, and nothing beyond it.

▶ What GDPR checks should clinicians carry out before adopting an AI medical assistant?

Confirm a Data Processing Agreement is signed before any data is transferred. Then ask the vendor five things: where data is processed and stored, whether they hold ISO 27001 certification (an internationally recognised standard for information security management), whether a Data Protection Impact Assessment has been completed, what the deletion policy is, and whether the tool is registered as a medical device under the EU Medical Device Regulation.

▶ Can a patient request deletion of their clinical records under GDPR?

Requests can be refused during the statutory retention period, but the refusal must still be communicated to the patient without undue delay, a separate obligation from the one-month-plus-extension deadline that applies to Subject Access Requests. Retention periods vary: England requires a minimum of eight years after the conclusion of treatment for adult hospital records, France requires twenty years from the last care episode, and the Netherlands requires twenty years from the date of recording.

▶ What is the difference between a data controller and a data processor in healthcare?

The controller sets the purpose and means of processing and carries primary legal responsibility. The processor handles data on the controller's instructions. The important liability point: if a processor suffers a breach, the controller can still be held responsible if it failed to carry out adequate due diligence before signing the contract.

▶ What does data minimisation mean for how clinicians write clinical notes?

Article 5(1)(c) requires data to be adequate, relevant, and limited to what is necessary. In practice, the risk is biographical or social detail that has no bearing on clinical decision-making. Structured templates help because they prompt for specific fields rather than leaving a blank page that can absorb irrelevant personal information.

▶ What patient rights under GDPR are clinicians most likely to encounter?

Subject Access Requests are the most frequent. The one-month response clock starts the moment the request is received, verbally or in writing, so prompt internal logging matters. The right to rectification covers factual errors in records, not a clinician's professional judgement. The right to erasure is largely inapplicable during statutory retention periods.

▶ What practical steps can individual clinicians take to stay GDPR compliant day to day?

Lock workstations whenever you step away. Use only organisation-approved devices and networks. Verify recipients before sending any patient communication, as misdirected correspondence is one of the most common breach types. Before adopting any third-party software that processes patient data, confirm a Data Processing Agreement is in place and a Data Protection Impact Assessment has been completed.