Healthcare CSV and PHI Data Prep: Complete De-Identification Guide (2026)

Patient CSV files show up in places most people don't expect.

A lab system exports 40,000 result rows for a research study. An EHR migration team stages 4 million patient records for go-live validation. A practice administrator imports a patient panel from a legacy PM system. A research coordinator extracts a cohort for an outcomes study.

In each case, the CSV contains protected health information. In each case, the person handling it may not be a HIPAA compliance specialist. And in each case, the wrong handling decision — uploading to a cloud validator, loading real PHI into a test environment, sharing without de-identification — creates a risk that the right workflow would have prevented entirely.

This guide covers the complete workflow: what makes patient CSV data PHI, the two methods for legally de-identifying it, the specific rules for dates and ZIP codes, handling the PHI that survives structured de-identification, and why the processing environment matters as much as the process itself.

⚖️ Not legal advice. This guide describes technical approaches to HIPAA Safe Harbor de-identification. Whether your specific data, process, and release meet HIPAA requirements is a determination for your organization's privacy officer or legal counsel. HIPAA regulations are authoritative — verify current rule text at HHS.gov.

---

TL;DR

PHI in a CSV is defined by the 18 Safe Harbor identifier types specified in 45 CFR §164.514(b). De-identifying patient CSV data requires either removing all 18 identifier types (Safe Harbor method) or obtaining a statistician's certification of minimal re-identification risk (Expert Determination). Dates and ZIP codes have specific transformation rules; free-text fields require separate scanning because structured de-identification doesn't read column values. Processing locally — never uploading the identified file — means the de-identification step itself creates no disclosure to a business associate and no BAA requirement for that step. De-identified data is not the same as anonymous data, and "actual knowledge" of re-identification re-activates HIPAA obligations even after de-identification.

---

Table of Contents

• What Counts as PHI in a Patient CSV
• The Two De-Identification Methods: Safe Harbor vs Expert Determination
• Why Uploading Patient Data to a Cloud Tool Triggers a BAA
• The De-Identification Workflow, Step by Step
• Validating De-Identification Before You Share
• De-Identifying for Research and Secondary Use
• Where CSV Actually Shows Up in Healthcare
• Why Local Processing Is the Privacy Floor
• De-Identification Method Decision Tree
• Additional Resources
• FAQ

---

What Counts as PHI in a Patient CSV

HIPAA's definition of PHI includes any information that identifies — or can reasonably be used to identify — an individual and relates to their health condition, healthcare provision, or payment for care. In a CSV, this means the column headers are not what matters. What matters is whether the values in the file could identify a patient.

Safe Harbor's 18-identifier framework is the practical standard. If a dataset has had all 18 identifier types removed (and the covered entity has no actual knowledge that the remaining data could re-identify individuals), the dataset is considered de-identified under HIPAA.

Two important caveats apply before the workflow even starts:

De-identified is not the same as anonymous. A de-identified dataset can be re-identified under some conditions. Safe Harbor satisfies a regulatory standard; it does not guarantee that re-identification is impossible in all future contexts.

The "actual knowledge" caveat. If a covered entity knows that a supposedly de-identified dataset can be used to identify individuals — even without the 18 identifiers — HIPAA protections re-apply to that dataset. De-identification is not a one-time action that permanently removes HIPAA obligations regardless of what you know.

The 18 Safe Harbor Identifier Types

This table matches the identifier list in HIPAA Safe Harbor De-Identification. For the full workflow covering each identifier type, see that guide.

Most patient CSVs contain identifiers from rows 1, 2, 3, 4, 6, 7, and 8 as a baseline. Research exports frequently add 9, 10, and 11. Lab exports add 13 (device/instrument identifiers). The full 18-type audit is necessary before any external share.

Quasi-identifiers are not on this list — but they matter. Combinations of non-identifier values (age + diagnosis + ZIP prefix) can re-identify individuals even after all 18 types are removed. A 2000 study by Latanya Sweeney demonstrated that 87% of Americans could be uniquely identified by ZIP code, birth date, and sex alone — none of which are named individually in the 18 Safe Harbor types. The quasi-identifier check is a separate step after Safe Harbor removal. See Validate PHI Removal in Patient CSV Files.

For a broader overview of HIPAA's data handling requirements in CSV workflows — including common compliance gaps and audit considerations — see Healthcare CSV Compliance: HIPAA and PHI Overview.

---

The Two De-Identification Methods: Safe Harbor vs Expert Determination

