Saravonixயாமிருக்க பயமேன்
Saravonix writing

The discharge summary was written in Tamil

An Aadhaar number in Tamil numerals passes straight through a PII filter built abroad. The numbers get masked; the patient’s name walks out of the hospital.

Karthik Balasundaram, 14 September 2026. About 8 minutes.


A discharge summary from a hospital in Madurai. The patient’s name is in Tamil script. The address is in Tamil script. The nursing notes are half English and half Tamil, typed on an English keyboard because that is the keyboard on the desk.

Send that to an anonymisation engine built for California or the Gulf and watch which half survives. The numbers get masked. The patient’s name walks out of the hospital.

We have not deployed this in a hospital. Everything below is a worked example from our own test suite, run against real Indian record formats. No customer, no case study, and no claim about how much time anybody saved — we do not have that number and will not borrow somebody else’s.

The number that gets through

Here is an Aadhaar number as it appears in a record typed by somebody working in Tamil:

ஆதார் ௯௯௯௯ ௪௧௦௫ ௭௦௫௮
Twelve digits. A valid Verhoeff checksum. Written in Tamil numerals, so an ASCII digit class never matches and the detector never fires.

And the same identifier out of a Hindi email, in Devanagari numerals:

आधार ९९९९ ४१०५ ७०५८
Same problem, different script. Both are Aadhaar numbers. Neither looks like one to a regular expression.

This is not a defect in anybody’s product. Personal-data detection is built from regular expressions and name recognition trained on English text, and both of those are bound to the script they were written for. Nobody ever asked them about Tamil, because the people who wrote them were not reading Tamil records.

Names were harder than numbers

A number has a shape. Normalise the digits, run the checksum, and you either have an Aadhaar or you do not. Names have grammar.

In Tamil, the honorific that marks a name inflects with the case ending, and the ending replaces the final puḷḷi rather than following it — so the base word is not even a prefix of the inflected form:

அவர்கள்  ·  அவர்களின்  ·  அவர்களுக்கு
Three forms of the same honorific. A prefix match on the first finds neither of the others.

There is no pattern to match your way out of that. It has to be modelled, and to model it somebody has to know the language.

Then there is how people actually type

Most Indian office text is neither the native script nor English. It is romanised, mixed, and written at speed. This is a real sentence from a collections workflow rather than a medical one, but the grammar is identical to a nursing note:

Ramesh oda account 3512045678 la EMI due iruku
The account number is caught by anything. The customer’s name is caught by nothing built outside India — “oda” and “la” are in no English model’s vocabulary.

The same shape appears with Telugu (Suresh garu), with Hindi (Ramesh ji), and with Tamil honorifics written in Latin letters (Priya avargal). Each one is a name sitting next to a marker that a detector has to recognise as a marker.

What we detect, exactly

This is the part to read twice, because it is the part a hospital will test.

  • Numerals in nine Indian scripts — Devanagari, Bengali, Gurmukhi, Gujarati, Odia, Tamil, Telugu, Kannada and Malayalam — normalised before the Aadhaar and card checksums run.
  • Names and addresses in Tamil, Hindi and Telugu, in native script and romanised, including the honorifics and case endings above.
  • Aadhaar, PAN, mobile, email, bank account, card, IFSC and credentials, in any of those scripts.
And what we do not detect yet. No ABHA number, no ABHA address, no hospital UHID or MRD number, no TPA member or policy number, no medical council registration. Those are the identifiers that make a record specifically medical, and they are the next detectors we are building rather than ones we can claim. If you are reading this because you hold those formats, we would like your sample files.

Names and addresses cover three languages today. India has twenty-two scheduled ones. We would rather say “three, and here is the plan” than “Indian languages” and let a hospital discover the difference during a pilot.

Precision matters as much as coverage

It is easy to catch every Aadhaar if you are willing to mask every twelve-digit number. That tool gets uninstalled by Friday, because a medical record is full of numbers that are not identifiers — dosages, readings, bed numbers, dates.

So the checksum does real work. A twelve-digit run in Tamil numerals that fails the Verhoeff check is left alone, exactly as it would be in ASCII. The normalisation happens before validation rather than instead of it.

Hospital recordname, Aadhaar, addressdetect · mask · loginside your networkModelsees [NAME·7] onlyplaceholders restored, clinician signsmapping table stays in the hospital’s own database
The mapping never leaves the hospital. The model receives placeholders; the reply is restored on the way back, and the treating clinician reviews and signs whatever was drafted.

Why the placeholder has to be stable

The standard objection to masking is that it ruins the output, and for most tools it is a fair one. Replace a name with a fresh token on every request and by the third exchange nobody can tell which patient the model is discussing. The clinician goes back to pasting the real record in, which is the outcome the tool existed to prevent.

So ours does not change. The same patient reads as the same reference in the next paragraph, in next week’s letter, and at the colleague’s desk — shared across the department, so two people working one file see the same thing. Across departments the references are derived separately, which means one department cannot establish that a patient it holds also appears in another’s records.

One thing we deliberately did not build: there is no way to look up what a placeholder meant. The value is sealed and never read back. A model will happily list two hundred placeholders when asked, and any lookup would turn that into an extraction tool pointed at the records we had just protected.

What this has to do with the law

The Digital Personal Data Protection Act does not care which script personal data was written in when it left the country. A hospital is the fiduciary either way, and the obligation is the hospital’s, not ours — what a tool can do is help evidence what was shared and what was not.

Which is the other half of this. Every request is written to an append-only, hash-chained record with database-level protection that refuses modification and deletion, so when somebody asks what left and when, that is a query rather than a conversation. We built it so that we cannot edit it either, which is the only version of that claim worth anything.

To be explicit about what we do not have: no ISO 27001 and no SOC 2. A gap assessment is work in progress. What exists today is deployment inside your own tenant or datacentre, a separate database per customer, and the option of routing to an India-hosted or on-premises model so that no patient text crosses a border at all. That last one is a capability, not a running deployment we can point you at.

The argument

Indian medical records are not English records with Indian names in them. They are Indian documents — written in Tamil, in Devanagari, in romanised shorthand, by people working at speed in two languages at once.

You cannot localise your way to reading them. It is not a translation layer on top of a product built somewhere else; it is the hardest part of the product, and it gets built by people who live where the records are written.

Detection is half the problem. The other half is the process it sits inside — who signs, what the auditor is shown, and which identifiers a letter actually carries. That is the pre-authorisation workflow, taken apart step by step.