Is your de-identified data still any good? Evaluating dataset usefulness

To work out whether de-identified data is still useful, run the same analyses on the changed copy and the original, then compare the answers.

De-identifying data means stripping or blurring details that lead back to a real person: names, dates, full postcodes and so on. However, every detail you blur is a detail that might have been needed to give the exact answer you want. Think of a photo you pixelate to hide a face. Pixelate a little and the face is still recognisable, but pixelate a lot and you can’t tell whether the photo shows a person or a postbox.

NIST, the US standards body, puts it simply in its review of the research: the harder you push on privacy, the less use is left in the data. So check the two things together – is the data still good enough for the job? Could anyone still work out who is in it?

Step 1: Ask what will be done with the data

You can’t judge whether data is good enough until you know what it’s for. So before anything is changed, ask the person receiving it (the recipient) to name their analyses. Not just “general research”, but the actual list of what the data will be used for and what they will measure:

• The figures that will be reported, such as each customer segment’s share of sales
• The statistical models that will be built
• The datasets they’ll join it to
• The time periods that are relevant

The next question is how far off each answer can be before it would change a decision. If, for example, they say that half a percentage point wouldn’t change anything, but a point would, then half a point is your pass mark. This is called the acceptance criterion. If nobody can name a pass mark, don’t sign off on the release, as there is nothing to test its usefulness against.

At the same time, understand and outline who will receive the data. The UK regulator, the ICO, distinguishes between four situations: using it inside your own organisation, handing it to another, releasing it to a pre-defined group, and releasing it to the world at large. This is very significant: if a named group gets the data under a contract with access controls, you can usually leave more detail in. If you are publishing it to the world, you can’t retract it and have no idea who will download it and what they will use it for, so you have to remove more detail and blur it further.

Step 2: Check the totals and the single rows – the checks fail in different ways

There are two ways the data can break, and each needs its own check.

Totals (aggregate checks). Do the summary numbers still come out right? Look at how values are spread (distributions), the counts in each cross-tabulation, the coefficients from any regression model, and whether categories still rank in the same order by size.

Single rows (record-level checks). Does each individual row still hold what the task needs? A few examples:

• You moved every date by a random amount. Do events in one case still happen in the right order?
• You cut ‘SW1A 1AA’ to ‘SW1A’ or a region. Does that still match the area the client reports on?
• You swapped real customer IDs for made-up codes. Can you still link the same person across files, where that linking is allowed?

The totals can look fine while the rows are broken, and the other way round.

The ICO gives a small example of why the privacy check belongs in the same review. Picture a six-row table with age in ten-year bands, a hospital area and a medical condition. Even after that blurring, four out of the six people could still be singled out: two by their age band alone, and two by combining age with location. One choice, like how wide to make the age bands, changes both usefulness and privacy at once. That is why the two must be checked together, and why the choice of de-identification vendor matters so much.

Step 3: Hold back some data for a final test

Set aside a slice of the records, plus some queries. Run your pass-mark checks on that slice once, at the very end of tweaking your settings.

Why? Because a transformation that adjusts the blurring until its headline numbers look right has been fitted to the exact records used for that adjustment. Like a student who memorises last year’s exam paper, it has only proved it can pass that paper. The held-back slice of records is the unseen exam, telling you whether the transformation settings work on data they weren’t tuned to.

A consumer panel company has a year of grocery purchases. A market research client wants three numbers from it:

To protect privacy, the company did three things. It replaced store locations with regions, moved each purchase’s timestamp by a random amount, and swapped household IDs for codes used only in this release.

The repeat-purchase figure broke because of the altered timestamps. Each purchase got its own random shift, so two shopping trips 11 weeks apart might end up 13 weeks apart, and so no longer count as a repeat. The fix is to give every purchase in one household the same shift, hiding the real calendar but preserving the gaps the metric measures.

Step 4: Describe both sides in real-world terms

The trade-off is only easy to weigh when you describe the loss of usefulness and the remaining privacy risk in terms of what actually happens to people.

The cost of losing utility. NIST describes a study by Fredrikson and colleagues on warfarin, a blood thinner where getting the dose wrong is dangerous. They built models that suggest a dose from a patient’s genes, using clinical trial data. Some models used differential privacy, a mathematical technique that adds carefully measured random noise so no individual can be picked out. In simulation, the private models would have led to worse outcomes for a significant number of patients. That’s what “lost utility” means once it is put in real terms: patients doing worse.

The remaining privacy risk. The same report covers a test of HIPAA Safe Harbor, a US rule that says which fields to delete from health data. When only the year of birth, sex and the first three digits of the ZIP code were left, under 1% of records could be re-identified. Add a few more details and the risk can jump.

The UK test: the ‘motivated intruder’. For a UK release, the ICO asks you to picture a reasonably capable person with internet access and public records, who is willing to ask around among people who might know more. Could they work out who someone is? The classic case, which the ICO cites, is the 2006 Netflix Prize dataset. Netflix released film ratings with names removed. Researchers matched them against public reviews on IMDb, identified the Netflix records of known users, and could see apparent political leanings from what they watched.

Step 5: Write it down, and check again when things change

The ICO expects you to record your decision about identifiability, explain why you made it, and review it as technology and your use of the data change. The risk creeps up over time. NIST notes that re-identification usually gets easier as techniques improve and more outside information becomes available, whether published or for sale.

Additionally, the Data (Use and Access) Act has put the ICO’s anonymisation guidance under review. Always check its current wording before relying on a specific test.

A short record makes the re-checking quick. Note down:

• The analyses tested
• The pass mark for each
• The records held back for re-testing
• The transformation settings
• The recipient of the data and on what terms
• What other data you assume the recipient has

Run the comparison when a new batch of data adds variables, when the recipient acquires another data source, or when they ask a question you didn’t test. A release that passed last year passed against last year’s outside information.

Jargon glossary