HIPAA recognizes two methods for de-identifying protected health information. Both satisfy the regulatory standard for de-identification; they differ in approach, expertise required, and what they permit in the output.

Safe Harbor (§164.514(b)(2)): Remove all 18 identifier types from the dataset. Apply specific transformation rules for dates and geographic data rather than removing them entirely (year-only for dates; 3-digit ZIP prefix with a population check). After removal and transformation, the covered entity must have no actual knowledge that the remaining data could identify individuals.

Safe Harbor is operationally straightforward and auditable. It does not require a statistician. It does require that all 18 identifier types are genuinely addressed — missing one type produces a non-compliant output.

Expert Determination (§164.514(b)(1)): A qualified statistician applies generally accepted principles to certify that the risk of identifying individuals from the dataset is very small. The statistician documents the methods and results supporting their determination.

Expert Determination can preserve more data utility than Safe Harbor — a statistician may certify that specific values can remain in the dataset while still meeting the "very small risk" standard. However, it requires engaging a qualified expert. No tool, including SplitForge, performs Expert Determination.

The practical split: Use Safe Harbor for most operational de-identification needs (research sharing, public data release, non-prod environments). Engage Expert Determination when Safe Harbor would destroy too much data utility for a specific research application, or when your IRB or data use agreement requires statistical certification.

For the detailed comparison of when each method applies, see Safe Harbor vs Expert Determination.

---

Why Uploading Patient Data to a Cloud Tool Triggers a BAA

The cloud de-identification paradox: to de-identify patient data using a cloud-based tool, you must first upload the still-identified patient data to that tool's servers. That upload is a disclosure of PHI to a third party.

Under 45 CFR §164.502(e) and §164.504(e), when a covered entity discloses PHI to a third party performing services on its behalf — including data processing — that third party is a business associate. A Business Associate Agreement is required before that disclosure occurs.

This is not a technicality. It is the structure of the regulation. Cloud de-identification vendors are legitimate services — many operate under BAAs, have SOC 2 certifications, and handle healthcare data professionally. The obligation is the covered entity's to execute the BAA before the upload, not an indictment of the vendor.

The local processing alternative addresses a different point in the workflow: if de-identification happens entirely within the user's browser, the identified file is never transmitted to a server. The de-identification step itself creates no disclosure to a business associate and no BAA requirement for that processing step.

This is verifiable: open DevTools → Network tab in any browser, drag a file into SplitForge's Data Masking tool, and run de-identification. No upload request appears in the Network log. The file does not leave the device.

The BAA question does not disappear entirely — it shifts to the data recipient after de-identification. If the de-identified output is shared with a covered entity's downstream partner, the data's de-identification status determines whether HIPAA applies to the recipient's handling of it.

For the detailed analysis of the cloud-vs-browser BAA exposure, including the specific disclosure scenarios and architecture comparison, see Cloud vs Browser PHI De-Identification.

---

The De-Identification Workflow, Step by Step

A complete Safe Harbor de-identification workflow for a patient CSV file involves eight distinct steps. This section provides the decision points and links to the spoke that owns each step's precise requirements.

Step 1 — Map all columns to the 18 identifier types. Before removing anything, audit every column in the dataset against the 18-identifier list. Column names are not reliable — ref_id may contain MRNs; note_date contains dates. Audit the values, not just the headers. → Full workflow

Step 2 — Remove or transform each identifier type. Identifiers that must be removed entirely: names, SSNs, phone numbers, email addresses, URLs, IP addresses, device IDs, biometric identifiers, photographs. Identifiers that are transformed rather than removed: dates (year-only with 90+ rule) and geographic data (3-digit ZIP prefix with population check). → Full workflow

Step 3 — Apply date transformation rules. All date elements more specific than year must be removed from dates directly related to the individual. Birth year must also be removed for individuals over 89 — combined with the current year, birth year reveals age over 89. Ages over 89 aggregate to "90 or older." Date-shifting is an alternative for longitudinal research. → HIPAA Safe Harbor Date De-Identification

Step 4 — Apply ZIP code rules. Full 5-digit ZIP codes are removed; only the first 3 digits may be retained, and only if the total population of all ZIP codes sharing that 3-digit prefix exceeds the threshold established in HHS guidance. Prefixes below the threshold become 000. City names, county names, and coordinates are removed entirely — the 3-digit ZIP prefix exception does not extend to them. → HIPAA Safe Harbor ZIP Code De-Identification

