A lot of people hear “anonymized health data” and mentally file it under “safe.” Italy’s privacy regulator didn’t. It fined IQVIA €7M after finding its Italian unit built a database of roughly 1M patients from about 800 GPs, using a unique patient code that still allowed tracking over time. Pair that code with rich details like year of birth, sex, diagnoses, prescriptions, tests, vaccinations, and location, and you’re no longer talking about anonymous data in any practical sense. We’ll break down how re-identification happens, what the regulator flagged beyond anonymization (legal basis, notice, retention, even direct identifiers in a subset), and what healthcare data teams should do differently—starting this week.
What Italy said went wrong (and why it matters to anyone handling health data)
Italy’s regulator (the GPDP) didn’t treat this as a theoretical “anonymization debate.” It treated it as a real GDPR health data risk: people could still be singled out and re-identified with reasonable means.
The core issue wasn’t that IQVIA kept patient names in the main dataset. It was that the Italian unit built a database of roughly 1 million patients by aggregating data from about 800 general practitioners, then assigned a unique code to each patient. The GPDP’s point was simple: a longitudinal unique patient code lets you follow someone across time—visits, prescriptions, tests—so the dataset still behaves like personal data, even if you’ve removed obvious identifiers .
And the dataset wasn’t “thin.” The GPDP described a very detailed set of fields—year of birth, sex, diagnoses, symptoms, prescriptions, tests, vaccinations, plus location data—that, when combined with that code, made it possible to single out individual patients and potentially reidentify them . This is the uncomfortable truth of GDPR anonymization: the structure of the data can identify people, even when the “name column” is gone.
The fine wasn’t only about anonymization
The decision also flagged basic GDPR compliance failures that show up in a lot of health analytics programs:
- No appropriate legal basis for processing, as found by the authority
- No patient notice / lack of transparency (people weren’t informed their health data was being used this way)
- No defined retention period, with records going back as far as 2001
- A subset of around 3,300 patients allegedly included direct identifiers like names, tax identification numbers, addresses, and contact details
If you work with “anonymized” or “de-identified” health datasets, this matters because it’s the exact pattern many teams rely on: swap names for a code, keep rich clinical detail for usefulness, and assume the result is safe. Italy’s message was that this combination can still fall squarely inside GDPR risk—especially when the dataset is longitudinal and linkable over time .
How “anonymous” breaks in real life: the re-identification mechanics (no math, just reality)
Once a regulator decides a dataset can single out a person and reidentify them using reasonable means, the “we removed names” argument collapses .
Here’s how that collapse happens in real life.
1) Removing names isn’t the same as removing identifiability
Teams often equate “anonymous” with “no direct identifiers.” That’s a category mistake.
A unique patient code can function like a shadow identity. It doesn’t say “this is Maria Rossi,” but it does say “this is the same person again,” across:
- GP visits
- prescriptions
- lab tests
- vaccinations
- diagnoses over time
That continuity is the problem. Italy’s GPDP focused on the fact that a per-patient code can make tracking possible over time .
2) Attribute pile-ups create a fingerprint (even when each field is “normal”)
Single fields are rarely identifying. Plenty of people share a birth year. Plenty share a diagnosis.
What becomes identifying is the combination, especially in GDPR health data where the fields are rich and specific. The GPDP highlighted exactly the kind of attributes that stack into a fingerprint:
- year of birth
- sex
- diagnoses and symptoms
- prescriptions
- tests
- vaccinations
- location data
Think of it like this: one tile doesn’t show the full mosaic. Ten tiles often do.
3) Time is an identifier all by itself
A longitudinal dataset quietly adds a powerful field: sequence.
Even if a single snapshot feels “anonymous,” a timeline of events (new prescription → test → diagnosis change → follow-up) can narrow the set of possible people fast. That’s why regulators worry about singling out—being able to point to one record as “that person,” even before you attach a name .
4) “Reasonable means” is the standard that keeps getting ignored
Re-identification doesn’t require Hollywood hacking. “Reasonable means” can include:
- matching against other datasets an organization already holds
- combining location with public knowledge (small communities make this easier)
- using internal access (people inside an org often have more context than they admit)
Italy’s GPDP explicitly connected the dots: detailed attributes + a trackable code can allow singling out and reidentification using reasonable means .
If you build, buy, or share de-identified health datasets, this is the practical test: can someone keep recognizing the same patient record, and does the data around it narrow down who that person is? If yes, you’re not in “anonymous” territory anymore—you’re in “still identifiable, still regulated” territory.
Anonymization vs. pseudonymization: the line teams keep stepping over
If you take one thing from the IQVIA fine, make it this: a dataset can be “coded” and still be personal data.
The clean definition (the one teams forget mid-project)
Anonymization
Data is anonymized only when it’s no longer possible to identify a person, even indirectly, using reasonable means. If re-identification is realistically possible, regulators won’t treat it as anonymous.
Pseudonymization
Pseudonymization is when you replace direct identifiers (like name) with a code. The person can still be linked back under certain conditions—sometimes by the same organization, sometimes by someone else with enough context.
In the IQVIA case, the GPDP’s reasoning tracks this logic: using a unique code instead of names didn’t settle the question. The authority focused on whether that code enabled tracking and whether the dataset could still be tied back to individuals in practice .
Why “we encrypted it” doesn’t end the GDPR conversation
A lot of health data teams assume encryption is a magic eraser: “If the data is encrypted, it’s safe. If it’s safe, it’s anonymous.”
Encryption is important. It reduces exposure risk. It can be a required safeguard.
But encryption doesn’t change what the data is. Encrypted personal data is still personal data. Same for pseudonymized personal data.
IQVIA’s statement after the decision is a good snapshot of how this often plays out inside organizations: the company said protecting data is a core priority and that it maintains safeguards, including pseudonymization and encryption, and it reserved the right to appeal . The GPDP still found the anonymization claims didn’t hold up to the dataset’s identifiability risk .
The practical test for healthcare analytics teams
When someone says “it’s anonymized,” ask three uncomfortable questions:
- Can we link records about the same patient over time? (If yes, you’re likely in pseudonymization territory.)
- Could a person be singled out from the data we kept? Regulators care about singling out, not just naming.
- If we combine this with other data we already have, does the code stop being “just a code”? If the answer is “maybe,” treat it as GDPR personal data and design controls like you mean it.
This is the line teams keep stepping over: they build a dataset for longitudinal value, then label it “anonymous” because the obvious identifiers are gone. Regulators look past labels and into mechanics and realistic re-identification paths .
A practical compliance playbook: lawful basis, transparency, retention, and damage control in 120 days
When a regulator orders a fix in 120 days, that’s not a policy refresh. It’s triage plus proof. In the IQVIA case, the GPDP paired a €7M fine with an order to bring practices into compliance within that window .
Here’s a practical, week-one playbook for GDPR health data teams.
1) Lock down the fundamentals (or nothing else matters)
1) Lawful basis (write it down, tie it to processing reality).
The GPDP flagged processing without an appropriate legal basis . Your task is to map each purpose (analytics, research support, market insights, etc.) to its lawful basis and document it.
2) Transparency and patient notice (close the “silent collection” gap).
The GPDP also flagged that patients were not informed . Update notices so they’re readable and specific:
- what data is used (at a category level)
- where it comes from
- who receives it
- why it’s processed
- how long it’s kept
3) Retention limits (stop “we keep it because it’s useful”).
Undefined retention was a cited failure, with records dating back as far as 2001 . Set retention by purpose, then implement deletion/archival that actually runs.
2) Reduce re-identification risk without killing utility
Treat “anonymous” as a claim you have to defend continuously, not a one-time label.
Operational moves that usually pay off fast:
- Minimize attributes: keep only what you can justify for the purpose.
- Reduce granularity (location is a repeat offender): less precise geography, fewer rare flags.
- Separate linkage keys: don’t let the same teams hold rich health attributes and the key material that makes linking easy.
- Tight access controls: role-based access, least privilege, logging, and periodic access reviews.
- Re-test identifiability as datasets grow: longitudinal data gets more identifying over time, even if your first cut looked “safe.”
3) Do an “oops identifiers” sweep before you share anything
This is the part that stings, because it’s preventable.
The GPDP found a subset of records that included direct identifiers like names, tax identification numbers, addresses, and contact details . That’s a pipeline failure, not a theory problem.
Put a hard gate in front of export, analytics, and partner sharing:
- automated scans for direct identifiers (name fields, tax IDs, emails, phone patterns)
- schema validation (block unexpected columns)
- sampling + manual review for high-risk extracts
- quarantine and incident workflow when something is found
If you’re rebuilding fast under a regulator timeline, this gate is your best “damage control” move. It prevents a pseudonymized dataset from quietly turning into a direct-identifiers dataset the moment someone adds the wrong join.
What this means for patients—and a simple way to reduce everyday exposure
Most patients hear “de-identified” or “anonymized” and assume the story ends there. Real life doesn’t work that way.
Your health data rarely lives in one neat folder labeled “care.” It gets copied into patient portals, billing systems, appointment tools, labs, imaging providers, specialty clinics, pharmacies, wellness programs, and analytics vendors. Even when each party thinks they’re handling “anonymous” data, linkable details can travel with it across time.
That’s the practical risk patients face: identity stitching. Not always from one big breach, but from lots of small linkages:
- the same email used on multiple portals
- the same phone number reused for every appointment reminder
- the same home address shared with a one-off provider
- a “helpful” intake form that asks for extra demographic info
None of that is medical. All of it is glue.
A simple habit that cuts down linkage
You usually can’t control how organizations build datasets. You can control how easily your identity connects across systems.
When you’re signing up outside your core care team (think: wellness program, a new portal for a single clinic visit, a pharmacy discount account, a telehealth trial, a one-time lab), use masked contact details:
- Use an alternative email for signups you don’t fully trust or won’t use long-term
- Use an alternative phone number for SMS reminders and verification codes
- Keep your “real” email/number for your main providers and insurance
This does two things:
- It reduces cross-service linkage if data moves around later.
- It limits the fallout if one system leaks contact details or starts spamming you.
If you want an easy way to do this without juggling burner accounts, Cloaked can generate alternative emails and phone numbers that still receive messages, so you can give a working contact method without handing over the one identifier you use everywhere. It’s not a cure for bad data governance, but it helps when the risk is linkage, not just leaks.
Privacy isn’t only about hiding. It’s about not making it effortless to connect the dots.
