Pre-Sharing PHI CSV Checklist: 12 Steps Before You Send Patient Data (2026)

One missed identifier can re-create PHI from a "de-identified" dataset.

One missed BAA can turn a routine data share into a reportable breach.

One undocumented de-identification run can make a future audit impossible to pass.

De-identification is not a single step. It is a sequence. Each step in the sequence can fail independently. The checklist below covers the complete sequence — from initial column mapping through final audit documentation — with a reference to the detailed guide for each step.

Use this before every external data share involving patient CSV files.

---

TL;DR

Safe Harbor de-identification requires addressing all 18 identifier types, applying specific rules for dates (year-only, 90+ aggregation) and ZIP codes (3-digit prefix with population verification), scanning free-text fields that structured de-id misses, checking quasi-identifier combinations, making a deliberate pseudonymization decision, validating the output, and documenting everything. Skipping or rushing any step produces a dataset that may appear de-identified but is not.

---

For the complete Safe Harbor workflow across all 18 identifiers, see our complete Safe Harbor de-identification guide.

⚖️ NOT LEGAL ADVICE — This post covers HIPAA Safe Harbor pre-sharing validation de-identification for informational purposes only. Whether your specific data and process satisfy Safe Harbor depends on your data, use case, and organizational context. Consult qualified legal and compliance counsel before making de-identification or sharing decisions for regulated data.

---

Table of Contents

• The 12-Step Pre-Sharing Checklist
• How to Use This Checklist
• Common Gaps That Create Post-De-Identification PHI
• Documentation Requirements
• FAQ
• Conclusion

---

The 12-Step Pre-Sharing Checklist

Step 1 — Map all columns against the 18 Safe Harbor identifiers

Before removing anything, build a complete column inventory. For every column in the dataset, determine whether it corresponds to one of the 18 Safe Harbor identifier types specified in 45 CFR §164.514(b)(2)(i)(A)-(R).

The 18 types include: names, geographic data, dates, telephone numbers, fax numbers, email addresses, SSNs, medical record numbers, health plan beneficiary numbers, account numbers, certificate/license numbers, VINs and serial numbers, device identifiers and serial numbers, web URLs, IP addresses, biometric identifiers (fingerprints, voiceprints), full-face photographs, and any other unique identifying number or characteristic.

Do not rely on column names alone. A column named ref_id may contain MRNs. A column named note_date contains dates. Audit the values, not just the headers.

Reference: HIPAA Safe Harbor De-Identification — Complete Guide

---

Step 2 — Remove all 18 identifier types from structured columns

Remove or transform every column identified in Step 1. For identifiers that must be removed entirely (names, SSNs, phone numbers, email addresses, URLs, IP addresses, device IDs, biometric identifiers, photos): delete the column or replace with a null value. For identifiers that may be transformed (dates, ZIP codes, patient IDs): apply the appropriate transformation rule in Steps 3, 4, and 9.

Do not leave any 18-identifier column untouched. A dataset with 17 of 18 identifier types removed is not Safe Harbor compliant.

Reference: HIPAA Safe Harbor De-Identification — Complete Guide

---

Step 3 — Apply date rules: truncate to year-only per §164.514(b)(2)(i)(C)

For every date column directly related to an individual (birth date, admission date, discharge date, date of death, procedure dates, visit dates, prescription dates): remove all elements more specific than year. Month and day are removed; year is retained.

Audit every column containing "date," "dt," "time," or "year" in its name. Check derived columns (age-at-admission, days-since-last-visit) for implicit date exposure.

Reference: HIPAA Safe Harbor Date De-Identification

---

Step 4 — Apply the 90+ rule: aggregate ages over 89 and implicated birth years

For any patient whose age exceeds 89: remove the birth year (it reveals age over 89 when combined with the current year) and replace the age value with the single category "90 or older." Any date element that would allow a reader to infer age over 89 must also be aggregated.

This step is separate from Step 3 because it applies to the birth year (which Step 3 would otherwise retain) and to any other date that implicitly reveals extreme age.

Reference: HIPAA Safe Harbor Date De-Identification — 90+ Rule

