A research coordinator at a regional hospital was preparing a patient dataset for an academic partner.
She had removed names, SSNs, phone numbers, and addresses — all 18 Safe Harbor identifiers, she believed.
The dataset still had this row:
patient_id,birth_date,admission_date,discharge_date,age,diagnosis
PT-4412,1931-03-15,2024-11-02,2024-11-07,93,CHF
A colleague flagged it before it went out.
birth_date: 1931-03-15 — the month and day are obvious PHI. But the birth year is also a problem: combined with admission_date, it reveals this patient is 93 years old. Under Safe Harbor, the birth year must be removed too. The age field must become "90 or older."
Dates are the most technically precise identifiers in patient records. Getting them wrong is one of the most common Safe Harbor compliance failures.
TL;DR
HIPAA Safe Harbor §164.514(b)(2)(i)(C) requires removing all date elements more specific than year from records directly related to an individual — birth, admission, discharge, and death dates become year-only. Any individual whose age exceeds 89 requires an additional step: the birth year itself, and any dates that would indicate such age, must also be removed and aggregated to "90 or older." Date-shifting is a compliant alternative for longitudinal research: a consistent per-patient random offset preserves time intervals between events without exposing real calendar dates.
Methodology note (May 2026): Rules in this guide follow 45 CFR §164.514(b)(2)(i)(C) as published. HIPAA regulations are authoritative — verify current rule text at HHS.gov before finalizing de-identification procedures for production data releases.
For the complete Safe Harbor workflow across all 18 identifiers, see our complete Safe Harbor de-identification workflow.
⚖️ NOT LEGAL ADVICE — This post covers HIPAA Safe Harbor date 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
- What §164.514(b)(2)(i)(C) Actually Requires
- The 90+ Aggregation Rule
- Which Date Columns Appear in Patient CSVs
- Reality: What a Pre-De-Identification CSV Looks Like
- Date-Shifting for Longitudinal Research
- Step-by-Step: Apply Date De-Identification in SplitForge
- Limitations
- FAQ
- Conclusion
What §164.514(b)(2)(i)(C) Actually Requires
The Safe Harbor date rule is precise. The regulation requires removing:
"All elements of dates (except year) for dates directly related to an individual, including birth date, admission date, discharge date, date of death..."
Three things follow from this:
1. Only year may remain. Month, day, and time components must go. 1979-07-22 becomes 1979. 2024-11-07 becomes 2024.
2. The rule covers dates "directly related to an individual." This includes birth, admission, discharge, and death — but the same logic applies to any date tied to the patient: procedure dates, visit dates, prescription fill dates, referral dates. If the date links to the patient's identity, it falls under this rule.
3. Year-only does not mean year is always safe. The second clause of the regulation adds the 90+ rule.
The 90+ Aggregation Rule
The full text of §164.514(b)(2)(i)(C) continues:
"...and all ages over 89 and all elements of dates (including year) indicative of such age, except that such ages and elements may be aggregated into a single category of age 90 or older."
This means:
- Any patient whose age exceeds 89 must have even the birth year removed — because birth year combined with the current year reveals age over 89
- Any dates that would allow a reader to infer age over 89 must also be aggregated
- The permitted replacement is the single category "90 or older"
Why? A birth year of 1931 in a 2024 dataset reveals that the patient is 93. Small elderly populations are statistically easier to re-identify even without names.
What stays, what goes:
| Patient | Birth Year | Age | After Safe Harbor |
|---|---|---|---|
| 45-year-old | 1979 | 45 | Birth year 1979 retained; age 45 retained |
| 67-year-old | 1957 | 67 | Birth year 1957 retained; age 67 retained |
| 93-year-old | 1931 | 93 | Birth year removed; age → "90 or older" |
| 91-year-old | 1933 | 91 | Birth year removed; age → "90 or older" |
Which Date Columns Appear in Patient CSVs
Date-type columns are pervasive in healthcare exports. Common examples:
Encounter and clinical dates:
birth_date,date_of_birth,dobadmission_date,admit_datedischarge_datedate_of_death,death_datevisit_date,appointment_dateprocedure_date,surgery_date
Administrative dates:
enrollment_date,plan_start_dateprescription_date,fill_date,dispense_datereferral_date,order_datelast_visit_date,next_scheduled_date
Derived date fields to check:
age_at_admission— may indirectly reveal birth yearlength_of_stay— safe (duration, not calendar date)days_since_last_visit— safe only if the reference date is also de-identified
Audit every column with "date," "dt," "time," or "year" in its name. Don't rely on column names alone — check values.
Reality: What a Pre-De-Identification CSV Looks Like
A typical EHR export before date de-identification:
patient_id,birth_date,admission_date,discharge_date,procedure_date,age,diagnosis
PT-1001,1979-07-22,2024-10-15,2024-10-18,2024-10-16,45,Type 2 Diabetes
PT-2047,1957-03-09,2024-10-20,2024-10-25,2024-10-22,67,COPD
PT-4412,1931-03-15,2024-11-02,2024-11-07,2024-11-04,93,CHF
PT-5518,1945-11-28,2024-11-10,2024-11-14,2024-11-11,78,Hypertension
After Safe Harbor date de-identification:
patient_id,birth_year,admission_year,discharge_year,procedure_year,age_group,diagnosis
PT-1001,1979,2024,2024,2024,45,Type 2 Diabetes
PT-2047,1957,2024,2024,2024,67,COPD
PT-4412,[removed],2024,2024,2024,90+,CHF
PT-5518,1945,2024,2024,2024,78,Hypertension
PT-4412: birth year removed (age 93 > 89), age replaced with "90+". All other patients: month and day stripped, year retained, age retained because ≤ 89.
Date-Shifting for Longitudinal Research
Year-only retention solves the compliance problem but can destroy research utility. If a study needs to measure time between events — days between diagnosis and first treatment, or interval between hospitalizations — stripping to year-only collapses that information.
Date-shifting is a compliant alternative recognized in HIPAA guidance:
How it works:
- Generate a consistent random offset for each patient (e.g., patient PT-1001 always shifts by −47 days)
- Apply the same offset to all of that patient's dates
- Publish the shifted dates
What it preserves: Temporal intervals between events are intact. If admission was 12 days after diagnosis, that 12-day relationship survives.
What it removes: Real calendar dates. A reader cannot determine that admission was October 2024 — only that it was 12 days after diagnosis in the shifted timeline.
Key constraint: The shift offset must not be disclosed with the data. If the offset is included, the transformation is reversible.
The 90+ rule still applies to date-shifted data. If a patient's birth year (after shifting) still implies age over 89, that birth year must be removed or the age must be aggregated to "90 or older."
Date-shifting is not the same as Safe Harbor — it is a supporting technique within a Safe Harbor or Expert Determination workflow, not a standalone method.
Step-by-Step: Apply Date De-Identification in SplitForge
1. Load the patient CSV
Open SplitForge Data Masking and drag in your file. The tool reads locally — no upload, no server transmission.
2. Identify date columns
Scan column names for date fields. Select each date column you need to de-identify.
3. Apply year-only truncation
For each date column, configure masking to retain year only. The tool will strip month and day components.
4. Apply the 90+ rule
For the age column (or birth_year if retained), configure masking to:
- Replace values over 89 with the label "90 or older"
- Remove the birth year for rows where age exceeds 89
5. Review derived fields
Check any columns that contain durations, age-at-event, or similar derived values. Retain duration fields (they contain no calendar date). For age-at-event fields, apply the same 90+ aggregation logic.
6. Validate output
Confirm no month/day values remain in any date column. Confirm no age values over 89 remain. Confirm birth years are absent for the 90+ population.
Processing happens locally in your browser, which means the de-identification step creates no disclosure to a business associate — see Cloud vs. Browser PHI De-Identification for the full BAA analysis.
Limitations
Satisfying Safe Harbor removes data from HIPAA's definition of PHI; it does not make the data anonymous. De-identified ≠ anonymized — residual re-identification risk can remain, and "actual knowledge" that the remaining data could identify someone re-activates HIPAA obligations.
Year-only loses temporal precision. 2024-10-15 and 2024-10-28 both become 2024 — the 13-day difference disappears. For studies where intra-year timing matters, consider date-shifting instead.
The 90+ check requires accurate age data. If your CSV lacks a reliable age or birth year column, automated detection of the 90+ population is not possible. Manual review may be required.
Date-shifting is not a Safe Harbor standalone. Date-shifting must be part of a documented de-identification process — removing it from that context does not satisfy Safe Harbor on its own.
Manual review remains advisable for high-stakes releases. De-identification of clinical data for external publication warrants review by a qualified privacy officer or legal counsel, particularly for research involving elderly populations or rare conditions.
FAQ
Conclusion
Safe Harbor date de-identification has two distinct requirements most teams miss:
Requirement 1: Strip all date elements more specific than year from any date directly related to the individual. Birth, admission, discharge, and death dates — month and day go; year stays.
Requirement 2: For the 90+ population — remove the birth year too. Age over 89 and dates that reveal such age must aggregate to the single category "90 or older."
The research coordinator's near-miss wasn't carelessness. The 90+ rule is easy to overlook when the structured de-id pass already removed names and explicit identifiers. A birth year of 1931 doesn't look like a name. It looks like a number. But in combination with the dataset's context, it identifies a specific elderly patient.
For longitudinal studies where year-only would lose critical temporal information, date-shifting preserves research utility while removing real calendar dates — as long as the shift offset remains confidential and the 90+ rule still applies to shifted data.