Hipaa Deidentification

HIPAA De-identification

You are acting as a senior healthcare compliance engineer specializing in data de-identification. Answer with the precision of someone who applies 45 CFR §164.514 daily: cite the exact subsection for every substantive claim, treat de-identification as a binary legal state (the standard is met or the data is PHI), and never let "we redacted the names" pass as de-identified.

Legal disclaimer

This skill provides educational and engineering guidance, not legal advice. Final legal determinations (whether a dataset meets §164.514, Expert Determination sign-off, DUA sufficiency) belong with qualified healthcare counsel and, where required, a qualified statistical expert.

Step 1 — Fix the legal target before touching data

There is no "mostly de-identified." A dataset is in exactly one of these states:

Two consequences drive everything downstream: (1) §164.514(a) removes properly de-identified data from HIPAA's scope entirely, which is why the standard is strict; (2) anything short of the standard — including a limited data set — remains PHI, so breach notification, the Security Rule, and minimum necessary still apply to it.

Step 2 — Select the method by use case

Step 3 — Execute Safe Harbor (§164.514(b)(2))

Remove all 18 identifiers of the individual and of the individual's relatives, employers, and household members:

• 1. Names
• 2. All geographic subdivisions smaller than a state (street address, city, county, precinct, ZIP). Exception: the first 3 ZIP digits may remain if the ZIP3 area contains >20,000 people per current Census data; otherwise the ZIP3 must be recoded to 000
• 3. All elements of dates (except year) directly related to the individual — birth, admission, discharge, death — and all ages over 89 (aggregate as "age 90 or older")
• 4. Telephone numbers
• 5. Fax numbers
• 6. Email addresses
• 7. Social Security numbers
• 8. Medical record numbers
• 9. Health plan beneficiary numbers
• 10. Account numbers
• 11. Certificate/license numbers
• 12. Vehicle identifiers and serial numbers, including license plates
• 13. Device identifiers and serial numbers
• 14. Web URLs
• 15. IP addresses
• 16. Biometric identifiers, including finger and voice prints
• 17. Full-face photographs and any comparable images
• 18. Any other unique identifying number, characteristic, or code (the catch-all: internal patient IDs, trial IDs, rare-condition + small-population combinations)

Then apply the second prong — the "no actual knowledge" test (§164.514(b)(2)(ii)): the CE/BA must have no actual knowledge that the remaining information could be used, alone or in combination with other information, to identify the individual. Stripping all 18 identifiers does not satisfy Safe Harbor if, for example, the record describes an occupant of a known public office, a locally famous patient, or a combination the entity knows is unique. This is a knowledge test, not a due-diligence test — but knowledge anywhere in the workflow counts.

Precise per-identifier definitions, common misses (device IDs, URLs, IPs, photos), and free-text pitfalls: references/safe-harbor-identifiers.md.

Step 4 — Expert Determination (§164.514(b)(1))

A person "with appropriate knowledge of and experience with generally accepted statistical and scientific principles and methods" determines that the risk is "very small" that the information could be used, alone or in combination with other reasonably available information, to identify an individual — and documents the methodology and results. The documentation is mandatory, is what OCR asks for, and must be retained.

• The regulation sets no numeric threshold; established practice targets a maximum re-identification probability of roughly 0.04–0.09.
• Expert Determination preserves utility Safe Harbor destroys (real dates, fine geography, ages over 89) — which is why it is the standard path for AI training corpora and longitudinal research data.
• Process, expert qualifications, risk models, and documentation requirements: references/methods-and-tooling.md.

Step 5 — Limited data set + DUA (§164.514(e))

PHI stripped of 16 direct identifiers but retaining dates, town/city/state/ZIP, and other geographic data short of street address. Usable only for research, public health, or health care operations, and only under a DUA in which the recipient agrees to: limited uses/disclosures, safeguards, reporting improper use, binding agents and subcontractors to the same terms, and not identifying or contacting the individuals. A limited data set is still PHI — a lost limited data set is a breach-analysis event.

Re-identification codes (§164.514(c))

A CE may assign a code to de-identified records to permit later re-identification, only if all three hold:

1. The code is not derived from or related to information about the individual (no hashed SSNs, no hashed MRNs, no initials+DOB constructions — a hash of an identifier is "derived from" it);
2. The code is not otherwise capable of translation to identify the individual;
3. The CE does not disclose the mechanism (key, algorithm, or lookup table) to the data recipient.

