PHI de-identification at the pipeline level — why sequence matters and where most architectures fail

De-identification is usually discussed as a capability — a named-entity model that finds names, dates, medical record numbers, and geographic identifiers, scoring well against a benchmark corpus. That framing hides the decision that actually determines whether an architecture is defensible: where in the pipeline that capability runs. A de-identifier with excellent recall placed after the extraction step protects nothing, because by the time it executes the raw document has already crossed the boundary it was supposed to guard.

The control is ordinal. Document text must be scrubbed before it enters any model context window, before it is written to any queue or cache used by inference, and before any request leaves the trust boundary of the processing environment. Every subsequent stage — extraction, assertion classification, ontology traversal, code assembly — should operate exclusively on the surrogate-bearing version of the text.

This is why de-identification belongs in the same architectural conversation as the model, rather than being treated as a preprocessing detail. It is not a filter applied to output; it is the first stage of the pipeline, and its position is the property auditors and security reviewers should be examining.

HIPAA's Safe Harbor method enumerates eighteen identifier categories that must be removed for a data set to be considered de-identified. The straightforward ones — patient name, address, telephone number, email, social security number, medical record number, health plan beneficiary number, account number — are handled well by any competent recogniser because they have strong surface form or predictable context.

The categories that break systems in production are the ones that look like clinical content. Dates are the largest problem: all elements of dates except year must be removed, and clinical notes are dense with dates that carry medical meaning. A note may reference the date of surgery, the date of onset, the date of a prior imaging study, and the date of the current encounter within a single paragraph. Removing them naively destroys the temporal reasoning that assertion status and encounter-type determination depend on.

The remaining hard categories are free-text leakage cases: names appearing inside a narrative rather than in a header, provider names that are also common words, facility names embedded in transfer descriptions, and the catch-all eighteenth category covering any other unique identifying number, characteristic, or code. Rare-disease descriptions, unusual occupations, and small-geography references can be identifying in combination even when no single element is. A system that reports one aggregate recall figure across all eighteen categories is concealing the performance on exactly the categories where it is weakest.

Replacing identifiers with a fixed marker such as [REDACTED] is the simplest approach and the most damaging to downstream accuracy. It removes the structural cues models rely on. A note where every date has become a bracketed token no longer supports the initial-versus-subsequent encounter determination that seventh-character ICD-10 specificity requires, and a note where every name is an identical marker loses the ability to distinguish the patient from a family member — which is the subject axis that assertion classification needs.

Surrogate generation preserves the shape of the data while removing the identity. A date becomes a different but plausible date, shifted consistently for the whole record so that intervals between events are preserved even though absolute dates are not. A name becomes a different name of the same apparent gender, used consistently within the document so that coreference still resolves. An age above eighty-nine, which Safe Harbor requires be aggregated, becomes a category rather than a number.

The consistency requirement is what makes this non-trivial. Surrogates have to be stable within a record and unpredictable across records. Stable within a record so that three mentions of the same date resolve to the same surrogate; unpredictable across records so that the surrogate mapping is not itself a re-identification vector. That means the surrogate function is keyed, and the key is a secret with the same handling requirements as the re-identification map itself.

Coding output has to be re-attached to a real encounter, a real patient, and a real claim, so de-identification in this setting is necessarily reversible. That reversibility is the part of the design that deserves the most scrutiny, because a re-identification map is a compact, high-value artefact: it maps surrogate to true identifier for every record processed.

The map must live outside the model path. It should be written by the de-identification stage, read by the final re-attachment stage, and be unreachable from anything in between. Extraction, inference, prompt logging, and any vendor-side observability tooling should have no credential that can read it. Where a third-party model provider is in the path, the map should not exist in that provider's environment at all.

Encryption at rest is table stakes. The controls that matter more are access scoping and audit: which service identities can read the map, whether reads are logged with the requesting identity and record, and whether the map has a retention limit tied to the claim lifecycle rather than being kept indefinitely. A map retained forever converts a de-identified corpus back into a fully identified one at any point in the future.

Most PHI exposure in AI pipelines is not caused by the primary data path. It is caused by the secondary paths that exist for operational reasons and were never included in the threat model. Application logs that record request payloads for debugging. Error handlers that attach the offending document to a stack trace. Prompt-and-completion logging enabled by default in an inference provider's dashboard. Response caches keyed on document content. Queue systems with message retention. Model providers that retain inputs for abuse monitoring or future training.

Each of these is a place where raw text can come to rest outside the intended boundary, and each is invisible in an architecture diagram that shows only the happy path. The audit question is not what the pipeline does but what every component in the pipeline persists, for how long, and who can read it.

Retention on the inference provider side deserves specific attention. A zero-retention configuration is a contractual and technical requirement, not a preference, and it should be verified rather than assumed — including for the abuse-monitoring pathway, which is frequently exempted from the standard retention promise in default terms.

Ask for the pipeline sequence as an ordered list of stages, and ask which stage first sees document text and which stage first sees scrubbed text. If those are the same stage, or if the answer is unclear, the sequencing control does not exist.

Ask for per-category de-identification recall — dates, names in narrative, provider names, facility names, and the catch-all category reported separately — measured on the vendor's own production document mix rather than on a public benchmark corpus that is cleaner than real dictation.

Ask who holds the re-identification map, what identities can read it, whether reads are audited, and when entries are deleted. Ask what is logged at every hop and what the retention period is for each log. Ask whether any model provider in the path retains inputs, including for abuse monitoring. A vendor that can answer these six questions precisely has thought about the problem architecturally; one that answers by citing a de-identification accuracy number has not.