Step 5 — Scan all free-text and notes columns. Structured de-identification operates on column definitions — it does not read the content of free-text fields. Clinical notes, visit summaries, result comments, and reason-for-visit fields routinely contain provider names, institution names, geographic references, and dates in prose form. Automated scanning flags detectable patterns; manual review remains the standard for high-stakes external releases. → De-Identify Free-Text PHI in Patient CSV Notes

Step 6 — Make the pseudonymization decision. Patient IDs (MRNs, account numbers) are Safe Harbor identifier elements that must be addressed. The choice between removing them entirely or replacing them with non-derived codes determines whether records can be linked across datasets. Pseudonymized data remains PHI for any party holding the mapping key. → Pseudonymize Patient IDs and MRNs

Step 7 — Check for quasi-identifier re-identification risk. After all 18 identifier types are addressed, combinations of remaining values (age + diagnosis + 3-digit ZIP + sex) may still permit re-identification, particularly for small populations and rare conditions. This check is separate from Safe Harbor compliance and requires population-level thinking. → Validate PHI Removal in Patient CSV Files

Step 8 — Validate output and document the process. Validate that no identifier types remain in the output. Document the de-identification method, the reviewer, the transformation rules applied, the date, and the data recipient. Retain this documentation. → Pre-Sharing PHI CSV Checklist

---

Validating De-Identification Before You Share

De-identification is not done when the structured removal pass finishes. A file that has had all 18 identifier types addressed in structured columns may still contain PHI in free-text fields, quasi-identifier combinations that reconstruct identity, or identifier-type values that a column audit missed.

Validation before sharing serves a different function than the de-identification steps themselves: it is a final check that the output file — not the process — contains no residual PHI risk above what Safe Harbor permits.

A validation pass should confirm:

• No full dates remain in any column (month or day present)
• No ages over 89 appear as numeric values
• No 5-digit ZIP codes remain
• No name values remain in structured columns
• Free-text columns have been scanned and reviewed
• No latitude or longitude values remain
• Row count and column count match expected output

The most common validation failures by category:

Date survivors: A date field transformed correctly in 99% of rows but left 2024-03-15 intact in 12 rows where the value was stored as a string with a non-standard separator (e.g., 2024.03.15) that the transformation regex didn't match. Spot-checking is not sufficient — the full column must be validated.

Free-text pass-through: A comments column that contains "see Dr. Martinez at UCSF Nephrology" in 40 rows. Structured de-identification removed the values from every named PHI column correctly. The comments column was not in scope for the column-level pass. This is the most common post-de-id PHI discovery scenario.

ZIP survivors: A dataset where most ZIP codes were in a zip_code column (caught and truncated) but 600 rows also had ZIP codes embedded in a mailing_address free-text field that was processed as a notes column rather than a structured geographic field.

90+ rule misses: Birth year retained for a patient whose age value was stored as 91.0 (a float) rather than 91 (an integer), where the transformation rule matched only integer format.

Validation catches these before they become incidents. After a dataset has left your control, the options are narrower.

For a systematic approach to the validation step, see Validate PHI Removal in Patient CSV Files.

For the full 12-step pre-sharing sequence — from initial column mapping through final audit documentation — see Pre-Sharing PHI CSV Checklist.

The documentation step matters for a reason that is easy to overlook: regulators do not audit de-identification quality at the point of release. They audit it after an incident. A documented process is your evidence that the right steps were followed.

---

De-Identifying for Research and Secondary Use

Research creates specific data utility pressures that Safe Harbor's year-only date rule can undermine. If a study measures time-to-treatment, hospitalization intervals, or disease progression over months, collapsing all dates to year-only may destroy the temporal relationships the study depends on.

Two tools address this:

Date-shifting: A consistent per-patient random offset applied to all dates. The shift preserves temporal intervals between events while removing real calendar dates. A patient whose admission was 12 days after diagnosis retains that 12-day relationship in the shifted data. The shift offset must not be disclosed with the dataset — if it is, the transformation is reversible. Date-shifting is a technique within a de-identification workflow, not a standalone method. The 90+ rule still applies to date-shifted data.

Research authorization exception: Once patient data meets the Safe Harbor de-identification standard, HIPAA's authorization requirements no longer apply to it as a matter of regulatory structure. This is the practical benefit of full de-identification for research: IRB oversight requirements shift, authorization collection becomes unnecessary, and the data can be shared more broadly.

For the full research de-identification workflow — including date-shifting, age-banding, and the specific considerations for longitudinal studies — see De-Identify Patient Data for Research.

