Two methods, and only two
Most teams start in the wrong place. They ask whether a dataset is de-identified as if that were a property you could inspect, like a checksum. HIPAA does not work that way. The Privacy Rule sets a standard at 45 CFR 164.514(a) — health information "that does not identify an individual and with respect to which there is no reasonable basis to believe that the information can be used to identify an individual is not individually identifiable health information" — and then, at 164.514(b), names exactly two ways a covered entity may conclude the standard has been met. There is no third way. A pipeline that strips columns because they looked sensitive has not de-identified anything; it has made an undocumented guess.
The first method is expert determination. A person with appropriate knowledge of and experience with generally accepted statistical and scientific principles 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 — and documents the methods and results of the analysis. Both halves are required. A conclusion without a written analysis does not satisfy 164.514(b)(1).
The second method is Safe Harbor. Remove eighteen enumerated categories of identifiers, at 164.514(b)(2)(i)(A) through (R), for the individual and for that individual's relatives, employers, and household members. Then satisfy a second condition teams routinely skip: the covered entity must not have "actual knowledge that the information could be used alone or in combination with other information to identify an individual who is a subject of the information."
Why this matters commercially, not just legally: data that clears either method leaves the Privacy Rule entirely. Section 164.502(d)(2) says the requirements of the subpart "do not apply" to information de-identified in accordance with 164.514, and the Office for Civil Rights states plainly in its standing guidance that the Rule does not restrict the use or disclosure of de-identified health information. That is the whole prize, and why the determination has to be defensible rather than convenient.
What Safe Harbor costs a model
Safe Harbor is attractive because it is mechanical. You can hand the list to an engineer. The problem is that three items on the list carry most of the signal in clinical modeling.
Dates. All elements of dates except the year must go, for any date directly related to an individual — birth, admission, discharge, death. Anything downstream that depends on intervals, sequence, or seasonality is damaged. Length of stay, time-to-event, readmission windows, medication timing, and lab trajectories all live in the part of the field Safe Harbor deletes.
Age. All ages over 89, and all date elements indicating such an age, must be aggregated into a single category of 90 or older. For any model that touches geriatric outcomes, that is a ceiling on the most consequential part of the distribution.
Geography. Every geographic subdivision smaller than a state goes, with one narrow exception: the initial three digits of a ZIP code may remain if the unit formed by combining all ZIP codes with those three digits contains more than 20,000 people, and the prefix of any unit at or below 20,000 must be changed to 000. A published list of seventeen restricted three-digit prefixes exists, and there is a trap in it. OCR derived that list from 2000 Census data and says in the same breath that entities "should not, however, rely upon this listing or the one found in the August 14, 2002 regulation if more current data has been published." A validator that hard-codes those seventeen values has inherited a demographic snapshot from a quarter century ago.
The remaining fifteen categories are mostly cheap to remove and rarely carry modeling signal — names, phone and fax numbers, email, Social Security numbers, medical record and beneficiary numbers, account, certificate and license numbers, vehicle and device identifiers, URLs, IP addresses, biometrics, full-face images, and the catch-all "any other unique identifying number, characteristic, or code." The catch-all is the exception, and it is where careless feature engineering gets caught. A synthetic patient key derived from a medical record number is a code. A high-cardinality provider-plus-visit hash that resolves to one person is a characteristic.

