Quick Answer
How do you validate that PHI has been fully removed from a patient CSV?
Two checks are required — and most de-id processes only run one. The first is scanning free-text and notes columns for residual direct PHI that survived the structured de-id pass. The second is assessing whether the remaining field combinations create quasi-identifier re-identification risk. A dataset can pass the first check and still be re-identifiable from the second.
Run both checks with SplitForge Data Validator before sharing. For the complete Safe Harbor identifier list to de-identify before validation, see HIPAA Safe Harbor: De-Identify Patient CSV (All 18 Identifiers).
⚖️ NOT LEGAL ADVICE — This post covers HIPAA Safe Harbor de-identification validation for informational purposes only. Whether a dataset satisfies Safe Harbor depends on your specific data, processing approach, and organizational context. Consult qualified legal and compliance counsel before making sharing decisions based on de-identification status.
TL;DR: Removing named columns is not sufficient validation. Two checks most de-id processes miss: (1) PHI embedded inside free-text and clinical notes fields — provider names, dates, contact details, and MRNs survive structured column removal because they are written in text, not stored in typed columns; (2) quasi-identifier re-identification risk from fields that Safe Harbor does not require removing — combinations like age + 3-digit ZIP + sex + diagnosis code can narrow the dataset to identifiable individuals. Both checks must pass before any sharing decision.
For the complete Safe Harbor workflow across all 18 identifiers, see our complete Safe Harbor de-identification guide.
De-identification validation is where good-enough becomes inadequate.
The de-id script ran. Names column removed. SSN column dropped. Date columns stripped to year only. The file looks clean — 1,200 records, headers are sensible, no patient names visible. The research partner is waiting.
Before sharing, open the clinical_notes column.
❌ BROKEN — structured columns passed de-id. Free-text PHI and quasi-identifiers not checked.
mrn_token,admission_year,age,sex,icd10,zip3,clinical_notes
RES-001,2022,34,F,E11.9,941,"Pt reports pain onset 3/14. Referred by Dr. Sarah Patel, St. Mary's Clinic."
RES-002,2022,87,M,I50.9,606,"Home health: ValleyCare aide assigned. Patient DOB 01/04/1935 on file."
RES-003,2022,67,F,C34.10,947,"Portal export: [email protected] — follow-up call scheduled 03/22."
VALIDATED (both checks passed — Safe Harbor):
mrn_token,admission_year,age,sex,icd10,zip3,clinical_notes
RES-001,2022,34,F,E11.9,941,"Pt reports pain onset [DATE REDACTED]. Referred by [PROVIDER REDACTED]."
RES-002,2022,87,M,I50.9,606,"Home health: [AGENCY REDACTED] aide assigned. [DOB REDACTED]."
RES-003,2022,67,F,C34.10,947,"[NOTES REDACTED — contained email address and date]"
Three records. Three validation failures — none of them caught by the structured column removal pass.
RES-001 contains a physician name and a named clinic in the free-text field. RES-002 contains a date of birth embedded in the clinical note — the DOB is direct PHI under Safe Harbor and must be redacted regardless of where it appears in the file. RES-003 contains an email address extracted from the patient portal.
The de-id script removed the columns it was configured to remove. It had no visibility into what the text fields contained.
De-identification validation requirements verified against HHS Safe Harbor guidance and 45 CFR §164.514(b)(2), May 2026.
Why Removing Named Columns Is Not Enough
Standard de-id workflows operate on structure: identify PHI columns, remove or redact them, output the file. This works correctly for the columns the configuration is aware of. It does not address two risks that live outside structured column detection.
Risk 1: Residual direct PHI in free-text fields. Clinical notes, visit summaries, discharge instructions, and comments fields are written in natural language. They routinely contain provider names, dates, contact details, and addresses that are not stored in their own typed columns. A workflow that removes the patient_name column cannot see the name written inside the clinical_notes field.
Risk 2: Quasi-identifier re-identification from retained fields. Quasi-identifiers are attributes that are not, by themselves, PHI under Safe Harbor — they do not appear on the 18-category list — but that in combination with other retained fields narrow the population to a group small enough for individual re-identification. The 18 identifier categories address direct identifiers. They do not eliminate the re-identification risk that can arise from combinations of fields that remain after removal.
Both risks require active checking. Neither is addressed by confirming the 18 structured column categories were removed.
Check 1: Residual Direct PHI in Free-Text Fields
Free-text fields are the most common source of residual PHI after a structured de-id pass. The categories most often embedded in clinical language:
Provider and facility names — referral notes contain referring physician names and practice names. Care coordination fields contain home health agency names. These are not stored in a typed column in most export formats; they appear in narrative text and are invisible to column-level de-id.
Dates embedded in text — clinical events are referenced by date in free-text: "follow-up scheduled 04/15," "onset approximately two weeks before 03/22," "DOB on file: January 1935." These survive structured date-column removal because they are not stored in a date-typed column — they are strings inside a text field.
Contact information — email addresses and phone numbers pulled from patient portal registrations can appear inside exported notes fields. They are not stored in their own column in the export, so column removal does not reach them.
Embedded MRNs and identifiers — system-generated notes sometimes include MRN references in the free text for care continuity: "see record MRN-00142 for lab results." The structured mrn column may have been removed; the text reference survives.
What the check requires: Pattern matching against PHI formats (email regex, phone number formats, date patterns, MRN formats) applied to the full content of every free-text cell — not just the column header. For clinical notes, effective scanning should also include detection of named entity patterns for provider and facility names.
Column-level de-id cannot substitute for content-level scanning of text fields. These are different operations.
For detailed guidance on identifying and de-identifying free-text PHI specifically, see De-Identifying Free-Text PHI in Patient CSV Notes.
Check 2: Quasi-Identifier Re-Identification Risk
Quasi-identifiers are fields that look innocuous individually but become identifying in combination. Age, sex, 3-digit ZIP code, and diagnosis code are all commonly retained after Safe Harbor removal — and individually, they are not among the 18 categories Safe Harbor requires removing.
The risk is specificity. Research in population re-identification has documented that field combinations can reduce a dataset to groups where individuals are identifiable. For healthcare data, a rare diagnosis code combined with a specific age, sex, and geographic area can narrow to a very small patient population — in some cases, to one.
Field combinations that warrant assessment:
| Retained fields | Re-identification concern |
|---|---|
| Exact age + 3-digit ZIP + sex | Population specificity across many demographic cohorts |
| Exact age + full ICD-10 (7 characters) + sex | Rare diagnoses reduce the denominator sharply |
| Year of birth + specific diagnosis + geography | Longitudinal specificity for chronic conditions |
| 3-digit ZIP + rare diagnosis + admission year | Geographic + clinical specificity in small regions |
Safe Harbor's ZIP code rule — retain only the first 3 digits; zero the prefix for populations ≤20,000 — addresses geographic specificity for one field. It does not address what happens when ZIP, age, sex, and diagnosis are retained simultaneously in the same output.
What the check requires: Assess whether each combination of quasi-identifier values is shared by a sufficient number of records in the dataset (k-anonymity, commonly k=5 or k=10 for healthcare data). Records where the combination is rare or unique represent re-identification risk.
When quasi-identifier analysis identifies high-risk records, the response is further generalization — not deletion:
- Replace exact age with a 5-year age band
- Replace full ICD-10 codes with 3-character parent codes
- Suppress records where combinations are unique in the dataset
These generalizations reduce re-identification risk while preserving most analytic utility. The tradeoff is a research design decision, made with awareness of the population and use context.
The Dual-Check Validation Workflow
Step 1 — Load the post-de-id output file
Open SplitForge Data Validator and load the patient CSV that has already had structured column de-id applied. This is the file you intend to share. Validation runs entirely in your browser — no file is uploaded to a server.
Step 2 — Run the direct PHI pattern scan
The validator scans all text fields for PHI format patterns: email addresses, phone numbers, date strings (including written formats), MRN patterns, and numeric sequences matching SSN formats. Free-text columns are scanned at the content level. Review all flagged cells and apply redaction to confirmed PHI residuals before proceeding.
Step 3 — Confirm age-aggregation compliance
Check that all ages ≥ 90 and all dates implying age ≥ 90 have been collapsed to "90+" as required under Safe Harbor. This is frequently missed in de-id passes that strip date columns but leave derived age columns unchanged with their original numeric values.
Step 4 — Run the quasi-identifier assessment
Select the retained fields — age, sex, ZIP prefix, diagnosis codes, or other demographic attributes — and run the quasi-identifier combination analysis. The tool identifies field combinations where population specificity is high and flags record groups where k-anonymity falls below threshold.
Step 5 — Apply generalizations for flagged combinations
For high-risk record groups identified in Step 4, apply the appropriate generalization to the relevant fields and re-run the assessment. Document each generalization applied and the rationale.
Step 6 — Record the validation run
Document the validation date, checks run, any flags identified, and remediation actions taken. Safe Harbor requires both that the 18 identifiers are removed and that the covered entity has no actual knowledge the remaining data could identify an individual. The validation record provides the documented evidence base for the second condition.
For a complete pre-share checklist, see Pre-Sharing PHI CSV Checklist. For the full cross-framework privacy guide, see our privacy-first data processing guide.
FAQ
Validate Before You Share
Run both checks — direct PHI pattern scan and quasi-identifier assessment — on your de-identified patient CSV before it leaves your control. Processing stays in your browser.
Validate Patient CSV with Data Validator
Legal disclaimer: The content in this post is for informational purposes only and does not constitute legal advice. HIPAA Safe Harbor de-identification and data-sharing requirements depend on your specific data, processing approach, and organizational context. Consult qualified legal and compliance counsel before making decisions about sharing de-identified patient data.