For HIPAA compliance considerations across regulatory frameworks (GDPR, CCPA), see GDPR, CCPA, and HIPAA CSV Compliance Comparison and HIPAA CSV Spreadsheet Compliance.

---

Where CSV Actually Shows Up in Healthcare

"Importing a CSV into an EHR" is not a standard clinical workflow. Enterprise EHR platforms operate natively on HL7 messages and FHIR resources for clinical data exchange. But CSV is genuinely present in healthcare data workflows — it appears at specific points that create specific handling challenges.

EHR Migrations

During go-live migrations, legacy patient data is exported to flat-file formats for conversion, validation, and testing. These staging extracts contain full PHI and regularly reach conversion vendors and non-production environments — often without the same security controls as production. De-identifying the extract before it enters the non-production workflow is the unaddressed privacy step most migration projects skip.

The strongest use case: non-production environments (QA, UAT, training, development) need realistic data for load testing and UAT validation. De-identified production data satisfies this requirement with no real patient risk. → EHR Data Migration: De-Identify Legacy Patient Data

For general EHR import formatting, see Format CSV for EHR Import — Healthcare Guide.

Patient List Imports

Ambulatory and practice-management platforms — athenahealth, eClinicalWorks, NextGen Healthcare, Practice Fusion — support patient demographic CSV imports for panel onboarding, practice setup, and migration from legacy systems. Patient demographic CSVs fail import for predictable format reasons: DOB format mismatch, missing required fields, duplicate patient detection triggering on legitimate records.

Patient demographic files contain PHI (name, DOB, MRN, contact information) — validate and reformat locally before import. → Patient List CSV Import Errors: Practice-Management EHRs

For CRM-specific patient data handling, see Healthcare CRM CSV Import and HIPAA Considerations.

Lab Results Data

Lab results CSVs carry two distinct problems simultaneously: format failures that block system import (LOINC code formatting, combined result/unit columns, reference range inconsistency) and embedded PHI that blocks legitimate research sharing (patient identifiers in structured columns, provider names in result comments).

LOINC (Logical Observation Identifiers Names and Codes), published by the Regenstrief Institute, is the standard coding system for laboratory tests. Lab CSVs that mix internal lab codes with LOINC codes or omit check digits will be rejected by EHR and LIS systems expecting strict LOINC format. → Lab Results CSV: Format and PHI Handling

For approaches to identifying PHI in notes and result comments, see De-Identify Free-Text PHI in Patient CSV Notes.

---

Why Local Processing Is the Privacy Floor

The environment where de-identification happens determines what obligations the processing step creates.

When patient CSV data is uploaded to a cloud-based tool for processing — conversion, validation, cleaning, de-identification — the upload is a disclosure of PHI to a third party. That third party becomes a business associate. HIPAA requires a BAA before that disclosure occurs.

When de-identification happens locally — entirely within the user's browser, with no file upload — no disclosure occurs for the processing step. The still-identified file never reaches a server. No business associate relationship is created by the de-identification step itself.

This is verifiable at zero cost: open browser DevTools → Network tab before starting a local de-identification run. Drag in a file. Process it. The Network log shows no upload requests.

The privacy floor is not "a BAA exists." The privacy floor is "the identified data never left the device during processing." A BAA is the minimum for cloud processing; local processing is a higher standard for the specific step of handling identified data before it becomes de-identified.

Scoped correctly: Local processing removes the BAA obligation for the de-identification step. It does not affect BAA obligations for other parts of the workflow: if the de-identified output is shared with a downstream analytics partner, that relationship is governed by the data's de-identification status and the partner's role. And "no BAA for the processing step" does not mean "no HIPAA obligations ever" — the covered entity's other HIPAA obligations continue in full.

The broader case for local-first data processing across clinical, research, and compliance use cases is covered in Privacy-First Data Processing Guide. For AI processing of healthcare CSV data and the specific GDPR and HIPAA implications, see AI Data Processing: Privacy, GDPR, and HIPAA.

For HIPAA-specific handling of patient data in spreadsheets and CSV tools, see HIPAA Safe CSV Cleaning Guide and HIPAA Data Masking: Anonymize Patient Records.

---

De-Identification Method Decision Tree

This decision tree is the primary bookmark artifact for this guide. Save it as a reference before any patient data release.

BEFORE SHARING PATIENT CSV DATA — DECISION TREE

