LLM De-Identification of Clinical Notes for Hospital Research

How the HIPAA standard applies when an LLM does the work

Health information that does not identify an individual, and for which there is no reasonable basis to believe it can identify an individual, is not individually identifiable health information. A covered entity may reach that conclusion only by meeting the implementation specifications in 45 CFR 164.514(b). HHS describes two methods. The first is a formal determination by a qualified expert (164.514(b)(1)). The second is removal of specified individual identifiers, combined with no actual knowledge by the covered entity that the remaining information could identify an individual alone or in combination with other information (164.514(b)(2)).

Neither method is defined by the tool used. An LLM is one way to perform identifier removal or to produce a candidate de-identified set. It does not decide whether the standard is met. Under the identifier-removal method, the hospital still needs to show that the specified identifiers are gone and that it has no actual knowledge of residual identifiability. Under Expert Determination, the qualified expert has to be able to assess the actual pipeline and its measured performance, not a vendor description of it.

Both HHS and NIST are clear that properly applied methods still leave some risk of re-identification. NIST SP 800-188 adds that tools which merely mask personal information may not provide enough functionality for de-identification, and that practitioners generally use special-purpose software to calculate likely re-identification risk. For a research office, this means choosing and documenting the pathway for each use case, and not treating model output as de-identified by default.

Where LLM de-identification fails

Free-text notes contain direct identifiers such as medical record numbers and indirect identifiers such as zip codes, in inconsistent formats. Abbreviations, misspellings, dictation artifacts and names that resemble ordinary words all complicate detection. The failure modes below follow from how generative models work, and each one needs its own test.

Missed identifiers are the most consequential failure, because a single surviving identifier can defeat the purpose of the release. Recall should be measured per identifier category, not as one aggregate score, since a high overall figure can hide weak performance on a rare category. Published results for any given model do not transfer automatically to your notes, so measure on a sample that reflects your specialties, note types and templates.

Altered content is a second risk. A generative model asked to rewrite a note can change clinical meaning, drop or invent details, or replace an identifier with something that still carries information. That harms research validity and can introduce new quasi-identifiers. Constraining the task to span detection and substitution, instead of free rewriting, reduces the surface for this.

Run-to-run variability is the third. The same note can yield different output across runs, so a single validation pass does not establish stable behavior. Repeat runs on the same sample and track disagreement as a metric.

The fourth failure is of a different kind: the model itself receives raw PHI during processing. That exposure is a property of the architecture and the control layer, not of model accuracy.

Runtime policy enforcement and audit-ready evidence

Model-level de-identification answers whether identifiers were removed. It does not answer what PHI the model was allowed to receive and emit, or who can show that later. Those are control questions, and they are best handled by enforcement at runtime, not by review after the fact. The literature on medical LLMs describes real-time auditing of prompts and outputs, using PII classifiers and drift detection, as one approach to preventing leakage across contexts. It is a described approach, so validate any such control in your own environment.

Trussed enforces policy in the execution path for each interaction and tool call, with allow, redact and block outcomes. For a de-identification pipeline, that means a request carrying PHI to an unapproved model or tool can be blocked, PHI that should not reach a downstream step can be redacted, and model output that still contains identifier patterns can be stopped before it is written to the research store. Trussed can be deployed self-managed in the customer cloud, with configurable retention and data residency, and it runs in production with healthcare and pharma organizations.

Enforcement also produces evidence. Each decision generates audit-ready evidence that is mapped to HIPAA, including 164.312(b) audit controls, so the research office can show what the pipeline was permitted to do and what it did. This is a separate layer from model accuracy. It does not make a note de-identified, and it does not replace the pathway determination or the validation work. It makes the process around the model enforceable and demonstrable.

Criteria for evaluating tooling

Whether the tool is a model, a pipeline or a control layer, ask the same practical questions and require evidence, not assertions.

• Masking or risk measurement: Does it only mask strings, or does it also support risk measurement and re-identification studies?
• Measured recall: Can the vendor show recall by identifier category on clinical notes like yours, including run-to-run consistency?
• PHI location: Where is PHI processed and retained, does any of it leave your environment, and is a BAA in place where one applies?
• Runtime control: Can prompts and outputs be inspected and allowed, redacted or blocked at runtime?
• Exportable evidence: Can decision records be exported in a form the research office and auditors can use?
• Key handling: How are re-identification codes generated, stored and kept apart from released data?