De-identify data properly before it goes anywhere

Removing the name is not the job

HIPAA describes two ways to de-identify a dataset. One is expert determination: a qualified person applies statistical methods and documents that the risk of re-identification is very small. The other, and the one most people are reaching for, is Safe Harbor: strip eighteen categories of identifier, and have no actual knowledge that what remains could identify anyone.

Eighteen categories is a great deal more than a name. It includes every element of a date more precise than a year — admission, discharge, procedure, birth — and it includes ages over 89. It includes geography below state level, with the initial three digits of a ZIP code permitted only where the area they cover holds more than twenty thousand people. It includes record numbers, account numbers, device identifiers, URLs, IP addresses, email addresses, phone and fax numbers, and full-face photographs.

The eighteenth is the one that actually bites: any other unique identifying number, characteristic, or code. That is not a loophole to argue with. It is the rule that makes the exercise about the whole record rather than the obvious columns.

The parts people consistently miss

Free text. Structured columns get cleaned and the notes field does not, and the notes field is where somebody wrote “saw her at the school fete.” Read it, or drop the column entirely.

Dates. Removing the name and keeping the exact date of a procedure at a named practice re-identifies a small population immediately. Shift dates consistently or reduce them to a year.

Rarity. A condition that occurs a handful of times a year, in a stated city, in a stated age band, is identifying with no name attached anywhere. Small cells are the problem, not missing columns.

The file itself. Filenames carry patient names startlingly often. Spreadsheet metadata carries the author, the practice, and revision history. Photographs carry location and device. Removing a column from the visible sheet does not remove it from the file’s properties or from a hidden tab.

How to actually do it

Work on a copy, always, and treat the original as untouchable. Replace identifiers with sequential codes rather than deleting them, so the rows stay usable and joinable — Patient 001, Patient 002 — and keep the mapping between code and person somewhere the AI tool never sees, if you keep it at all.

Delete columns you do not need for the question rather than de-identifying them. The fastest way to protect a field is not to include it.

Then re-read the result as though you were trying to break it. Pick the strangest row and ask what you could work out about that person from what is left, given anything you already know. If the answer is uncomfortable, the file is not ready.

Do not ask the AI tool to de-identify it for you

This is the trap, and it is a natural mistake to make. Asking a model to strip the identifiers from a file requires uploading the file with the identifiers still in it. The disclosure has already happened by the time the model answers; the work has to be done before anything is pasted or attached.

The same reasoning applies to a script written by an agent. Have it write the de-identification script against invented sample rows, then run that script yourself, on your own machine, against the real file.

It also applies to convenience features that are easy to forget about: file sync, chat history, cloud backup of the folder you are working in. De-identifying a file after it has synced to a shared drive does not un-sync the earlier version.

When de-identification is the wrong answer

If the work needs the identifiers — writing to a specific patient, reconciling a specific chart, checking a specific claim — then de-identification is not a workaround. It is a different task from the one in front of you. Use a route the directory records as covered instead, and read its posture scope before you rely on it.

If the work is research, the sequence is not “de-identify, then proceed.” Ask the IRB first. A de-identified dataset can still be a protocol deviation, and that is a conversation nobody wants to have retrospectively.

And if you are not a covered entity, none of this stops mattering. State consumer-health law reaches data HIPAA never touches, and Safe Harbor is a useful discipline regardless of whether it is the standard you are being held to.