How should organisations handle GDPR when de-identifying health data?

When is health data de-identification enough to take it outside GDPR?

GDPR turns on the real identifiability of the dataset, not the label you apply to it. For health data, that means asking whether the record can still be linked back to a person by reasonable means, directly or indirectly, before treating it as anonymous. The closer the dataset remains to an individual, the more GDPR duties continue to apply.

That assessment is especially important because health information is often highly distinctive when combined with other fields. Dates, locations, rare conditions, treatment patterns and small populations can make re-identification feasible even after obvious identifiers are removed. If the data is only harder to link, rather than truly anonymous, organisations should still treat it as personal data and govern it accordingly.

For a practical guide to judging whether data is truly anonymous, see Anonymisation and Re-identification Risk Guide.

What safeguards matter most when the data is only pseudonymised?

Pseudonymisation is useful, but it does not remove the dataset from GDPR. The main question becomes whether the remaining identifiers, quasi-identifiers and linkage opportunities still expose a person to identification, inference or re-linking. That is why de-identification work should be built around minimisation, controlled access and a clear record of what has been removed, transformed or retained.

For health data, good practice is to reduce attribute detail only as far as the use case allows, separate the mapping key from the analytic dataset, and limit who can re-link records. Organisations should also remember that pseudonymisation can reduce risk without changing the legal classification of the data. That distinction matters when deciding whether GDPR obligations, retention limits and sharing controls still apply.

For a deeper treatment of lawful handling of sensitive data and minimisation, consult Data Minimisation and Identity Data Privacy and Consent Guide.

What does a defensible GDPR approach to de-identified health data look like?

A defensible approach starts with a documented risk assessment that tests identifiability in context, not in theory. That means reviewing direct identifiers, quasi-identifiers, outliers, row uniqueness, small cohorts and any external data sources that could enable linkage. If the dataset is shared outside the original control environment, the organisation should re-check whether the new recipient, purpose or combination of fields changes the risk picture.

It also helps to keep the processing story coherent. If you are using the data for research, analytics or product improvement, your privacy assessment should align the purpose, retention and disclosure model with the actual dataset structure. In practice, that usually means combining technical stripping or generalisation with policy controls, access restrictions and an explicit decision on whether the remaining data is anonymous, pseudonymised or still plainly personal.

For a structured way to record the flow of health data and its control points, use Data flow mapping for security and privacy. For the legal basis and record-keeping side, Record of Processing Activities (ROPA) Template is the natural companion.

Risk and Threat Considerations

De-identified health data creates a false sense of safety when organisations focus on removing obvious identifiers but ignore linkage risk. The main exposure is re-identification, either through quasi-identifiers alone or by joining the dataset with other available information such as location, timing, rare conditions or external datasets.

Failure mechanism: The data remains linkable because the combination of fields still singles out individuals or narrow groups, so the organisation treats personal data as anonymous and drops GDPR-grade controls too early.

Impact: Re-identification can expose sensitive health information, trigger unlawful disclosure, undermine consent and purpose boundaries, and create enforcement or notification risk if the dataset is later mishandled or breached.

Practitioner Guidance

What to verify: Test the dataset against the intended recipient, use case and likely external data sources before deciding it is anonymous. A dataset that is safe in one context may become personal data again once it is shared, enriched or combined.

Decision rule: If you cannot explain why reasonable re-identification is no longer likely, keep treating the dataset as personal data and apply GDPR controls rather than relying on the de-identification label.

Practitioner takeaway: The safest operational position is to prove anonymity, not assume it, especially where health data retains enough structure for linkage, inference or small-population re-identification.

Related resources from NHI Mgmt Group

• How should organisations handle consent for health data submitted through service portals?
• Why do health data files in cloud drives create HIPAA and GDPR risk when visibility is limited?
• How should security teams de-identify health data for HIPAA in a way that preserves enough utility for analytics and AI use cases?
• Who should determine whether health data qualifies for HIPAA de-identification under Expert Determination?