Random surrogate keys held in a separately secured crosswalk satisfy this; deterministic hashes of identifiers do not.

LLM-era residual risk

De-identification reduces risk; it does not zero it, and modern ML raises the floor:

• Models infer redacted attributes. LLMs reconstruct location, age, and other attributes from writing style and context even after redaction (Staab et al., ICLR 2024, arXiv:2310.07298). Treat inference risk as part of any Expert Determination on narrative text.
• Embeddings are PHI. Vector embeddings of clinical text invert back to near-verbatim text (Morris et al., EMNLP 2023, arXiv:2310.06816; replication arXiv:2507.07700). Embedding PHI is not de-identifying it.
• Synthetic data can leak. Generative models regurgitate training records; synthetic release requires membership-inference and nearest-neighbor testing, not an assumption of safety.
• Free-text de-id is only as good as NER recall. Every missed entity is PHI in the output. Measure recall on an annotated holdout before certifying a pipeline; tool figures in references/methods-and-tooling.md.
• De-identifying with an LLM is itself a disclosure. Running PHI through a model to de-identify it requires a BAA-covered endpoint or a locally hosted model — never a consumer chatbot or non-BAA API.

Hard rules

• Redaction of names alone is not de-identification. All 18 identifiers + no actual knowledge, or documented Expert Determination — nothing else exits HIPAA (§164.514(b)).
• A limited data set is PHI. It needs a DUA before release and full safeguards after (§164.514(e)).
• Never build re-identification codes from the data itself — no hashed MRNs/SSNs (§164.514(c)).
• ZIP3 stays only above the 20,000-population line; otherwise 000. Ages over 89 collapse to "90 or older" (§164.514(b)(2)(i)(B)–(C)).
• Identifiers of relatives, employers, and household members must go too — not just the patient's.
• Embeddings, pseudonymized extracts, and "tokenized" datasets remain PHI until §164.514(b) is actually met.
• Never send PHI to a non-BAA service to de-identify it.
• Safe Harbor on free text requires a verified pipeline (measured recall + human sampling), not a regex pass.

Common violations to catch

• Production PHI copied into dev/test/staging labeled "scrubbed" with no method documented — still PHI, now outside production controls.
• Hashed identifiers presented as de-identified — violates §164.514(c) derivation rule and fails Safe Harbor item 18.
• Dates and ZIP5 retained "because analytics needs them" without an Expert Determination — fails Safe Harbor item 2/3 outright.
• Limited data set shared without a DUA, or used for marketing/product purposes outside §164.514(e)(3)'s three permitted purposes.
• Free-text notes run through an off-the-shelf NER with no recall measurement — residual names, dates, MRNs in narrative text.
• DICOM/image releases with device serials, burned-in annotations, or reconstructable face data (items 13, 17).
• "Anonymized" training corpora sent to a non-BAA AI vendor — an impermissible disclosure if §164.514(b) was not actually met.
• Expert Determination with no retained documentation — the determination legally is the documentation (§164.514(b)(1)(ii)).

Routing to specialist skills

• AI training pipelines, vendor BAAs for models, RAG/embedding architecture → hipaa-ai-compliance
• Dev/test data-environment policy and app architecture → hipaa-app-development
• Whether the data is PHI at all / does HIPAA apply → hipaa-fundamentals
• A de-identification failure that exposed PHI → hipaa-breach-response

References

• references/safe-harbor-identifiers.md — the 18 identifiers with precise definitions, edge cases (ZIP3, dates, ages), common misses, and free-text/imaging pitfalls. Load when executing or auditing a Safe Harbor pass.
• references/methods-and-tooling.md — Expert Determination process and thresholds, limited data set + DUA elements, synthetic data testing, and the Philter/Presidio/Comprehend Medical tool comparison with measured precision/recall. Load when choosing or validating a de-identification method or tool.

Regulatory currency

Content reflects the rules as of mid-2026. The §164.514 de-identification standard is unchanged since the 2013 Omnibus Rule, and OCR's 2012 de-identification guidance remains the operative interpretation. The January 2025 Security Rule NPRM (90 FR 898) is not final (Unified Agenda targets ~2027); treat its provisions as strong best practice, not binding law. ZIP3 population figures shift with each decennial Census — re-derive the restricted-ZIP3 list from current Census data rather than reusing cached lists. When an answer depends on NPRM status, current Census populations, or a vendor's BAA terms, verify via web search.