---

Step 5 — Apply ZIP code rules: 3-digit prefix with population check per §164.514(b)(2)(i)(B)

Truncate all 5-digit ZIP codes to their first three digits. For each 3-digit prefix, verify the combined population of all ZIP codes sharing that prefix against the HHS-published restricted-prefix list (based on current Census Bureau data). Replace restricted prefixes (combined population ≤ 20,000) with 000.

Retrieve the restricted-prefix list from current HHS official guidance — do not rely on memorized or third-party lists. Document the source and its Census-year basis.

Reference: HIPAA Safe Harbor ZIP Code De-Identification

---

Step 6 — Remove all other geographic data smaller than state

Step 5 covers ZIP codes. Step 6 covers everything else: street addresses, city names, county names, neighborhood names, census tract identifiers, latitude and longitude coordinates, and any equivalent geocode. All are part of the geographic identifier at §164.514(b)(2)(i)(B) and must be removed entirely.

State-level data may be retained.

Reference: HIPAA Safe Harbor ZIP Code De-Identification

---

Step 7 — Scan all free-text and notes columns for residual identifiers

Structured de-identification does not read the content of free-text fields. Clinical notes, visit summaries, reason-for-visit fields, comments, and narratives routinely contain provider names, institution names, geographic references, and dates in prose form — none of which are touched by column-level de-id.

Audit every column that may contain narrative text. Run an automated scan for detectable PHI patterns (names, dates, addresses, SSNs in prose). For each flagged row, review the content and redact identified terms.

Document the scanning method and the residual risk assessment.

Reference: De-Identify Free-Text PHI in Patient CSV Notes Fields

---

Step 8 — Check for quasi-identifier re-identification risk

Individual values that are not 18-identifier PHI elements can combine to re-identify individuals. Age + 3-digit ZIP + sex + diagnosis is a classic re-identification vector. Small populations and rare conditions amplify this risk.

After completing Steps 1-7, assess the remaining quasi-identifier exposure in the dataset. Consider: How many rows share a given age/ZIP/sex/diagnosis combination? Are any conditions rare enough that a small group is effectively identifiable?

For high-risk datasets (small populations, rare diseases, elderly patients), this assessment may warrant consultation with a qualified privacy officer or statistician.

Reference: Validate PHI Removal in Patient CSV Files

---

Step 9 — Make the pseudonymization decision explicitly

Patient IDs (MRNs, account numbers, encounter IDs) are Safe Harbor identifier elements that must be addressed. The decision is: remove entirely, or replace with a code?

If replacing with a code:

• Internal longitudinal linkage: retain the mapping; the dataset remains PHI for your organization
• External Safe Harbor release: use a randomly generated code not derived from the individual's information; do not disclose the mapping to the recipient

Make this decision deliberately and document it. Do not let MRNs remain in the dataset by default.

Reference: Pseudonymize Patient IDs and MRNs in CSV Files

---

Step 10 — If releasing externally: verify replacement codes meet §164.514(c)(1)–(c)(2)

For external releases under Safe Harbor where patient IDs have been replaced with codes, confirm all three conditions of §164.514(c) (the coded-record exception):

1. §164.514(c)(1) — Derivation test: the replacement code is not derived from or related to information about the individual (hashes of PHI fail this condition)
2. §164.514(c)(2) — Security conditions: the covered entity will not use or disclose the code for any other purpose
3. §164.514(c)(2) — Non-disclosure: the mechanism for re-identification will not be disclosed to the recipient of the de-identified dataset

If any condition is not met, the coded-record exception does not apply. The patient ID must be removed rather than replaced.

Reference: Pseudonymize Patient IDs and MRNs in CSV Files

---

Step 11 — Run a validation pass on the output file

Before delivering the dataset, run a validation pass on the output:

• Confirm no full dates remain (month or day present in any date column)
• Confirm no ages over 89 appear as numeric values
• Confirm no 5-digit ZIP codes remain
• Confirm restricted ZIP prefixes are replaced with 000
• Confirm no name values remain in structured columns
• Spot-check free-text columns for visible identifiers
• Confirm no latitude or longitude values remain
• Confirm row count and column count match expected output