Free text is not a separate problem, and the rule says so
Structured columns are the easy half. The hard half is the note. OCR is unambiguous here: "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." A discharge summary is subject to the same eighteen categories as a billing table.
OCR goes further, and this sentence should govern how a team scopes the work: "Clinical narratives in which a physician documents the history and/or lifestyle of a patient are information rich and may provide context that readily allows for patient identification." That is the actual-knowledge provision reaching into prose. OCR's own worked example is a record listing a patient's occupation as "former president of the State University" — no listed identifier appears, and the record is still not de-identified.
Automated clinical de-identification is a real research field with a real benchmark. The 2014 i2b2/UTHealth shared task, documented by Stubbs, Kotfila and Uzuner in the Journal of Biomedical Informatics, built a corpus of longitudinal clinical narratives annotated for PHI and evaluated automated systems against it. The companion corpus paper by Stubbs and Uzuner describes replacing real identifiers with realistic surrogates rather than blanks — the right instinct, because a note full of [REDACTED] tokens teaches a downstream model that redaction markers predict outcomes.
Two cautions. Scores on a benchmark corpus are scores on that corpus; note conventions, templates and specialty vocabulary shift across institutions and across service lines within one institution, so assume a de-identification model degrades off its training distribution until you have measured it. And recall below one is not a rounding error here — it is a count of identifiers that survived into what someone is about to call de-identified data.
Expert determination is the method that keeps the dates
If the model needs intervals, ages above 89, or geography finer than a three-digit ZIP prefix, Safe Harbor is the wrong instrument and expert determination is the conversation to have. Four things about it are commonly misunderstood.
There is no numeric threshold. OCR states there is no explicit numerical level of identification risk deemed to universally meet the "very small" standard. Anyone who tells you the number is a fixed percentage is describing their own house methodology, not the rule.
The risk is assessed against an anticipated recipient. The determination is relative to who receives the data and what else that recipient can reasonably reach. The same table can be a clean determination for one recipient and an unacceptable one for another. Change the recipient and the analysis changes with it.
Determinations age. The Privacy Rule does not require an expiration date, but OCR notes that practitioners commonly use time-limited certifications because computational capability and the availability of linkable outside data both change. OCR also warns that where an expert produces multiple tailored releases from one source dataset, the releases must not be combinable in a way that defeats the mitigation.
There is no certification body. OCR says there is no specific professional degree or certification program for this role, and that it would review the expert's professional experience, training, and actual experience using de-identification methodologies. That cuts both ways: a statistician with a real track record qualifies, and a vendor badge does not.
The third door people forget: the limited data set
Between "full PHI under a business associate agreement" and "de-identified and out of scope" sits an option that fits a large share of clinical modeling work, and gets overlooked because it does not have the word de-identification in it. Section 164.514(e) defines a limited data set: protected health information stripped of sixteen listed direct identifiers. Compare that list against Safe Harbor's eighteen and the difference is the whole point — a limited data set may retain dates and may retain town or city, state, and ZIP code.
The trade is that a limited data set is still PHI. It stays inside the Privacy Rule. It may be used or disclosed only for research, public health, or health care operations, and only under a data use agreement meeting 164.514(e)(4), which must establish permitted uses, name who may use or receive the data, and bind the recipient not to re-identify or contact individuals. For a team that needs longitudinal structure and can live inside a contract, this is frequently the correct answer and it is faster to reach than a defensible expert determination.
| Pathway | Citation | Dates and geography | Still PHI? | What it requires of you |
|---|---|---|---|---|
| Safe Harbor | 164.514(b)(2) | Year only; ages 90+ collapsed; three-digit ZIP with the 20,000-population test | No | Remove all 18 categories everywhere, including free text, and hold no actual knowledge of residual identifiability |
| Expert determination | 164.514(b)(1) | Negotiable — whatever the documented analysis supports for the anticipated recipient | No | A qualified expert, a written analysis of methods and results, and a recipient-specific scope |
| Limited data set | 164.514(e) | Full dates retained; town or city, state and ZIP retained | Yes | Remove 16 direct identifiers, execute a data use agreement, and stay within research, public health, or health care operations |
| Full PHI as a business associate | 164.502(e), 164.504(e) | Everything | Yes | A signed BAA, the full Security Rule, breach notification duties, and the minimum necessary standard at 164.514(d) |
| Research use of PHI | 164.512(i) | Everything | Yes | Individual authorization, or documented IRB or privacy board approval of a waiver or alteration, with the waiver criteria on the record |
If you build on someone else's PHI, you are probably a business associate
Under 45 CFR 160.103, a business associate is a person who, on behalf of a covered entity and outside its workforce, "creates, receives, maintains, or transmits protected health information" for a regulated function or activity — with data analysis named in the definition. An analytics vendor training on a hospital's records is squarely inside that text. The definition also reaches down: a subcontractor that creates, receives, maintains or transmits PHI on behalf of a business associate is itself a business associate. Your cloud tenancy, your labeling vendor and your annotation contractor do not sit outside the chain because they sit behind you in it.
Two consequences follow that teams learn late. First, a covered entity may use a business associate to de-identify PHI on its behalf only to the extent that activity is authorized by the business associate agreement — that is OCR's language. If the BAA does not name de-identification, the vendor performing it is operating outside the agreement, and the resulting dataset has a defect at its root. Read the agreement before the first extract, not after the first model.
Second, 164.502(a)(5)(ii) prohibits the sale of PHI without an authorization meeting 164.508(a)(4), where "sale" means any disclosure for direct or indirect remuneration in exchange for the information. The exceptions are narrow. Research and public health disclosures are excepted only where the remuneration is a reasonable cost-based fee to prepare and transmit the data; disclosures to a business associate are excepted where the only remuneration flows from the covered entity to the business associate for performing the activity. Data-for-equity and data-for-license arrangements are exactly the structures this provision was written about.
The model artifact is in scope, and HHS has said so in writing
Here is the question that decides how a team stores checkpoints, and the one most often waved off: if a model was trained on ePHI, is the model itself regulated?
HHS answered it directly in the January 6, 2025 notice of proposed rulemaking on the Security Rule. Responding to a recommendation from the National Committee on Vital and Health Statistics that the Department clarify how the HIPAA Rules apply to AI, the Department wrote: "ePHI, including ePHI in AI training data, prediction models, and algorithm data that is maintained by a regulated entity for covered functions is protected by the HIPAA Rules and all applicable standards and specifications." The Department cited generative systems reproducing names and personal information from their training sources, and said that similar use by a regulated entity, "including the training of AI models on patient data, could result in impermissible uses and disclosures."
A footnote in the same passage carries weight: where a regulated entity maintains ePHI for research purposes as described by 164.512(i), it is not performing a covered function. Read that carve-out closely with counsel before relying on it, because it turns on how the work is characterized. Section 164.501 defines research as a systematic investigation designed to develop or contribute to generalizable knowledge, while health care operations expressly excludes quality studies whose primary purpose is generalizable knowledge. The same modeling effort can land on either side of that line depending on why it is being done.
The technical literature supports that concern rather than softening it. Carlini and co-authors showed in Extracting Training Data from Large Language Models that an adversary querying a published model can recover verbatim training sequences, including personally identifiable information, and that larger models were more vulnerable than smaller ones. The follow-on work, Quantifying Memorization Across Neural Language Models, found memorization grows log-linearly with model capacity, with how many times an example is duplicated, and with prompt context length. Duplication is the operationally useful finding: clinical corpora are full of templated text, and duplication is one of the few memorization drivers a team controls directly, through deduplication before training.
Treat weights trained on PHI as artifacts that carry the data
If a checkpoint was trained on ePHI held for covered functions, store it, access-control it, log it and inventory it the way you treat the source data — not the way you treat build outputs. The Department's proposed technology asset inventory would expect AI software that interacts with ePHI, "including where ePHI is used to train the AI software," to appear in that inventory.
What the Security Rule requires now, and what is proposed
The Security Rule's structure surprises people arriving from other frameworks. Some implementation specifications are required and some are addressable, and addressable does not mean optional — it means the entity must assess whether the safeguard is reasonable and appropriate in its environment and, if not, document why and implement an equivalent alternative where reasonable.
Under the current rule, risk analysis at 164.308(a)(1)(ii)(A) is required: an accurate and thorough assessment of potential risks and vulnerabilities to the confidentiality, integrity and availability of ePHI. So are risk management, a sanction policy, and information system activity review. Encryption is not. Both the encryption and decryption specification at 164.312(a)(2)(iv) and the transmission encryption specification at 164.312(e)(2)(ii) are addressable today. That single fact is one of the things HHS proposed to change.
The proposed rule, published January 6, 2025 under RIN 0945-AA22, would "remove the distinction between required and addressable implementation specifications and make all implementation specifications required, with specific, limited exceptions." It would add a written technology asset inventory and a network map covering all technology assets that may affect the confidentiality, integrity or availability of ePHI; multi-factor authentication with enumerated exceptions; and written procedures to restore critical systems and data within 72 hours of loss.
Status, stated plainly, because this is in flux. The comment period closed March 7, 2025. As of this writing, RIN 0945-AA22 has produced one Federal Register document — the proposed rule. No final rule has been published. Nothing in the proposal is enforceable yet, and a final rule may differ from what was proposed. Two responses are reasonable: do not represent proposed requirements as current obligations, and do not design a new system that would be expensive to retrofit if they land. Encryption, MFA and an asset inventory are defensible engineering on their own merits regardless of the rulemaking. For teams already mapping the current rule, NIST's Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide, SP 800-66r2, published February 2024, remains the working crosswalk.
Substance use disorder records are a separate regime, and it is already in force
One category of clinical data carries its own rule, and a HIPAA-only posture misses it. Records from federally assisted substance use disorder programs fall under 42 CFR Part 2. HHS published a final rule modifying Part 2 on February 16, 2024, implementing section 3221 of the CARES Act and aligning much of Part 2 with the HIPAA Privacy Rule. It took effect April 16, 2024, with a compliance date of February 16, 2026 — which has now passed.
The consequence for a modeling team is scoping. If an extract may contain records originating from a Part 2 program, the consent and redisclosure rules are not the ones you read in Part 164 — and that question belongs to the data owner before the extract is cut, not to an engineer who finds it later in a column of diagnosis codes.
Re-identification research, and the honest tension in the rule
The most cited result here is Rocher, Hendrickx and de Montjoye in Nature Communications, July 2019. Using a generative copula-based model validated across 210 populations, they estimated that 99.98% of Americans would be correctly re-identified in any dataset using fifteen demographic attributes, and concluded that heavily sampled anonymized datasets are unlikely to satisfy modern anonymization standards.
Set that against OCR's guidance and a real tension appears, worth naming rather than smoothing over. Asked whether an entity that knows of specific re-identification studies therefore has "actual knowledge" under Safe Harbor, OCR said no: mere knowledge of such studies, by itself, does not mean the entity knows those methods would be used with the data it is disclosing, and OCR "does not expect a covered entity to presume such capacities of all potential recipients." OCR is explicit elsewhere that both methods "yield de-identified data that retains some risk of identification" — very small, not zero.
So the rule is satisfiable and the risk is real at the same time. That is the design, not a contradiction to argue away. Safe Harbor buys legal certainty with a fixed list; expert determination buys utility with a documented, recipient-specific argument. If a release goes to a broad or unknown audience, the honest reading of the research is that a fixed list does less work than its legal finality suggests — and contractual bars on re-identification, which OCR permits over de-identified data though it does not require them, are worth adding.
Where real training data actually comes from
Teams that need clinical data before they have a covered-entity relationship usually land on credentialed research corpora, and those corpora are the best public illustration of what serious de-identification looks like. MIMIC-IV, maintained by the MIT Laboratory for Computational Physiology and drawn from Beth Israel Deaconess Medical Center, covers more than 65,000 ICU admissions and more than 200,000 emergency department admissions. It is not an open download: access requires credentialed status, completion of CITI "Data or Specimens Only Research" training, and a signed data use agreement.
The transformation is documented and worth copying. Identifiers were replaced using a random cipher to produce consistent integer keys. Structured fields were filtered with lookup tables and allow lists. A free-text de-identification algorithm was applied to notes. Dates and times were shifted randomly into the future by an offset measured in days, with a single shift per subject — so intervals within one patient are preserved exactly, while patients are no longer temporally comparable to one another. That last choice is the one to steal: it concedes cross-patient calendar effects to keep the within-patient temporal structure most clinical models actually need. A specific, defensible trade, which is exactly the shape of thinking an expert determination is supposed to produce.
- Decide the pathway before the extract — Safe Harbor, expert determination, limited data set, or PHI under a BAA. It sets the schema, the storage tier and the contract.
- Read the BAA for de-identification authority — a business associate may de-identify only to the extent the agreement allows it.
- Treat notes as a first-class surface — measure identifier recall on your own institution's text, not on a published benchmark score.
- Deduplicate before training — repetition is the memorization driver you control, and clinical corpora are full of templated text.
- Inventory checkpoints as data — weights trained on ePHI belong in the asset inventory alongside the tables.
- Write down the reasoning — expert determination requires documented methods and results; every other pathway benefits from the same discipline.
Frequently asked questions
Expert determination under 45 CFR 164.514(b)(1), where a qualified person documents an analysis showing re-identification risk is very small for an anticipated recipient; and Safe Harbor under 164.514(b)(2), removing eighteen identifier categories and holding no actual knowledge that what remains is identifiable. Data clearing either method is no longer protected health information.
Not under Safe Harbor, which permits the year only for dates directly related to an individual. Two routes preserve dates: an expert determination whose documented analysis supports retaining them for the anticipated recipient, or a limited data set under 164.514(e), which may retain full dates but remains PHI and requires a data use agreement.
In its January 2025 proposed Security Rule, HHS stated that ePHI including ePHI in AI training data, prediction models and algorithm data maintained by a regulated entity for covered functions is protected by the HIPAA Rules. Memorization research shows the concern is technical as well as legal: models can emit verbatim training data, and the effect grows with capacity and with duplication in the corpus.
If it creates, receives, maintains or transmits PHI on behalf of a covered entity, yes — data analysis is named in the business associate definition at 45 CFR 160.103. Subcontractors handling PHI on the vendor's behalf are business associates too. A covered entity may have a business associate de-identify PHI on its behalf only to the extent the agreement authorizes that activity.
Today it is an addressable implementation specification at 164.312(a)(2)(iv) and 164.312(e)(2)(ii), meaning the entity must assess whether it is reasonable and appropriate and document its reasoning. The January 2025 proposed rule would remove the required-versus-addressable distinction and make implementation specifications required with limited exceptions. That proposal is not final, so current obligations still run to the existing rule.