HIPAA Safe Harbor De-identification: Complete Guide to 18 PHI Identifiers

What is HIPAA Safe Harbor De-identification?

Under 45 CFR § 164.514(b), covered entities and their business associates may de-identify protected health information using one of two methods:

1. Safe Harbor Method (§ 164.514(b)(2)): Remove all 18 specified identifiers and verify that the covered entity has no actual knowledge that the remaining information could be used to identify an individual.
2. Expert Determination Method (§ 164.514(b)(1)): A qualified statistical expert certifies that the risk of identification is "very small."

Safe Harbor is the more commonly used method because it provides a clear, bright-line rule. If all 18 identifiers are removed and there is no actual knowledge that the rest can identify someone, the data is de-identified by definition — no statistical expertise required. This guide focuses on Safe Harbor.

Key benefit: De-identified health information is not PHI. It falls outside the scope of HIPAA's Privacy Rule entirely. You can share it freely for research, publish it, use it to train AI models, and process it with third-party tools — no BAA required.

The 18 PHI Identifiers Under 45 CFR § 164.514(b)(2)

Every one of the following identifiers must be removed or transformed to achieve Safe Harbor de-identification:

Safe Harbor vs Expert Determination: When to Use Which

The "No Actual Knowledge" Requirement

Even after removing all 18 identifiers, § 164.514(b)(2)(ii) requires that the covered entity "does not have actual knowledge that the information could be used alone or in combination with other information to identify an individual."

This means that small-cell data poses a risk. Suppose your de-identified dataset contains only one patient with a particular rare condition, in a particular age range, in a particular geographic area. The combination of remaining data points may still be identifying — even with all 18 identifiers removed.

Practical guidance:

• Apply cell suppression for demographic combinations with fewer than 5 individuals
• Generalize age to 5-year bands rather than exact year when the dataset is small
• Document your analysis showing no actual knowledge of residual identification risk
• For sensitive research, consider Expert Determination despite the higher cost

Geographic Data: The ZIP Code Rule

The geographic data rule under § 164.514(b)(2)(i)(B) is nuanced and frequently misunderstood. The regulation requires removal of all geographic subdivisions smaller than a state — except that the first three digits of a ZIP code may be retained if the geographic unit formed by all ZIP codes with the same three initial digits contains more than 20,000 people.

In practice:

• All ZIP codes whose first three digits represent fewer than 20,000 people must be replaced with "000"
• The Census Bureau publishes population data by 3-digit ZIP prefix — this list must be maintained and updated
• Street address, city, county, precinct, and other geographic units smaller than state must always be removed
• State-level data may be retained

The anonym.legal HIPAA preset does not apply this rule. It covers a fixed list of entity types; the ZIP-3 population rule and the age-90+ rule must be implemented on your side.

Date Restrictions: What You Can and Cannot Keep

Dates are among the most commonly mishandled PHI identifiers. The rule:

• Must remove: All elements of dates (except year) directly related to the individual — including birth date, admission date, discharge date, date of death, and exact ages over 89
• May keep: Year only (e.g., "2024" instead of "March 15, 2024")
• Special rule for age 90+: All ages 90 and above must be aggregated into a single category ("90 or older") — even the year of birth must be removed for these individuals
• Date shifting: Not permitted under Safe Harbor (it preserves temporal relationships). Consider Expert Determination if date intervals are required.

Automated Safe Harbor Implementation

The anonym.legal API detects selected HIPAA-related entities but does not currently implement a complete automated Safe Harbor transformation. The example below detects the entity types of the HIPAA preset and replaces them; everything else on the list of 18 stays your responsibility:

import requests

API_KEY = "your-api-key"
BASE = "https://anonym.legal"
HEADERS = {"Authorization": f"Bearer {API_KEY}"}

# Entity types of the HIPAA preset. They cover part of the 18 identifiers, not all.
HIPAA_ENTITIES = ["PERSON", "PHONE_NUMBER", "EMAIL_ADDRESS", "DATE_TIME", "LOCATION",
                  "US_SSN", "MEDICAL_LICENSE", "URL", "US_PASSPORT"]

def deidentify(text: str) -> dict:
    """Detect and replace HIPAA-related entities. The ZIP-3, age-90+ and
    year-only rules of 45 CFR § 164.514(b)(2) are NOT applied here."""
    analysis = requests.post(
        f"{BASE}/api/presidio/analyze",
        headers=HEADERS,
        json={"text": text, "language": "en", "entities": HIPAA_ENTITIES},
    ).json()
    result = requests.post(
        f"{BASE}/api/presidio/anonymize",
        headers=HEADERS,
        json={"text": text, "analyzer_results": analysis["results"]},
    ).json()
    return result

# Example input:
sample = """
Patient: John Michael Davis
DOB: 03/15/1941 (age 84)
SSN: 234-56-7890
MRN: MRN-78234
Address: 42 Maple Street, Boston, MA 02115
Admission: 02/14/2026
Discharge: 02/18/2026
Diagnosis: Type 2 diabetes with peripheral neuropathy
"""

result = deidentify(sample)
print(result["text"])
# Illustrative output; the exact spans depend on detection:
# Patient: <PERSON>
# DOB: <DATE_TIME> (age 84)
# SSN: <US_SSN>
# MRN: MRN-78234   (not in the preset: add a custom pattern)
# Address: <LOCATION>, MA 02115   (ZIP not generalized: apply the ZIP-3 rule yourself)
# Admission: <DATE_TIME>
# Discharge: <DATE_TIME>
# Diagnosis: Type 2 diabetes with peripheral neuropathy

Note that the diagnosis — which is clinical information not itself an identifier — is preserved. Only the detected entities are replaced. This is the key advantage of Safe Harbor over over-aggressive redaction: clinical utility is maintained.

Documentation Requirements

To demonstrate Safe Harbor compliance in an audit, maintain the following documentation:

1. De-identification policy: Written policy specifying which method (Safe Harbor) is used, which entity types are removed, and who is responsible
2. Technical specification: Documentation of the tools used (e.g., "anonym.legal API, HIPAA preset, plus our own ZIP-3 and date rules, version X.Y"), including version history
3. Processing log: Record of each de-identification run — timestamp, document count, identifiers removed — for audit trail purposes
4. No actual knowledge attestation: For each dataset released, a brief documented analysis confirming no residual identification risk is known
5. Recipient agreements: While de-identified data is not PHI, document who receives it and for what purpose — good practice that supports your overall compliance posture

Limitations & Honest Caveats

Safe Harbor is mechanical but not a guarantee. Removing the 18 identifiers reduces risk; it does not eliminate it, because combinations of remaining quasi-identifiers — a rare diagnosis, ZIP3 plus age plus visit date — can still enable re-identification against external datasets. Its limitations show most when stripping the 18 identifiers destroys the analytic value you actually need: for rich research datasets, Expert Determination is often the better choice, even though it costs more and takes longer. De-identified data is no longer PHI, but de-identification is not for use as a substitute for a Business Associate Agreement while you are still handling PHI upstream.