Flag and resolve any anomalies before the dataset leaves your control.

Reference: Validate PHI Removal in Patient CSV Files

---

Step 12 — Create and retain the audit documentation

Document the de-identification run. At minimum, record:

• Date of de-identification
• Method used: Safe Harbor (list which identifiers were removed and how) or Expert Determination (attach the statistician's report)
• Reviewer: who performed or supervised the de-identification
• Free-text scan: method used, who reviewed results, residual risk assessment
• ZIP prefix list source: the HHS document used, its Census-year basis, and the date retrieved
• Pseudonymization decision: whether patient IDs were replaced or removed; mapping storage location if applicable
• Data recipient: name/organization receiving the dataset
• Intended use: the stated purpose for which the data is being shared

Retain this documentation. Regulators do not audit de-identification quality at point of release — they audit it after an incident. The documentation is your evidence that the process was followed correctly.

---

How to Use This Checklist

Work through Steps 1-12 sequentially. Each step has a dependency on the ones before it — the quasi-identifier check (Step 8) is meaningless before the 18-identifier removal is complete (Steps 1-6).

Not every data release requires the same depth at every step. An internal research share under a full BAA does not require the same rigor on Steps 9 and 10 as a public repository upload. Scale the effort to the release context — but document the reasoning when you reduce scope.

For high-stakes releases (external publication, public repositories, data involving vulnerable populations), treat this checklist as a minimum. Engage a qualified privacy officer and consider Expert Determination if the dataset involves small populations or rare conditions.

---

Common Gaps That Create Post-De-Identification PHI

Gap 1: Free-text columns skipped. The most common failure mode. Steps 1-6 complete cleanly; no one looks at clinical_notes. Provider names and institution references pass through intact.

Gap 2: 90+ rule not applied. Birth years for elderly patients are retained because the team focused only on month/day removal. Birth year 1931 in a 2024 dataset reveals age 93.

Gap 3: ZIP codes truncated but not population-checked. 3-digit ZIP prefixes appear in the output, but the restricted-prefix list was not applied. Rural prefixes covering fewer than 20,000 people remain in the dataset.

Gap 4: City name retained after ZIP removal. The team removed the ZIP code but kept the city name, believing the city was safe because the ZIP was gone. City names are the same identifier category as ZIP codes.

Gap 5: MRN hash treated as de-identified. SHA-256(MRN) values remain in the output. The team believes this is de-identified because the original MRN is not present. The hash is derived from the MRN, which is PHI; the §164.514(c)(1) derivation test is not met, so the coded-record exception does not apply.

Gap 6: No audit documentation. The de-identification ran successfully. Nothing was recorded. When a question arises six months later about which identifiers were addressed and how, there is no record to produce.

---

Documentation Requirements

HIPAA does not specify a documentation format for de-identification. But enforcement and audit experience has produced a practical standard: if you cannot demonstrate that a compliant process was followed, you cannot defend the outcome.

Minimum documentation:

• Date, method, and reviewer
• Column inventory (which columns mapped to which identifier types)
• Transformation log (what was done to each identifier-type column)
• Free-text scan record
• ZIP prefix list source and retrieval date
• Pseudonymization decision and mapping disposition
• Recipient and stated purpose

Store this documentation for as long as you retain the de-identified dataset or the underlying PHI, whichever is longer. Associate it with the specific dataset version and release date.

---

FAQ

Conclusion

De-identification is not done when the structured removal pass finishes. It is done when all 12 steps are complete, the output has been validated, and the audit documentation is filed.

Every gap in this list has a corresponding real-world incident. Free-text columns passed through intact. Birth years for 90-year-old patients retained. City names surviving ZIP removal. MRN hashes treated as de-identified. No documentation surviving past the analyst's departure.

The checklist is not bureaucratic friction. It is the sequence that converts a data share from a compliance risk into a defensible, documented, repeatable process.

Use it before every external patient data release. Adjust scope based on the release context. Document what you did and why.

---

Cluster Reference: