The problem
Clinical notes are useful to an AI model and dangerous to send to one. Rules handle structured fields well: a name, a birth date, a health-card number. Free text defeats them. “She still sees Dr. Halloran, and her sister Mei drives her” holds two identifiers that no field list or regular expression will catch, because what makes “Mei” an identifier is the words around it. Finding them is a language problem, so a language model is the right tool for the search. It is the wrong tool to trust with the result.
What it does
Sovereign removes identifiers on my own server so an outside model can work with a note without seeing who it is about.
The summary path is reversible: known identifiers become tags such as [PATIENT_NAME_ab12cd], the tagged text goes out for a summary, and the summary is re-identified locally from an encrypted map.
The release path is for text that leaves for good, so nothing is kept that could reverse it. Rules replace everything they know. The model reads the tagged text and returns only a list of substrings it thinks are leftover identifiers, each with a category. It never writes the document. Code applies the redactions, and a final gate refuses the release if anything identifier-shaped survives.
Underneath is a batch engine for structured patient records, built around the Ontario privacy commissioner’s 2025 de-identification guidelines: identifiers removed or hashed with a secret salt, dates shifted per patient, age and region generalised until every group of look-alike records is big enough. On 1,473 synthetic records the smallest group held 94 and the estimated re-identification risk was 0.053%.
How it’s built
The web app is FastAPI with mandatory two-factor login, server-side roles, encrypted re-identification maps and an audit log that records categories, never matched text. Everything bound for the model passes an outbound gate that looks for the document’s own known identifiers and for identifier-shaped patterns. A hit stops the call.
The batch engine is standard-library Python under two Unix accounts. My coding agent works in one and never sees the other, which owns the sealed area for real records and the hashing salt. The only bridge is one approved admin command that takes no arguments, so there is nothing to inject.
Everything has run on synthetic data only.
Decisions
- The model points and code cuts. A model that finds and fixes the problem has to be trusted with the output, and a model that only points can be checked.
- The model’s vocabulary is closed. Seven categories are allowed and anything else is dropped, because an open vocabulary would let it invent a reason to redact, or keep, any text.
- A span longer than 120 characters is rejected. A span that long means the model has started summarising instead of pointing.
- Unknown fields are dropped by default. A list of known-bad fields leaks on the next unfamiliar one, which is what happened below.
How it broke, and what changed
It broke twice, both times where an identifier turned up in a form the code didn’t expect.
In June the released output was called leak-free after a check for a fixed list of fields: name, birth date, postal code, city, coordinates. In July an audit ran the pipeline on fresh synthetic records and found each record’s mother’s maiden name and birthplace passing straight through, in a part of the record (FHIR extensions) the code never read. The fix inverted the rule: every extension is dropped unless it is on an allowlist, and the allowlist is empty. It was checked by running the pipeline over 30 records and inspecting the output.
In August a realistic assessment note, written as a test document, leaked on its first run. The stored identifier was the fictional patient’s full name, replacement matched whole strings, and the note used the first name on its own throughout. No gate pattern matches a bare first name, so it reached the outside model in the clear. Name fields now add their first-name and surname parts to the map, with guards: parts of four letters or more, whole words only, so a surname like Fisher can’t rewrite “Fisherman”.
What’s still rough
- It has never processed a real record and isn’t ready to. The web app has no login rate limiting, and a used two-factor code stays valid until its time window rolls over.
- The web app’s encryption key sits under the same account the app runs as. The two-account separation covers the batch engine only.
- The group-size floor and risk threshold are fixed numbers. The guidelines tie them to how sensitive the data is, and clinical psychology records would plausibly fall in a stricter tier.