HIPAA · 45 CFR 164.514(b)(2) · SAFE HARBOR

HIPAA Safe Harbor for LLM Prompts: Removing the 18 Identifiers Before Egress

The HIPAA Safe Harbor method in 45 CFR 164.514(b)(2) treats health information as de-identified when 18 listed identifier categories are removed and the covered entity has no actual knowledge that the remainder could identify a person. This page explains how that applies when clinical text is prepared for a language model.

Summary

Safe Harbor is a rule-based method. It lists identifier categories of the individual and of relatives, employers, and household members that must be removed, including names, geographic subdivisions smaller than a state, date elements other than year, contact numbers, and record numbers.

Section 164.514(c) allows a covered entity to assign a code to permit re-identification, provided the code is not derived from or related to information about the individual and is not otherwise capable of being translated to identify the individual, and the covered entity does not use or disclose the code for any other purpose and does not disclose the mechanism for re-identification. Random per-session surrogates whose mapping is held only in local memory fit that constraint; surrogates derived from the original values would not.

Scope notice. This page maps a technical control to a published framework as a Statutory Risk Minimization and Defense-in-Depth measure. It is not legal advice, not a certification by the framework owner, and not a statement that any regulation is fully satisfied. Consult qualified counsel for jurisdiction-specific determinations.

Identifier Handling in Clinical Text

Identifier category	Typical form in prompts	Required handling
Names	Patient, relative, and clinician names in notes.	Replace with a surrogate such as [NAME_1].
Dates	Admission, discharge, and birth dates.	Remove all date elements except year. Ages over 89, and any year indicating such an age, must be removed or aggregated into a single category of 90 or older.
Contact and record numbers	Telephone, email, medical record and account numbers.	Replace with typed surrogates.
Geographic data	Street addresses, small-area locations.	Remove below the state level except as the rule permits.
Free-text context	Narrative details that could single out a person.	Specialized profiles reduce risk; residual review remains required.

How ZTDS Applies

To keep the re-identification code consistent with Section 164.514(c):

Generate surrogates as session counters, not as hashes or transforms of the original values.
Keep the mapping on the covered entity side in volatile memory and never transmit it.
Zeroize the mapping when the session ends unless the covered entity has a documented reason to retain it.
Retain a local receipt of entity categories and counts as evidence of the step.

What This Control Does Not Cover

Safe Harbor requires no actual knowledge that the remaining information could identify an individual. A tool cannot establish that on its own.
Clinical narratives can contain details that identify a person outside the 18 categories; expert determination is the alternative method for those cases.
This page is not a legal opinion and does not constitute a determination by HHS.
Business associate and contractual questions remain separate from the de-identification method.

Frequently Asked Questions

What does the HIPAA Safe Harbor method require?

Under 45 CFR 164.514(b)(2), the covered entity removes 18 listed categories of identifiers and has no actual knowledge that the remaining information could identify an individual. If both hold, the information is treated as de-identified.

Can reversible surrogates be used under Safe Harbor?

A code that permits re-identification is allowed under 164.514(c) if it is not derived from or related to information about the individual, is not otherwise capable of being translated to identify the individual, the code is not used or disclosed for other purposes, and the covered entity does not disclose the mechanism for re-identification. Random session surrogates whose mapping stays only on the covered entity side meet that design constraint.

Is Safe Harbor enough for free-text clinical notes?

Not always. Free text can carry identifying details beyond the listed categories. Where residual risk remains, the expert determination method or additional review is the appropriate route.

Global Regulatory Compliance Matrix — Cross-framework statutory mapping.
ZTDS RFC v1.0 Specification — The four invariants referenced on this page.
Perimeter Scanner — Browser-based egress audit with local receipts.
Framework Mappings Hub — All framework mappings in one index.
OWASP LLM02 Sensitive Information Disclosure — Maps pre-egress tokenization to OWASP LLM02:2025 and states what it does not cover.
NIST AI RMF Generative AI Profile — Places ZTDS across GOVERN, MAP, MEASURE, and MANAGE for generative AI data privacy risk.
EU AI Act Article 10 Data Governance — Describes how pre-ingestion sanitization supports Article 10 data governance practices.
GDPR Articles 25 and 32 for AI Prompts — Explains data protection by design and security of processing for prompts sent to AI providers.
MCP stdio PII Sanitization — Describes a local gateway that sanitizes JSON-RPC traffic over the MCP stdio transport.
RAG Pipeline PII Sanitization — Places sanitization at ingestion, retrieval, and prompt assembly stages of a RAG pipeline.
Client-Side Sanitization vs Proxy DLP — Compares client-side in-memory sanitization with network proxy and cloud DLP approaches.