PHI Redaction at Inference: HIPAA-Safe LLM Patterns

The instinct is sensible: if you never send PHI to a model, you never need a BAA. Redact the identifiers, send the rest, and the compliance problem disappears.

It is a legitimate strategy. It is also harder than it looks, and it has one specific trap worth understanding before you build on it.

The two legal routes

HIPAA provides exactly two ways to render health information non-identifiable. Both live in 45 CFR 164.514.

Safe Harbor requires removing all of a specific list of 18 identifiers, and adds a condition: 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."

Expert Determination requires a person with "appropriate knowledge of and experience with generally accepted statistical and scientific principles" to determine that "the risk is very small" that the information could be used to identify an individual, and to document the methods and results.

Get either right, and HHS is explicit about the consequence: de-identified health information "is no longer considered protected health information." The Privacy Rule does not restrict its use or disclosure.

The 18 Safe Harbor identifiers

These are the categories that must be removed. The list is long, and the entries that matter most for AI workloads are the dates.

Two of these have detail that catches implementations out. ZIP codes may be kept only as the initial three digits, and only where that three-digit area contains more than 20,000 people; otherwise the prefix becomes 000. Ages over 89 must be aggregated into a single "90 or older" category, including any dates that would reveal such an age.

The trap: redaction removes clinical signal

Here is the part that surprises engineering teams.

The identifiers are not all noise. Item C - dates - carries most of the clinical meaning in a longitudinal record. Remove admission dates and discharge dates and you cannot reason about length of stay, readmission windows, disease progression, or medication response. Item B removes the geography that anchors social determinants of health.

A fully redacted record is compliant and often clinically inert. Teams discover this after they have built the pipeline, which is an expensive moment.

Why this bites harder with LLMs than with analytics

Traditional de-identification was designed for datasets analyzed in aggregate, where losing a date shifts a distribution slightly and nobody notices. An LLM performs per-record reasoning. Remove the dates and the model loses the ability to reason about progression - and it will often produce confident, plausible output rather than reporting that the information is missing. That failure mode is worse in a clinical setting than an obvious error, because it is harder to catch.

Patterns that work

Four approaches, roughly in order of effort:

• Redact only what the task needs. A coding-suggestion model may need diagnoses and procedures but not names, MRNs, or addresses. Scope the redaction to the minimum identifier set the task actually requires, rather than applying the full 18 uniformly.
• Shift dates instead of deleting them. Date shifting preserves intervals while removing absolute dates - a common de-identification technique in research datasets, and one that maps naturally onto Expert Determination rather than Safe Harbor, because it is a documented, justified method.
• Tokenize and re-link at the boundary. Replace direct identifiers with opaque tokens, keep the mapping inside your own environment, and never send the mapping. Note that the re-identification code itself is regulated: the regulation treats disclosure of a code designed to re-identify data as a disclosure of PHI.
• Keep the BAA and skip redaction. For clinical workloads, a signed BAA with zero-retention inference is often simpler than a redaction pipeline that has to be maintained, tested, and re-validated every time the model or the task changes.

Two caveats that do not go away

Residual risk is never zero. HHS states it directly: both methods, "even when properly applied, yield de-identified data that retains some risk of identification. Although the risk is very small, it is not zero."

Re-identification undoes the exemption. If you successfully identify the subject of de-identified information you maintain, "the health information now related to a specific individual would again be protected by the Privacy Rule." De-identification is not a permanent state; it is a property of a particular dataset at a particular moment.

The checklist

Before you build a redaction pipeline, answer these:

• Which identifiers does this specific task actually require, and which can be removed without losing the signal?
• Are you claiming Safe Harbor or Expert Determination? They have different evidentiary burdens, and Safe Harbor is the stricter one on dates.
• Who signs off on the method, and is the analysis documented?
• What happens when the task changes - does the redaction scope get re-reviewed?
• If de-identified data is combined with other datasets, does the re-identification risk change?

If the answers are uncomfortable, that is a signal that a BAA is the simpler path. The HIPAA compliance guide covers what the agreement requires, and Zero Data Retention covers the retention posture that pairs with it.

OpenMed Router provides zero-retention isolated inference under a signed BAA across the open-weight model catalog - so redaction stays an option rather than a requirement.

Deciding between redaction and a BAA? Join the waitlist.