Data anonymization is an irreversible strip of personal details so a record cannot be traced back to one person. A concert crowd with the faces blurred: you can still count the crowd, you cannot name anyone in it. This page is that definition — tabular privacy, HIPAA Safe Harbor, GDPR, linkage. It is not a DICOM how-to.
If you meant DICOM files specifically → DICOM anonymizer software (tools) or DICOM anonymization using Python (pydicom). If you meant HIPAA transfer / Dropbox → HIPAA compliant data transfer. If you meant what DICOM is → what is DICOM.
k-anonymity (Samarati / Sweeney) is a related tabular guarantee: every record is indistinguishable from at least k−1 others on the quasi-identifiers. This page names it so the query has a home. It does not teach how to compute k, and it does not invent a second article for it.
Anonymization vs pseudonymization
| Anonymization | Pseudonymization | |
|---|---|---|
| Reversibility | No key. Identifiers are gone or altered for good | A separate key can re-link the record |
| Risk | Re-identification only via leftover quasi-identifiers + outside data | The key is itself a target; the dataset is still personal data under GDPR |
| Use | A public release, an open research dump, a figure that must not name anyone | A trial that still has to follow one patient over time |
Pseudonymization is a codename. Anonymization is a deletion. If someone can still get back to the person with a key you hold, you did not anonymize — you pseudonymized, and the GDPR file is still open.
Why it is mandatory
Two statutes do most of the work in medical data. GDPR (EU) treats personal data as anything that relates to an identifiable person — name, but also IP, device id, a precise location. Fines go up to 4% of global annual turnover (GDPR Art. 83). Once the data is actually anonymous — re-identification not reasonably likely — it leaves that scope. HIPAA (US) has a checklist route for the same idea: Safe Harbor, below. Transfer of the bytes (a BAA, a Dropbox question) is HIPAA compliant data transfer, not this definition.
Four tabular techniques
Take a toy record: name, age 47, ZIP, a diagnosis. None of this is a DICOM tag. It is a row.
- Suppression. Delete the name. First pass on every direct identifier.
- Generalization. Age 47 becomes 40–50; a ZIP becomes a city or the first three digits. Useful, less exact.
- Masking. Replace the name with a plausible fake that keeps the format. Good for a test database that still has to look like production.
- Perturbation. Nudge 47 to 45 or 49. One row is wrong; the histogram can still be right. Used when the model cares about the distribution, not the person.
There is no best method. Over-generalize and a study that needed age 42 vs 58 is dead. Under-strip and a linkage attack (next section) puts the name back. k-anonymity is one way to state the generalization target; it is not a fifth technique on this list.
HIPAA Safe Harbor — the 18 identifiers
HIPAA’s Safe Harbor method (45 CFR 164.514(b)(2)): remove these 18, and the data is no longer PHI under that method. The expert-determination route is the other door; this page does not walk it.
- Names
- Geographic subdivisions smaller than a state (street, city, ZIP — with a narrow 3-digit ZIP exception)
- Dates (except year) tied to the person: birth, admission, discharge, death; ages over 89
- Telephone numbers
- Fax numbers
- Email addresses
- Social Security numbers
- Medical record numbers
- Health plan beneficiary numbers
- Account numbers
- Certificate / license numbers
- Vehicle identifiers and license plates
- Device identifiers and serial numbers
- URLs
- IP addresses
- Biometric identifiers (finger, voice)
- Full-face photographs and comparable images
- Any other unique identifying number, characteristic, or code (except a permitted re-id code held separately)
That list is why a “we deleted the name” export still fails. Device serials, MRNs, and a birth date are on it. DICOM headers carry several of these as tags — one sentence, not a second how-to. The tag-strip is DICOM anonymization using Python; the product list is DICOM anonymizer software.
GDPR and identifiability
GDPR does not hand you an 18-item list. It asks whether a person is identifiable, including by combining the file with data a motivated party can get. An IP or a rare job title can be enough. Recital 26 is the usual cite: account for means reasonably likely to be used. “We hashed the name” is often still personal data.
Linkage attacks
A linkage attack joins your “anonymous” table to a public one on the leftover columns. Sweeney (2000) showed that ZIP + date of birth + sex uniquely identified a large share of the US population against voter rolls. The number is famous; the mechanism is the point. Quasi-identifiers (not names) do the join.
Messy data makes the same hole: a clinical note that mentions a spouse and a street; an audio consult; a medical-image header that still holds Patient’s Name. Those are pitfalls, not a reason this article becomes a DICOM tutorial.
A strategy, not a project
Map what you hold and how it identifies someone. Pick a technique that matches the use (mask a test DB; generalize a public dump; perturb a model set). Write who may see the output. Put the strip in the pipeline so a new export does not skip it. Then try to break your own file with public data. If you can re-link it, it was not anonymous.
FAQ
Anonymization vs encryption?
Encryption is a lock. The key opens the original. Anonymization is a redaction. There is no key. Encrypted PHI is still PHI. Encrypted data in transit is a transfer problem — HIPAA compliant data transfer.
Can anonymized data be reversed?
If the strip was thin, yes — that is the linkage attack. The goal is “not reasonably likely,” not a magic word in a filename.
Does all data need it?
No. Only data that can identify a person (PII / personal data / PHI). A machine-temperature log with no people in it does not. A ZIP + birth date + sex table does, even without a name column.
PYCAD’s imaging work sits next to this problem when the files are DICOM. The definition stays here. Case studies.