Interactive Demonstration

Watch a patient record become un-identifiable, then watch it come back

This runs the full Health Vault pipeline in your browser on a synthetic patient. The cryptography is real: AES-256-GCM for the Identity Vault, HMAC-based TOTP for the second factor, SHA-256 for the audit chain. Nothing is sent anywhere, because there is nowhere for it to be sent. That is rather the point.

7 stages Real WebCrypto Fully client-side Synthetic data only
Source system

What arrives from the hospital information system

A discharge record for a synthetic patient. Every identifier here is invented. Edit the note if you like; the anonymisation engine in Stage 3 will process whatever you type.

Structured recordFully identified
Discharge summary · free textContains PHI
Note what makes this identifying. Not just the name and the ABHA number. The pin code, the date of birth and the sex together identify most people in a single hospital's catchment, and the narrative names a relative, a referring doctor and a hospital. Removing the name field alone would accomplish very little.
Zone 0, Archive

The immutable record of receipt

Before anything is processed, a byte-exact copy is written to object storage under a WORM lock and hashed. This is a legal record that a particular payload arrived at a particular time. It is never queried, never joined, and never read by an analyst.

archive/2026/09/16/enc_a7f3.json WORM locked No read grant
SHA-256
computing…
Size
Received
Retention
7 years (object lock, no delete grant issued)
Readers
none; ingestion service has write-only credentials
Why keep it at all? Because anonymisation is lossy and occasionally wrong. If the de-identification engine mangles a record, or a regulator asks what was actually received, the archive is the only authoritative answer. It is the thing you hope never to open.
Zone 1, Bronze

The split

Direct identifiers are extracted out of the clinical record and encrypted into a separate database on a separate host with separate credentials. What remains on the clinical side is a random integer. This is the move that everything else depends on.

Instance A · identity_vaultAES-256-GCM
empty; run the split
no join path
Instance B · lakehouseNo identity
Why subject_id is random and not a hash of the MRN. Hashing feels safe, but a hash is only one-way over an unpredictable input. Hospital MRNs are short, structured and sequential: APL/2024/08812 tells you the format. An attacker hashes every plausible MRN in the issuing range in seconds and builds a complete reverse lookup. A random integer from a look-up table has no relationship to the input at all.
Zone 2 · Silver

Anonymisation

Three transformations run here: dates are shifted, the clinical narrative is de-identified, and indirect identifiers are generalised.

1 · Date shiftingoffset +0 days

One random offset per patient, applied to every date in their record. Drag it, and watch the intervals below stay exactly where they are.

Preserved
intervals · time of day · day of week · season
Destroyed
absolute year · comparability between patients
anchor_year_group
2026 - 2028
anchor_age
58
2 · Clinical note de-identification 0 detected

Detection is a hybrid of dictionary lookup, regular expressions and context heuristics. What you put back is the interesting decision, try all four.

Original · PHI highlighted
Name Organisation MRN ABHA Contact Date Location
De-identified output
3 · Generalising indirect identifiers Mosaic defence
AttributeBeforeAfterWhy
Zone 3, Gold

The Vault state

This is the record every analyst, dashboard and local model sees. No privacy review is required to query it, because there is nothing here to review.

gold.patientNo identity present
k-anonymity · cohort this record hides in k = 1

Quasi-identifiers in play
Try to re-identify this patientLinkage attack

Here is a mock external dataset, the kind of thing an attacker actually has: an electoral roll extract for the district. Attempt to join it against the gold record above and find our patient.

NameAgeSexDistrictWard
Break-glass

Authorised re-identification

A lab result has to reach a real person. Here is the only path back, and every condition is required.

Acting asAnalyst
Re-identification request6 conditions
Stated purpose (ticket reference)
Second factor, live TOTP
••••••
Dual control, second authoriser
ResultSealed
Identity Vault sealed. Complete all six conditions to unseal.
Append-only audit chain Chain intact
No entries.
What a user without the permission seesAnalyst view
Zone 4, Egress

Why nothing leaves

The guarantee is not a promise in a contract. It is the absence of a route and the absence of a credential.

Send notes to an external modelBlocked

Attempt to POST the clinical corpus to a hosted LLM API.

Run the same model locallyPermitted

The same task, computed inside the boundary.

ABDM is not an exception to this. Consent-artefact exchange is outbound by design, and it should be. The rule is not no egress; it is no ungoverned egress. ABDM traffic is an allowlisted Zone 4 channel: consent-bound, logged, carrying only what the artefact permits.
Source
1 / 7

Synthetic data throughout. No real patient record is present, and nothing you type leaves your browser. Companion to The Yajur Health Vault: Anonymisation by Architecture.

Method drawn from MIMIC-IV (MIT-LCP) and the SAIL Databank (Swansea University).

Built by Manish Sharma, Yajur.ai, September 2026. Part of Yajur Labs. The cryptography here is genuine (AES-256-GCM, HMAC-based TOTP, SHA-256 hash chaining) and operates only on invented data that never leaves this page.