Pre-authorisation, without the patient leaving the hospital

A hospital’s insurance desk writes cashless pre-authorisation requests all day. Patient identity, policy details, diagnosis, proposed line of treatment, and a justification in prose. It is precisely the work a language model is good at, and precisely the text a hospital cannot send anywhere.

So it is typed by hand. Not because nobody thought of automating it — because somebody did, and the compliance officer said no.

Two people who are both right

Most governance products resolve this by siding with the first person: block the tool, publish the policy, and the desk carries on by hand. That is a decision dressed as a control. The disagreement is not actually about whether AI should help — it is about whether the patient has to be in the request.

They do not

The request leaves the practice management system with the patient in it and reaches the model without. In order:

• The draft request is composed as it is today, from the hospital information system, with real identifiers.
• Before anything crosses the network boundary, each identifier is replaced with a stable placeholder. The mapping is written to the hospital’s own database and never leaves it.
• The model receives only the anonymised text, and drafts the letter from it. It has the diagnosis, the treatment, the clinical reasoning — everything it needs to write well, and nothing that identifies anybody.
• On the way back, the placeholders are restored from the local mapping, so what the coordinator sees is a complete letter.
• The treating clinician reviews and signs it. That step does not move.

The placeholder has to be stable, or none of this works

If a patient becomes a different token on every request, the drafted letter is incoherent by the second paragraph and the coordinator goes back to pasting the real record in. Ours does not change: the same patient reads as the same reference across the letter, across next week’s letter, and at the next desk — shared within the department so two people on one case see the same thing.

Across departments the references are derived separately, so one department cannot establish that a patient it holds also appears in another’s records. And there is no lookup: the sealed value is never read back, because a model asked to list two hundred placeholders would otherwise turn any lookup into an extraction tool aimed at the records we had just protected.

The part the auditor asks about

A hospital that adopts this will eventually be asked three questions, and only three: what left, when, and can you prove that record has not been edited since.

A policy document answers none of them. Neither does a proxy log that the hospital’s own administrator can modify. Every request here is written to an append-only, hash-chained record, with database triggers that refuse updates and deletions — built so that we cannot edit it either, which is the only version of that claim worth anything.

What we detect, and what we do not

The honest inventory, because this is where a hospital should test us rather than believe us.

• Detected today: Aadhaar, PAN, patient name, address, mobile, email, bank account, card, IFSC and credentials. In Latin script, in nine Indian numeral scripts, and — for names and addresses — in Tamil, Hindi and Telugu, script or romanised. That last part matters more than it sounds: an Aadhaar in Tamil numerals passes straight through a filter built abroad.
• Not detected yet: the ABHA number and ABHA address, hospital UHID and MRD numbers, TPA member and policy numbers, and medical council registration numbers. These are exactly the identifiers that make a record medical, and they are the next detectors we are building — not ones we can claim today.

Where it runs

Inside your own cloud tenant or your own datacentre, with a separate database per customer, and with the option of routing to an India-hosted or on-premises model so that no patient text crosses a border at all. The last one is a capability rather than a deployment we can point you at.

And to be explicit, because a healthcare buyer will ask and should: we hold no ISO 27001 and no SOC 2 today. A gap assessment is work in progress. We would rather you heard that from us on a blog than find it in a questionnaire.

What actually changes

Not the clinician’s signature, and not the compliance officer’s position. What changes is that the question moves from should we let AI near patient records — where the answer is reasonably no — to what has to be in the request, where the answer turns out to be: not the patient.