STEP 1: Is this data going outside your organization?
│
├── NO (internal use only, within the covered entity)
│   └── HIPAA minimum-necessary standard applies.
│       De-identification not required for internal analytics.
│       Apply access controls and audit logging.
│
└── YES (external share, research partner, public repository, vendor)
    │
    STEP 2: Do recipients need a re-identification path?
    │
    ├── NO (recipients should not be able to re-identify individuals)
    │   │
    │   STEP 3: Which de-identification method applies?
    │   │
    │   ├── SAFE HARBOR: Remove all 18 identifier types.
    │   │   Apply specific rules for dates and geographic data.
    │   │   Document the process. No statistician required.
    │   │   → See: hipaa-safe-harbor-de-identify-patient-csv
    │   │
    │   └── EXPERT DETERMINATION: Engage a qualified statistician.
    │       Statistician certifies very small re-identification risk.
    │       Required when Safe Harbor destroys too much data utility.
    │       → See: safe-harbor-vs-expert-determination-csv
    │   │
    │   STEP 4: Do you need records to link across datasets?
    │   │
    │   ├── YES (longitudinal research, panel tracking)
    │   │   └── PSEUDONYMIZE: Replace patient IDs with non-derived codes.
    │   │       Retain mapping securely. Do not disclose mapping to recipient.
    │   │       Data remains PHI for you (you hold the key).
    │   │       → See: pseudonymize-patient-id-mrn-csv
    │   │
    │   └── NO → Remove patient IDs entirely.
    │
    └── YES (partner has BAA, internal research with authorization)
        └── PHI may be shared under BAA or authorization.
            Apply minimum-necessary standard to field selection.
            Confirm BAA is executed before disclosure.

STEP 5: Will the data enter a non-production environment?
│
├── YES (QA, dev, training, testing)
│   └── DE-IDENTIFY BEFORE LOADING.
│       Test environments are not production equivalents.
│       → See: ehr-migration-de-identify-legacy-patient-data
│
└── NO → Standard clinical data handling applies.

STEP 6: Will a cloud-based tool process the identified data?
│
├── YES (upload to cloud converter, validator, or de-id service)
│   └── BAA REQUIRED before upload.
│       Cloud vendor receives PHI; business associate relationship created.
│       → See: cloud-vs-browser-phi-de-identification
│
└── NO (process locally) → No disclosure for the processing step.

---

Additional Resources

Regulatory:

• 45 CFR §164.514 — De-identification of protected health information — the authoritative rule text
• HHS Guidance on Methods for De-identification of PHI — HHS's detailed guidance document on Safe Harbor and Expert Determination
• NIST SP 800-188 — De-Identifying Government Datasets — NIST's technical guidance on de-identification, useful for understanding statistical risk assessment

Standards and codes:

• LOINC Database — Regenstrief Institute's LOINC code search for verifying lab test identifiers

Technical:

• MDN Web Workers API — documentation on browser-based background processing; the technical basis for local, non-uploading data processing

Methodology: Safe Harbor de-identification requirements in this guide are verified against HHS guidance and 45 CFR §164.514, May 2026. HIPAA regulations are authoritative — verify current rule text at HHS.gov before finalizing any de-identification procedure for production data releases.

---

FAQ

Explore the Full PHI De-Identification Cluster

This guide is the anchor of a 13-post cluster. Each spoke covers one step or scenario in detail — the precise rules that this pillar summarizes and links to.

De-Identification Methods and Fundamentals

• HIPAA Safe Harbor De-Identification — Complete Workflow
• Safe Harbor vs Expert Determination: Which Method Applies
• Cloud vs Browser PHI De-Identification — BAA Requirements

The Specific Transformation Rules

• HIPAA Safe Harbor Date De-Identification — Year-Only Rule and 90+
• HIPAA Safe Harbor ZIP Code De-Identification — 3-Digit Rule
• De-Identify Free-Text PHI in Patient CSV Notes
• Pseudonymize Patient IDs and MRNs Under Safe Harbor

Validation and the Pre-Sharing Workflow

• Validate PHI Removal in Patient CSV Files
• Pre-Sharing PHI CSV Checklist — 12 Steps

Research and Secondary Use

• De-Identify Patient Data for Research — Date-Shifting and Age-Banding

Healthcare Data Workflows: Imports, Migration, Lab Data

• EHR Data Migration: De-Identify Legacy Patient Data
• Patient List CSV Import Errors: Practice-Management EHRs
• Lab Results CSV: Format and PHI Handling

---