Healthcare teams building AI features keep running into the same wall: the model needs real clinical data to be useful, but HIPAA governs how that data can be used, and "anonymized" is not a term the regulation actually defines. If you are training a model, fine-tuning one, or sending clinical text to a third-party AI API, you need to know exactly what HIPAA requires before that data leaves a protected environment. This article walks through the two methods HIPAA recognizes for de-identifying protected health information, where AI and machine learning projects specifically run into trouble, and a practical workflow for getting this right before training starts.
"De-Identified" Is a Legal Standard, Not a Feeling
In everyday conversation, people use "anonymized" to mean "we removed the name." Under HIPAA, that is not enough. The Privacy Rule defines de-identified health information as information for which there is no reasonable basis to believe it can be used to identify an individual, and it recognizes exactly two methods for reaching that standard under 45 CFR 164.514: Safe Harbor and Expert Determination. If your process does not match one of these two methods, the resulting dataset is still protected health information in the eyes of regulators, no matter how thoroughly you think you scrubbed it.
This distinction matters more for AI projects than for most other uses of health data, because AI pipelines tend to involve steps that regulators specifically worry about: moving data to new environments, combining it with other datasets, and generating new text or synthetic records from it. Each of those steps can quietly undo a de-identification effort that looked solid on paper.
The Two Methods HIPAA Actually Recognizes
Safe Harbor: Remove 18 Specific Identifiers
Safe Harbor is the more mechanical of the two paths. Under 164.514(b)(2), a covered entity or business associate removes 18 categories of identifiers relating to the individual, their relatives, employers, or household members, and has no actual knowledge that the remaining information could still identify someone. The categories include the obvious ones (names, Social Security numbers, medical record numbers, email addresses, phone numbers, device identifiers, full-face photographs) and several that trip up engineering teams building training datasets:
- Geographic detail smaller than a state, including street address and ZIP code, except that the first three digits of a ZIP code may be kept if the area those three digits cover has more than 20,000 people (otherwise it is changed to 000).
- Every date element more specific than the year that relates to an individual, including birth date, admission date, discharge date, and date of death. Ages over 89 must be aggregated into a single "90 or older" category.
- Any other unique identifying number, characteristic, or code, a catch-all category that in practice covers things like internal patient IDs, device serial numbers embedded in free text, and biometric identifiers.
For structured database fields, Safe Harbor is relatively easy to automate: drop the columns, bucket or hash the geography, and truncate the dates. The real difficulty shows up in free-text fields, which is exactly the content most valuable for training clinical language models.
Expert Determination: Statistical Risk Assessment
The second path, under 164.514(b)(1), does not require stripping a fixed list. Instead, a person with appropriate statistical and scientific training applies accepted methods to determine that the risk of the information being used, alone or combined with other reasonably available information, to identify an individual is very small, and documents the analysis and methods behind that conclusion.
Expert Determination is the method most AI teams actually want, because it can preserve far more analytical and training value than Safe Harbor's blunt removals. A qualified expert can, for example, keep more precise dates or richer geographic detail if the statistical risk of re-identification given the dataset's size, context, and likely recipients is still assessed as very small. The tradeoff is that it requires a qualified person to do the assessment and produce documentation that would hold up if the determination is ever challenged. There is no shortcut version of this where an engineering team self-certifies that risk is "probably fine."
Why This Is Harder for AI and ML Projects Specifically
Three issues come up repeatedly once a de-identification effort is aimed at a model rather than a report or a research dataset.
Unstructured text hides identifiers that structured fields do not. Clinical notes, discharge summaries, and transcribed visit recordings routinely contain names, employer references, specific dates, and identifying details embedded in sentences, not in a column you can drop. Simple find-and-replace or regex-based scrubbing misses variants (nicknames, misspellings, indirect references like "my daughter who works at [employer]") that a trained person or a validated clinical NLP de-identification tool is built to catch. Teams that rely on a generic scrubber and call the result "de-identified" are often still holding PHI.
Model outputs and synthetic data are not automatically de-identified just because they are generated. If a model is trained or fine-tuned on real patient records, its outputs can memorize and reproduce rare combinations of details, especially with small training sets or over-trained models on long-tail cases. Synthetic data generated from real PHI inherits the same de-identification obligation as the source: if a synthetic record is specific enough to be traced back to the person it was modeled on, it has not actually solved the problem, it has relabeled it.
Combining de-identified data with other datasets can re-create identifiability. This is often called the mosaic effect. A dataset that is safely de-identified in isolation can become identifying again once joined with another dataset, a public records source, or even another AI system's own context window. AI pipelines that pull in multiple sources, enrich records, or retain long conversation histories need to evaluate re-identification risk at the level of what the system can access in combination, not just what one input file contains.
Where Teams Get This Wrong in Practice
- Treating a third-party AI API as automatically safe once "the obvious fields" are removed. If PHI, even partially de-identified PHI that does not meet the Safe Harbor or Expert Determination standard, is sent to a vendor's model, that vendor is acting as a business associate and needs a signed business associate agreement before any PHI reaches its systems. Properly de-identified data, by contrast, is no longer PHI and the BAA requirement for that specific data flow falls away, which is exactly why getting de-identification right has real operational consequences, not just compliance box-checking.
- Assuming Safe Harbor automatically applies to free text just because it was run through a tool labeled "de-identification." Validate the tool against your actual data. A scrubber tuned for billing records will not reliably catch the identifiers that show up in clinical narrative text.
- Skipping documentation on the Expert Determination path. If a dispute or audit arises later, "we think it was fine" is not a defense. The expert's methodology, assumptions, and conclusion need to be written down at the time the determination is made, not reconstructed afterward.
- Forgetting re-identification risk from the model itself. A model fine-tuned on a small, specific patient population (a single clinic's rare-disease cohort, for instance) can effectively memorize enough detail that its outputs recreate identifiable information even though the training pipeline handled the input data correctly.
A Practical Workflow Before Training or Fine-Tuning Starts
- Inventory the data and its intended destination. Know exactly which fields, including free text, will be used, and whether the destination is an internal model, a fine-tuning job on a third-party platform, or a vendor API call.
- Decide which method fits the use case. If the project can tolerate losing precise dates, fine geography, and rare identifying details, Safe Harbor is faster and does not require bringing in an outside expert. If the project needs more analytical fidelity (precise timing for clinical event sequencing, detailed geography for population health modeling), plan for Expert Determination and budget the time and cost of a qualified statistician.
- Handle structured and unstructured data separately. Automate removal and bucketing for structured fields. For free text, use a validated clinical NLP de-identification approach and spot-check output against a sample of records a human reviews line by line, not just a pass/fail scan.
- Assess combination risk, not just single-dataset risk. If the AI system will have access to multiple data sources, or will retain context across sessions, evaluate what becomes identifiable when those sources are considered together.
- Document the determination and keep it current. For Expert Determination specifically, the written analysis is the artifact that demonstrates compliance. For Safe Harbor, document which identifiers were removed and how the "no actual knowledge" standard was evaluated.
- Treat vendor AI tools as business associates until proven otherwise. Unless the data leaving your environment meets the de-identification standard before it reaches the vendor, assume a business associate agreement is required, and confirm the vendor's own data handling and retention practices for training purposes.
- Log the process. Who ran the de-identification pipeline, when, against what dataset version, and what was removed. This ties into the same audit logging discipline that HIPAA's security rule expects for PHI access generally, and it is the record you want available if a determination is ever questioned.
NIST's SP 800-188 guidance on de-identifying government datasets is a useful technical reference alongside the HIPAA standard. It is not itself a HIPAA requirement, but its discussion of re-identification risk, formal privacy methods like differential privacy, and the limits of traditional de-identification techniques is directly relevant to anyone designing a pipeline that feeds an AI model rather than a static report.
Where This Fits With Other AI Work in Healthcare
De-identification decisions do not happen in isolation. They sit alongside the broader set of choices a team makes when building healthcare AI features: what infrastructure and security controls the training and inference environment needs, how a system like ambient clinical documentation handles the raw audio and transcripts it processes before any model sees them, and how a retrieval-based system is architected if the project is better served by retrieval-augmented generation over a secured, access-controlled data store instead of training on de-identified data at all. In many cases, retrieval against properly access-controlled PHI, rather than de-identifying data for training, is the simpler and safer path, and it is worth evaluating both options before committing engineering time to a de-identification pipeline.
Frequently Asked Questions
Does removing names and dates automatically make data safe to use for AI training?
Not by itself. Safe Harbor requires removing all 18 specified categories of identifiers, not just names and dates, and it also requires that the entity have no actual knowledge that the remaining data could still identify someone. Partial scrubbing does not meet the standard.
Can we use a vendor's AI tool on patient data without a business associate agreement if we remove the obvious identifiers first?
Only if the data genuinely meets the Safe Harbor or Expert Determination standard before it leaves your environment. If any protected health information reaches the vendor, a signed business associate agreement is required regardless of how much scrubbing was attempted. This is a compliance question that depends on your specific architecture and should be reviewed with qualified legal counsel.
Is synthetic data generated by an AI model automatically exempt from HIPAA?
No. If synthetic data is generated from real patient records and is specific enough that it could be traced back to an individual, it is treated the same as the source data for de-identification purposes. The output has to independently meet the Safe Harbor or Expert Determination standard.
Who is qualified to perform an Expert Determination?
HIPAA does not name specific credentials, but the regulation requires a person with appropriate knowledge of and experience with generally accepted statistical and scientific principles and methods for rendering information not individually identifiable. In practice this is typically a biostatistician or a privacy risk specialist with documented experience in re-identification risk analysis.
This article explains the de-identification standard as a technical and architectural concern for software teams. It is not legal advice. Whether a specific dataset, pipeline, or vendor relationship satisfies HIPAA depends on your organization's full set of facts, and should be confirmed with qualified legal counsel before data is used for AI training or shared with a third party.
If your team is weighing whether to de-identify data for model training, adopt retrieval over a secured data store, or redesign a pipeline that currently sends PHI to a third-party AI tool without the right agreements in place, our team can help you work through the architecture and the tradeoffs. Book a strategy call or learn more about our approach to healthcare AI development.