AFFIXIO
Sandbox demonstration
INR recording without patient identifiers
A working demo of anticoagulation INR monitoring where the recorder keeps a private reference token, the browser hashes it before any network call, and AffixIO returns a live ZK proof plus Merkle leaf. No name. No NHS number. No patient store on this side of the boundary.
Demo only. Values typed here are not clinical records. Nothing from this form is persisted as a patient row. Sandbox API calls produce real proofs; the INR figure itself is not retained server-side.
Reference token model
How the private phrase works
The recorder chooses their own private phrase. AffixIO never asks for a patient name, NHS number, or clinic ID. Only the person who chose the phrase can re-derive the same SHA-256 hash later if they need to check that a specific reading was committed.
That phrase is not a patient ID. It is a recall key held by the recorder. The raw text is hashed in the browser, then cleared from the form. AffixIO never sees the phrase, and never stores anything that identifies the patient against the Merkle leaf.
Healthcare teams reviewing privacy-preserving INR workflows (and the wider debate on patient data breach exposure in anticoagulation services) can treat this as architecture proof, not a clinic product.
Record a demo INR
Enter a reading, a date, and your private reference token. On submit the token is hashed locally, then {inr_value, date, hashed_token} is committed into a sandbox ZK proof and Merkle leaf.
Sandbox receipt
After a successful run you will see the proof hash, the Merkle root, and the audit trail receipt from the live AffixIO sandbox.
- Proof hash
- Merkle root
- Transaction receipt
Breach contrast
A normal breach vs a breach against this system
Same clinic pressure. Different blast radius when the store is emptied.
Conventional INR database
An attacker who reaches a typical anticoagulation table gets the whole patient row in one query.
- Name
- NHS number
- Date of birth
- Full INR result history
- Contact and clinic metadata sitting beside the numbers
Everything needed to re-identify the patient and reconstruct their anticoagulation course is already joined.
AffixIO Merkle tree
An attacker who dumps the audit tree gets cryptographic commitments, not a patient register.
- A hash with no name attached
- No reverse lookup to NHS number or identity
- No readable INR history in the leaf
- Even possession of the hash proves nothing without the original reference token
- That token was never transmitted or stored
The leaf can show that a commitment was made. It cannot hand over who the patient was.
Questions
Is the raw reference token ever sent to AffixIO?
No. The browser hashes it with SHA-256 first, then clears the field. Only the hashed token participates in the commitment digest and sandbox call.
Where do the proof hash and Merkle root come from?
From the live AffixIO sandbox at /sandbox/api/zk. A yesno circuit proof is generated, then /v1/merkle/audit appends a leaf for the client-computed digest. You can inspect roots further in the Merkle verifier.
Can this replace an anticoagulation clinic system?
No. It demonstrates a zero-PII recording boundary for INR values. Clinical dosing, TTR reporting, and patient communication stay with dedicated clinic software and clinical governance.
Why talk about warfarin INR and patient data breach risk here?
UK anticoagulation services still concentrate high-sensitivity rows (identity plus serial INR history). Industry and research interest in privacy-preserving health data sharing, including zero-knowledge approaches, is rising for exactly that reason. This page shows a concrete commitment model without claiming clinical certification.