Anonymising health data: what works, what doesn't exist

"Just remove the name." Really? A date, a pixel, a turn of phrase in a report or a DNA sequence is enough to re-identify a patient. Anonymise, structure, protect, host: what works, what doesn't exist, and where the law requires this data to be hosted.

"Just remove the name." That is what people often believe when it comes to anonymising health data. In reality, a date, a pixel, a turn of phrase in a report or a DNA sequence is enough to re-identify a patient. In spring 2025, I devoted a series of posts to this subject: what works, what does not exist, and where the law requires this data to be hosted. Here they are, gathered together and put back in order.

"The more data, the better." False.

Especially in health. Because the more data you have:

• the more complex it is to anonymise,
• the riskier it is legally,
• the harder it is to maintain, both technically and in human terms.

And the CNIL (France's data protection authority) does not mess about: fines of up to 20 million euros or 4% of worldwide turnover for breaching the RGPD (GDPR), including for excessive data collection.

In health, data is not a bonus. It is a critical resource: regulated, sensitive, binding. The real lever is not collecting "as much as possible". It is targeting the data that is genuinely useful, and turning it into product value. And that is worked out from the design stage, not at the end, when it is too late to reframe everything.

Worth remembering if you work on a health product:

• More data = more risks (legal, technical, human).
• Quantity never replaces relevance.
• You do not "manage" data at the end: you do it from the product scoping stage.
• Clarifying why you collect what is a product exercise, not just a legal one.

RGPD, CNIL, HDS: three responsibilities we confuse

Three acronyms you come across everywhere when working on a health product. Three different responsibilities… that we forget to tell apart.

• The RGPD is the legal framework (and no, it does not ban the use of health data).
• The CNIL is the supervisory authority, not an authorisation service.
• The HDS (Hébergeur de Données de Santé, France's health-data hosting certification) is a technical certification, not a guarantee of compliance.

And the classic mistake is to think that an HDS host "covers" the rest. Three questions to keep in mind: which cases of health data processing are permitted, what the CNIL actually checks, and what an HDS host really guarantees (and what it does not).

Anonymising dates

A single date is rarely identifying. But as soon as you have two, for example a date of birth and a date of death, the risk of re-identification rises considerably. You can imagine other combinations: a diagnosis date and an MRI date. And if, on top of that, you know the location… jackpot. The identity becomes fairly easy to guess.

This has been demonstrated: the triplet of postcode + date of birth + sex is unique for 80% of the United States population.

So what do we do?

1. Check whether you really need the date for the analysis. If not, simply do not collect it.
2. Reduce the precision of the date. For a date of birth, you can remove the day, or even the month. You dilute the information, which limits the risk of re-identification.
3. If per-individual consistency is not needed, shuffle the dates between people (randomisation). The overall statistics stay correct, but the information can no longer be exploited at the individual level.
4. If you must keep per-individual consistency, add noise: this is dateshift. Each individual is assigned a random offset, applied to all of their dates. You mask the raw information but keep the temporal logic.

Bonus: sometimes it is the other way round. We are missing data… so we invent it. Example: we have biopsy dates in DD-MM-YYYY format, but for one patient we only have MM-YYYY. Two options: exclude them (a shame, as it is not easy to find patients who meet a project's criteria), or arbitrarily fix a day (the 15th of the month). Otherwise, you cannot compare the dates with one another. But that is another subject: data quality.

Anonymising an image's metadata (DICOM)

Anonymising medical images means first understanding what surrounds the pixels.

Medical images are stored in the DICOM format (Digital Imaging and Communication in Medicine). This format contains both the image data (pixels) and a header rich in metadata: name, dates, type of examination, machine used…

Each type of image has its own SOP Class:

• DICOM-CT for CT scanners,
• DICOM-MR for MRI,
• DICOM-SEG for segmentations (often produced by AI),
• DICOM-RT for radiotherapy,
• DICOM-SR for structured reports…

Some fields are common to all DICOM files, but others are specific to the type. And of course… the private tags, where manufacturers and users can put whatever they like (otherwise it would be too easy). A typical DICOM field is, for example, (0010,0010) Patient's Name, (0010,0020) Patient ID, (0008,0060) Modality or (0008,1030) Study Description.

For anonymisation, DICOM offers a confidentiality profile:

1. The Basic Application Level Confidentiality Profile, which removes all directly identifying information, pseudonymises the dates, serial numbers and UIDs, and removes the private fields (unless you decide to keep them).
2. Depending on the use cases, you activate Named Options to adjust what you keep:

• Retain Patient Characteristics: keep age, sex, weight (useful in clinical research).
• Retain Longitudinal Temporal Info: keep the chronology (D+2, D+5) without keeping the real dates.
• Retain Safe Private Attributes: keep certain private tags considered non-identifying.
• Retain Device/Institution Info: analyse the performance of equipment or centres.
• Retain UIDs: keep the technical DICOM identifiers (for consistency across files).
• Clean Pixel Data: remove text burned directly into the images (more on this shortly).

DICOM therefore provides a clear process for anonymising metadata. But you still have to look at each field in detail depending on the project. Whatever the type of data, it always comes back to the same thing:

Reduce re-identification risk while maintaining the usefulness of the data.

The real question is always: what still makes it possible to re-identify the patient?

Anonymising an image's pixels

Anonymising a medical image… by hand? DICOM files contain two types of information: the image pixels (what the radiologist sees… or the AI), and the metadata (name, date, patient ID, device, protocol…). I talked about the metadata just before. Here, we are talking about the pixels.

Yes, the image itself can contain embedded text, directly visible on screen (patient name, ID, department…). This is called burned-in text. Three difficulties:

1. Identifying the embedded text

Is it identifying text (to remove) or clinical text (to keep, such as organ names)? Some image types are known to be risky, ultrasound scans for example. You need to extract the text from the pixels (OCR), cross-reference it against a database of sensitive words (name, ID, location…) and decide what to mask. Specialised tools exist: DCMTK, Microsoft Presidio DICOM Redactor, Google Cloud Healthcare API…

2. Masking without introducing bias

A black rectangle is simple to add. But in AI, it can create a learning bias: if all the images from one hospital have a masked corner, the model may use it as a clue.

3. Preventing re-identification through facial recognition

Some 3D brain MRIs make it possible to reconstruct an identifiable face. And yet we want to anonymise this very data in order to analyse it (yes, it sounds absurd). Some approaches are being evaluated: DeepDefacer (supervised deep learning), conditional GANs to generate an artificial but structurally faithful face.

So? A human review remains essential, at least on a representative sample.

A human quality control process to confirm the efficacy of the de-identification process should be used.

Anonymising a medical report? I don't recommend it.

A name, a date? Fine, we know how to do that. But a "resident of the Sainte-Anne care home", a "brother admitted to Purpan hospital", or "10 years of post-transplant follow-up"? That is where it gets complicated.

What we anonymise is free text. Unstructured. Full of implicit meaning. Dictated on the fly. And every word can be a clue for re-identifying a patient (reminder: 10% of the patients in a research project can be re-identified). Reports cross-reference everything:

• administrative information,
• clinical context,
• social and family details,
• sometimes even the patient's address or the name of their pharmacist.

The possible techniques?

• Regex / expert rules: useful, but fragile.
• NER (Named Entity Recognition): spots names, dates, places… as long as you stay within scope.
• Medical NER (Spark NLP, medSpaCy): more accurate, but depends on quality annotated corpora.
• Local LLMs (Mistral, Llama-3): promising on context, but can remove non-sensitive information, remain prone to semantic bias if poorly framed, and are costly to deploy.

And none of these approaches really handles the edge cases: indirect references, implicit cross-references, domain bias, spelling mistakes.

My recommendation? Don't anonymise. Structure. Rather than running models to "clean up" free text, it is better to structure the useful information: extract, map, qualify. The result: less sensitive data to manage, greater analytical robustness, and above all a more controllable processing chain. We do not need to know everything. We need to know what is useful, and to structure it.

You don't anonymise the genome. You protect it.

A genome is not a piece of data. It is a signature. And a signature cannot be anonymised. It has to be protected. A genome is unique, stable over time, correlatable with other databases, and therefore enough to re-identify a person, or even their relatives.

For reference: a piece of genetic data is targeted information (BRCA1 mutation for breast cancer, CFTR variant for cystic fibrosis…). A piece of genomic data is the complete sequence of the genome, in A, C, G, T. It is like the difference between a test result… and a fingerprint.

Even with de-identified genetic data, re-identification is possible:

• Lin (2004): with at most 80 SNPs (small variations in DNA, ~0.0000025% of the whole genome), you can identify an individual in a genetic database.
• Gymrek (2013): "anonymous" participants are found by cross-referencing their Y-chromosome profile with online genealogy databases.
• Erlich (2018): family ties are used to re-identify people from open databases (GEDMatch).
• Ney (2020): genetic data can be leaked by uploading fake information onto genetic genealogy sites.

This last paper is incredible:

1. You create a fake DNA profile (a file you control).
2. You upload it to a site that offers to "find genetic relatives".
3. The site compares your file with its database… and tells you the matches.
4. If the file is well constructed, you can deduce genetic fragments from profiles already stored.

Conclusion: no, you do not anonymise genetic and genomic data. You protect it. In practice: you never expose the full sequence in standard tools; you extract only the mutations of interest, when justified; you compartmentalise access and log everything.

An alternative: do not move the data, move the algorithms. Federated learning makes it possible to train models directly on site, without transferring raw data. It limits the risk by design.

The Health Data Hub: the awkward hosting choice

For those who do not know it, the HDH (Health Data Hub) is the French platform that makes accessible (on paper at least) a whole range of data for research, broadly the billing data, and that is already very useful to analyse.

In 2023, the CNIL approved hosting the HDH with Microsoft Azure, a US company, and therefore subject to the Cloud Act. Okay, anyone can make a mistake: the CNIL itself acknowledges that this choice was tricky. It is hardly ideal to place sensitive data with a host that is obliged to provide access to our data whenever the US courts request it.

And so we go ahead with a 3-year contract, promising that by the end of 2025 we will have migrated to a sovereign cloud. It is now May 2025. There was a question in the National Assembly in April. There is discussion of an "interim solution". But in concrete terms, is anything actually moving forward? I honestly can't tell.

To be HDS or not to be

There are currently 336 HDS-certified hosts in France. But who is required to use one? And in what context?

A regulatory reminder:

• The HDS hosting obligation is set out in article L1111-8 of the Code de la santé publique (French Public Health Code).
• It applies to any entity that hosts personal health data on behalf of a third party.

But also: as soon as you outsource the hosting of personal health data, you must go through an HDS-certified provider, even if you are the data controller. In plain terms:

• Processing a hospital's data? → HDS required.
• Publishing SaaS health software? → HDS required.
• Storing data with an external cloud provider (even a French one)? → HDS required.
• Processing only your own data, hosted in-house? → HDS not required.
• Working on anonymised data (in the sense of the RGPD)? → HDS not required.

What this changes in practice: using an HDS-certified host is not a marketing label. It is a legal obligation, overseen by the ANS (France's digital health agency), audited every year, valid for 3 years.

In summary

One thread runs through this series: anonymising health data is almost never about "removing the name". It is a constant trade-off between reducing the risk of re-identification and keeping the data useful. Depending on the type of data (a date, a pixel, free text, a DNA sequence), the right answer changes. And for some, such as the genome, anonymisation does not exist: only protection remains. All of this within a framework (RGPD, CNIL, HDS, HDH) that is well worth not confusing.

Read next

Build in Public

I wanted to build my own app without knowing how to code

AI & Health

AI in healthcare: chronicle of a summer