Quick Answer
What does HIPAA Safe Harbor de-identification require?
Safe Harbor, defined under 45 CFR §164.514(b)(2), requires removing all 18 HHS-specified identifier categories from a dataset — not just names, SSNs, and dates. A dataset satisfies Safe Harbor only when every identifier category has been addressed AND the covered entity has no actual knowledge that remaining data could identify an individual.
The fix: Remove all 18 identifier categories from your patient CSV using SplitForge Data Masking. Files process entirely in your browser — PHI never reaches a server, so the de-identification step does not create a BAA relationship for that processing activity.
TL;DR: HIPAA Safe Harbor requires removing all 18 HHS-defined identifier categories from patient CSV data — not just the obvious ones. Most de-id processes stop after names, SSNs, and dates, leaving device IDs, patient portal URLs, IP addresses, biometric identifiers, full-face photos, and the §164.514 catch-all clause unaddressed. Remove all 18 in-browser with SplitForge Data Masking — PHI never leaves your device, so no BAA is required for the de-identification processing step.
For the complete Safe Harbor workflow across all 18 identifiers, see our complete HIPAA Safe Harbor de-identification guide.
⚖️ NOT LEGAL ADVICE — This post covers HIPAA Safe Harbor 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.
Your hospital's research team needs to share a patient cohort extract with an academic partner. Someone ran a de-identification script three months ago: names removed, SSNs blanked, birthdates stripped to year only. The file looks clean. 847 records, cleared for sharing.
Then your privacy officer opens the CSV and finds the patient_portal_url column: https://patientportal.hospital.org/u/MRN-00142. The MRN is embedded in the URL path. The device_id column contains IMEI numbers from remote monitoring equipment. The ip_address column was included in the export and never cleared.
The script removed identifiers 1, 6, and 7 from the HHS list. It left identifiers 8, 13, 14, and 15 intact. Under 45 CFR §164.514(b), this dataset is still PHI. The planned data-sharing agreement would be a HIPAA disclosure violation before the first record transmits.
Every identifier category HHS specifies is there for a reason. The ones at the end of the list — device IDs, URLs, IP addresses, biometric identifiers, photographs, and the catch-all — are not afterthoughts. They are the identifiers that survive standard de-identification processes and enable re-identification from secondary-use exports.
This guide covers all 18. The reference table is the one to print and run against your actual CSV schema before any de-id process.
Each identifier category and its handling was verified against HHS Safe Harbor guidance (45 CFR §164.514(b)(2)) and the HHS Guidance Regarding Methods for De-identification of Protected Health Information, May 2026.
Table of Contents
- What Is HIPAA Safe Harbor De-Identification?
- The Complete 18-Identifier Reference Table
- The Identifiers Most De-Id Processes Miss
- How to Handle Each Category in a Patient CSV
- De-Identify Patient CSV Without Uploading PHI
- After De-Identification: Validate and Document
- Additional Resources
- FAQ
This guide is for: HIPAA compliance officers, clinical data analysts, healthcare IT administrators, and research data coordinators who need to share or process patient CSV data after PHI removal.
Already know the basics? Jump to The Complete 18-Identifier Reference Table.
What Is HIPAA Safe Harbor De-Identification?
HIPAA provides two HHS-recognized methods for de-identifying PHI under 45 CFR §164.514: Safe Harbor (§164.514(b)(2)) and Expert Determination (§164.514(b)(1)). Safe Harbor is the more commonly used method because it follows a defined list of identifier categories rather than requiring a qualified statistical expert.
A dataset satisfies Safe Harbor when two conditions are met: (1) all 18 HHS-specified identifier categories have been removed or appropriately addressed, AND (2) the covered entity has no actual knowledge that the remaining information could be used — alone or in combination with other available information — to identify an individual.
The "actual knowledge" condition is not a formality. A covered entity cannot remove 18 identifiers from a dataset and declare it de-identified if it knows that remaining quasi-identifiers would enable re-identification of specific records. Research by Latanya Sweeney demonstrated that 87% of the U.S. population can be uniquely identified using only ZIP code, date of birth, and sex — which is why HIPAA's geographic and date handling rules are specific rather than general.
Safe Harbor produces de-identified data — data that no longer meets the HIPAA definition of PHI. De-identified data is not the same as anonymous data in every legal sense. Re-identification risk remains, particularly for datasets with unusual combinations of quasi-identifiers. Satisfying Safe Harbor means the data is outside HIPAA's scope; it does not mean re-identification is impossible.
For datasets where strict analytical utility is needed alongside stricter de-identification guarantees, see the Expert Determination method — covered in Safe Harbor vs. Expert Determination for Patient CSV Data.
The Complete 18-Identifier Reference Table
Run every column in your patient CSV against the "Typical CSV Column Names" column. For each match, apply the action in the "Safe Harbor Action" column. A dataset is not Safe Harbor compliant until every row has been addressed. This table is the primary reference for this post.
| # | HHS Identifier Category | Typical CSV Column Names | Safe Harbor Action | Compliant Output Example |
|---|---|---|---|---|
| 1 | Names | patient_name, first_name, last_name, full_name | Remove entirely | [REMOVED] or column dropped |
| 2 | Geographic subdivisions smaller than state | address, street, city, county, zip_code, postal_code | Remove street, city, county; retain only first 3 ZIP digits if 3-digit area population exceeds 20,000; otherwise replace with 000 | 941 (3-digit prefix) or 000 (low-population area) |
| 3 | Dates (except year) directly related to individual; ages 90+ aggregated | dob, birth_date, admission_date, discharge_date, death_date, service_date | Retain year only; for ages 90+: remove birth year and aggregate to "90 or older" | 1962 not 1962-03-14; 90 or older for age ≥90 |
| 4 | Telephone numbers | phone, mobile, contact_phone, work_phone | Remove entirely | [REMOVED] |
| 5 | Fax numbers | fax, fax_number, office_fax | Remove entirely | [REMOVED] |
| 6 | Email addresses | email, patient_email, contact_email | Remove entirely | [REMOVED] |
| 7 | Social Security numbers | ssn, social_security, tax_id | Remove entirely | [REMOVED] |
| 8 | Medical record numbers | mrn, patient_id, chart_number, record_number | Remove or replace with non-linked research identifier | RES-00142 (new non-linked ID; not derivable from original MRN) |
| 9 | Health plan beneficiary numbers | insurance_id, plan_member_id, beneficiary_number, member_id | Remove entirely | [REMOVED] |
| 10 | Account numbers | account_id, billing_account, subscriber_id, encounter_id | Remove entirely | [REMOVED] |
| 11 | Certificate and license numbers | license_number, npi, dea_number, state_license | Remove entirely | [REMOVED] |
| 12 | Vehicle identifiers and serial numbers, including license plates | vin, license_plate, vehicle_id, car_registration | Remove entirely | [REMOVED] |
| 13 | Device identifiers and serial numbers | device_id, serial_number, imei, mac_address, pacemaker_id | Remove entirely | [REMOVED] |
| 14 | Web Universal Resource Locators (URLs) | patient_portal_url, profile_url, referral_url | Remove entirely | [REMOVED] |
| 15 | IP addresses | ip_address, session_ip, login_ip, source_ip | Remove entirely | [REMOVED] |
| 16 | Biometric identifiers, including finger and voice prints | fingerprint_hash, voice_id, retinal_scan, face_embedding | Remove entirely | [REMOVED] |
| 17 | Full-face photographs and any comparable images | photo_url, image_path, profile_picture, face_image | Remove entirely | [REMOVED] |
| 18 | Any other unique identifying number, characteristic, or code | Internally-generated patient tokens, kiosk IDs, research cohort codes with a reversal mechanism | Remove or replace with irreversible research code — if any mechanism exists to link back to an identifiable individual, this is a HIPAA identifier | [REMOVED] or irreversible research code |
How to use this table: Map every column header in your patient CSV against column 3. For each match, apply the action in column 4. Identifiers 1–7 appear in most operational exports. Identifiers 8–12 appear in clinical and billing data. Identifiers 13–17 appear in wearables data, patient portal logs, monitoring exports, and telehealth session records.
Identifier #18 — the catch-all: The clause in 45 CFR §164.514(b)(2)(i)(R) covers "any other unique identifying number, characteristic, or code" except as permitted by the regulation. An internally-generated patient token is an identifier under #18 if a lookup table or other mechanism would allow reversal to the original patient — even if the token itself contains no directly identifying information. The test is whether re-identification is possible, not whether the value looks like an identifier.
The Identifiers Most De-Id Processes Miss
Most de-identification processes address identifiers 1–7 reliably: names, geographic data, dates, phone numbers, fax numbers, email addresses, and SSNs. Identifiers 8–12 are handled less consistently. Identifiers 13–18 are the ones most often missed entirely — and they appear with increasing frequency as healthcare data integrates with device, portal, and analytics systems.
What "names and SSNs removed" actually looks like in a real secondary-use export:
❌ BROKEN — de-id process removed identifiers 1, 6, 7 (names, emails, SSNs). Still PHI.
mrn,admission_year,device_id,patient_portal_url,ip_address,zip_code
MRN-00142,1962,IMEI-356938035643809,https://patientportal.hospital.org/u/00142,192.168.1.47,94103
MRN-00143,1978,IMEI-354356089624498,https://patientportal.hospital.org/u/00143,192.168.1.53,94107
Remaining PHI (identifiers NOT addressed):
- mrn: identifier #8 — medical record number intact, not pseudonymized
- device_id: identifier #13 — monitoring device IMEI still present
- patient_portal_url: identifier #14 — URL contains embedded MRN in path
- ip_address: identifier #15 — patient session IP retained
- zip_code: identifier #2 — full 5-digit ZIP retained (only 3 digits permitted)
FIXED (Safe Harbor compliant for identifiers 2, 8, 13, 14, 15):
mrn,admission_year,device_id,patient_portal_url,ip_address,zip_code
RES-001,1962,[REMOVED],[REMOVED],[REMOVED],941
RES-002,1978,[REMOVED],[REMOVED],[REMOVED],941
The bottom record addresses identifiers 2, 8, 13, 14, and 15. The top record is PHI regardless of how many names and SSNs were removed. A dataset with intact MRNs, device IMEIs, patient portal URLs, and IP addresses is fully re-identifiable.
Why these identifiers appear in secondary-use exports:
Device identifiers (#13) appear in any dataset sourced from wearables, infusion pumps, glucose monitors, or remote monitoring equipment. Patient portal URLs (#14) appear when CRM or analytics systems export engagement and session data — the MRN is commonly embedded in the URL path. IP addresses (#15) appear in access logs, telehealth session records, and patient portal authentication event exports. These columns pass through standard de-id checklists because they do not look like "patient information" to non-clinical data engineers.
How to Handle Each Category in a Patient CSV
Every identifier requires a specific decision: remove, pseudonymize, generalize, or aggregate. The choice depends on whether the column carries downstream analytical value.
Remove entirely: Identifiers with no secondary-use value — telephone numbers, fax numbers, email addresses, SSNs, health plan IDs, account numbers, certificate numbers, vehicle identifiers, device IDs, web URLs, IP addresses, biometric hashes, and image paths. Removing these columns entirely reduces dataset size and eliminates re-identification vectors with no analytical trade-off.
Pseudonymize: Identifiers where record linkage across datasets matters — medical record numbers (#8) are the primary case. Replace MRNs with a consistent, non-linked research identifier (for example, RES-00142) so that multiple records for the same patient can be joined in longitudinal analysis without exposing the actual MRN. The research identifier must not be derivable from the original MRN, and any lookup table enabling reversal must be secured separately and not accompany the de-identified dataset. Identifier #18 applies: if a mechanism exists to reverse the pseudonymous ID, it remains a HIPAA identifier.
Generalize: Geographic data (#2) and dates (#3) are generalized rather than removed. ZIP codes are truncated to their first three digits — but for 3-digit prefixes whose population is 20,000 or fewer, HIPAA requires replacing all three digits with 000. HHS publishes the specific low-population prefix list. For dates, retain only the year. Ages 90 and above must be represented as "90 or older" — a specific year of birth can indirectly identify individuals in elderly cohorts even when other identifiers are removed. See ZIP Code De-Identification: The 3-Digit and 20,000-Population Rule and Date De-Identification Under Safe Harbor for the exact handling rules.
Free-text columns: Clinical notes, discharge summaries, referral descriptions, and narrative fields require a separate de-identification pass. A structured-column de-id process removes the patient_name column — it does not remove "John Smith" from a discharge summary stored in a notes column. Names, MRNs, phone numbers, and provider names commonly appear embedded in free-text. See De-Identify Free-Text and Notes Columns: PHI Hidden in Description Fields for the specific handling workflow.
De-Identify Patient CSV Without Uploading PHI
Most de-identification approaches — cloud tools, SaaS de-id platforms, and hosted services — require uploading the patient file to process it. Under 45 CFR §§164.502(e) and 164.504(e), any vendor whose servers receive PHI on behalf of a covered entity generally qualifies as a Business Associate, requiring a signed BAA before use. Uploading an identified patient CSV to a de-identification vendor to produce a de-identified output creates a BAA relationship for that upload and any retention period the vendor applies under its terms of service.
Browser-based processing removes the upload step from the BAA scope. When a file is processed entirely in Web Worker threads in your browser — using the browser File API, with no network transmission of file contents — the PHI does not reach a third-party server. For the de-identification processing step itself, no BAA relationship arises for that activity. This is verifiable: open browser DevTools, go to the Network tab, and confirm that no file contents are transmitted during processing.
This does not mean browser-based de-identification satisfies all HIPAA obligations. Full compliance requires access controls, audit logging, workforce training, risk analysis, and policies covering how identified and de-identified data are stored and shared. The BAA reduction is scoped to the processing step — not to the full compliance program.
De-identification workflow with SplitForge Data Masking:
- Open SplitForge Data Masking in your browser — no account required, no upload.
- Load your patient CSV. The file is read locally using the browser File API. Nothing is transmitted.
- Map each column to the corresponding Safe Harbor action from the reference table above.
- Apply masking strategies per category: suppression for telephone/email/SSN/device/URL/IP columns; pseudonymization for MRN columns; truncation for ZIP codes; year-only for date columns.
- Process. The operation runs in a Web Worker thread, keeping the browser responsive for large files.
- Download the de-identified CSV output. Validate before any sharing or downstream use.
For datasets exceeding one million rows, use a batch approach: split by department or facility extract, mask each batch independently, validate each, then merge. See HIPAA Data Masking: Anonymize 1M Patient Records Without Uploading PHI for the streaming architecture and scale-specific workflow.
After De-Identification: Validate and Document
Removing the 18 identifiers produces a de-identified dataset under Safe Harbor. Validation confirms that removal was complete and that no residual PHI survived in non-obvious columns or embedded in values that passed the structured pass.
Minimum validation steps after de-identification:
- Pattern scan — search all columns for residual patterns: SSN format (
XXX-XX-XXXX), phone number formats, email patterns (@), URL patterns (https://), and IMEI formats (15-digit numeric strings). - MRN audit — confirm that MRN columns contain only research identifiers, not values sharing format characteristics with the original MRNs.
- ZIP code check — confirm no 5-digit ZIP codes remain; verify that low-population 3-digit prefixes are replaced with
000. - Age and date review — confirm all dates are year-only; confirm ages 90 and above are represented as "90 or older."
- Free-text scan — check narrative and notes columns for names, phone numbers, or identifiers that survived the structured pass.
- Row count verification — input and output row counts must match. Silent truncation means unprocessed rows that may still contain unmasked PHI.
For the complete validation workflow with residual-PHI detection, see Validate PHI Removal: Confirm All 18 Identifiers Are Gone Before You Share.
Documentation HIPAA requires you to maintain:
HIPAA requires documentation of the de-identification process, including: the column-to-identifier mapping (which columns correspond to which identifier categories), the masking method applied to each, the validation steps taken, the tools used, the date and personnel, and attestation that the output satisfies Safe Harbor. This documentation is required for OCR audits and is the basis for demonstrating accountability under 45 CFR §164.530(j). Name de-identified output files systematically: [Department]_[DataType]_[YYYY-MM-DD]_deidentified.csv — this prevents confusion between identified and de-identified copies.
Additional Resources
Official HIPAA De-Identification Guidance:
- HHS Guidance Regarding Methods for De-identification of Protected Health Information — Authoritative HHS guidance on Safe Harbor and Expert Determination, including worked examples
- 45 CFR §164.514 — De-identification of Protected Health Information (eCFR) — Full regulatory text of both Safe Harbor and Expert Determination methods
- HHS OCR Resolution Agreements and Civil Money Penalties — Enforcement case documentation including de-identification failures
Technical Standards:
- NIST SP 800-188: De-Identification of Government Datasets — Federal de-identification standard covering methods, risk assessment, and re-identification testing
- MDN Web Workers API — Technical specification for browser-native file processing without server transmission
- MDN File API — How browsers read local files without server upload
Verified against: HHS Safe Harbor guidance (45 CFR §164.514(b)(2)) and HHS Guidance Regarding Methods for De-identification of Protected Health Information, May 2026. External links pending verification before publish — see Hard Gate 7.