Large language models (LLMs) are AI systems trained on vast amounts of text to understand and generate human-like language, the technology behind tools like chatbots, writing assistants, and text-summarization APIs. Most public LLM APIs and consumer chat tools are not covered by a business associate agreement (BAA), which means that under HIPAA, they are not authorized to receive protected health information (PHI).

HIPAA treats dates as one of the 18 identifiers that make data "individually identifiable," for instance, a birthdate combined with a zip code and a gender can uniquely identify a person.

Read also: How to de-identify protected health information for privacy

 

Why dates are a special category under HIPAA

The HIPAA Safe Harbor method (45 CFR §164.514(b)(2)) lists specific rules for dates related to an individual. Per the regulatory text itself, quoted from HHS's Safe Harbor guidance, "All elements of dates (except year) for dates that are directly related to an individual, including birth date, admission date, discharge date, death date, 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."

The only exception is ages under 89 can be reported as-is, but ages 90 and older must be aggregated into a single "90 or older" category, because very old age combined with location data creates a real re-identification risk in small populations.

In other words, "March 14, 1952" is not safe harbor compliant, but "1952" is. HHS's guidance notes this with an example, "Elements of dates that are not permitted for disclosure include the day, month, and any other information that is more specific than the year of an event. For instance, the date 'January 1, 2009' could not be reported at this level of detail. However, it could be reported in a de-identified data set as '2009'."

The age-90 rule gets a worked example in the same guidance, "For example, if the patient's year of birth is 1910 and the year of healthcare service is reported as 2010, then in the de-identified data set the year of birth should be reported as 'on or before 1920.'" It's not just the birth year that has to be masked once someone crosses into the 90+ category, the service-record year has to be handled carefully too, since the two together would otherwise reveal the approximate age.

Learn more: When do you have to use deidentified data sets?

 

The techniques

1. Year-only generalization

The simplest approach is to strip the month and day from any PHI-related date and retain only the year. This satisfies Safe Harbor directly and requires no complex tools.

It's worth noting that this applies even to dates you might assume are "operational" rather than personal, like lab or test dates. HHS addresses this by stating, "Dates associated with test measures, such as those derived from a laboratory report, are directly related to a specific individual and relate to the provision of health care. Such dates are protected health information."

Research on structured health data de-identification, titled “Ten quick tips for protecting health data using de-identification and perturbation of structured datasets”, has recommended reporting age at an event instead of an exact birthdate, with the granularity of that age scaled to how fast a person changes at that life stage, days for neonates up to two weeks old, weeks for infants up to eight weeks, months up to two years, and years thereafter so that early-life health trends stay analyzable without ever exposing a precise birthdate.

 

2. Date shifting (for use cases that need temporal relationships)

Year-only dates work for many summarization tasks, but they destroy information about elapsed time, how many days passed between two visits, or how long a treatment course lasted.

Date shifting means applying a random offset (say, between -365 and +365 days) to every date associated with a given patient, and applying that same offset consistently across every record for that patient. This preserves the relative spacing between events, a 10-day gap between two visits stays a 10-day gap, while destroying the actual calendar dates. Furthermore:

  • The offset must be generated per patient, not per record, or temporal relationships will be scrambled.
  • The offset must be stored securely and separately from the de-identified dataset, ideally behind access controls, since it functions as a re-identification key. HHS's guidance on the re-identification provisions of the Privacy Rule states that the regulation requires that a covered entity, "does not use or disclose the code or other means of record identification for any other purpose, and does not disclose the mechanism for re-identification."

However, date shifting alone is not automatically Safe Harbor compliant, it falls under the "Expert Determination" method (45 CFR §164.514(b)(1)), which requires a qualified statistician or privacy expert to certify that re-identification risk is very small. HHS defines that method as requiring, "A person with appropriate knowledge of and experience with generally accepted statistical and scientific principles and methods for rendering information not individually identifiable... determines that the risk is very small that the information could be used, alone or in combination with other reasonably available information, by an anticipated recipient to identify an individual."

Furthermore, health data privacy researchers, from the research on structured health data de-identification, distinguish between shifting an entire dataset by one undisclosed offset versus assigning a separate random offset to each individual patient, noting that a per-individual shift further reduces the chance that the de-identification process could be reverse-engineered by an outside party.

 

3. Outright removal

If the LLM task doesn't need date information at all, for example, summarizing the clinical content of a note, the safest option is to remove the date fields rather than transform them.

Learn more: How to choose the right method for deidentification

 

Don't forget dates hiding in free text

Clinical narrative text, where dates show up in sentences like "patient was seen in the ER on 6/2 and again 6/9 following a fall," are not so easy to deal with. HHS's guidance notes that the Safe Harbor standard makes no allowance for unstructured text, "The de-identification standard makes no distinction between data entered into standardized fields and information entered as free text... an identifier listed in the Safe Harbor standard must be removed regardless of its location in a record if it is recognizable as an identifier."

Before sending narrative text to a non-BAA LLM, run it through a dedicated de-identification tool that can detect and generalize or redact dates, along with names, MRNs, and other identifiers embedded in free text.

 

Watch for combined re-identification risk

Even a fully Safe Harbor-compliant dataset can become re-identifiable when dates interact with other quasi-identifiers such as rare diagnoses, small geographic areas, or unusual demographic combinations. If your dataset includes year-only dates alongside a rare condition and a small zip code, consider whether additional generalization or an Expert Determination review is needed.

Health data privacy research distinguishes two attacker scenarios, a "prosecutor" scenario, where an outside party already knows a specific individual is somewhere in the dataset and is trying to pick them out, versus a "journalist" scenario, where the attacker doesn't know who's in the dataset and is scanning for any uniquely identifiable record. The prosecutor risk is calculated as one divided by the number of individuals who share the exact same combination of quasi-identifiers, so if a shifted admission date, an age, a sex, and a postcode together match only one other person in a dataset of a thousand, that individual has a 50% re-identification risk under that scenario. The conclusion from the research is that a date field that looks compliant in isolation can still leave a patient identifiable once it's combined with age, location, and a rare diagnosis, and it's worth actually counting how many records share a given combination of fields rather than assuming generalization alone has solved the problem.

 

A pre-send checklist

Before any healthcare data reaches a non-BAA-covered LLM:

  1. Inventory every date field in the dataset, including free text.
  2. Decide whether the use case needs temporal relationships (favor shifting) or not (favor year-only generalization or removal).
  3. If shifting, generate and securely store per-patient offsets separately from the working dataset.
  4. Run free text through a clinical NLP de-identification tool, not just structured-field scrubbing.
  5. Check for combined re-identification risk from other quasi-identifiers.
  6. Document the method used (Safe Harbor vs. Expert Determination) for compliance records.

 

FAQs

Does running an LLM locally or on-premises avoid the need for a BAA?

Yes, a BAA is only required when PHI is disclosed to an outside vendor, so a model hosted within your own controlled environment isn't subject to the same restriction, though you still need to verify no data leaves your infrastructure.

 

Is a de-identified dataset still considered PHI once dates and other identifiers are removed?

No, once data meets the Safe Harbor or Expert Determination standard, HIPAA no longer classifies it as PHI, and it can generally be shared and used more freely.

 

Does de-identifying dates also satisfy privacy laws outside the US, like GDPR?

Not automatically, GDPR's anonymization bar is generally stricter than HIPAA Safe Harbor, so a Safe Harbor–compliant dataset may still need additional review before it qualifies as anonymized under GDPR.

 

Can synthetic data generation be used instead of de-identifying real dates?

Yes, some organizations generate synthetic patient records that preserve statistical patterns without corresponding to any real individual.