The Access-Control Gap
Encryption protects the record. It does not, by itself, prove that the person opening it still has valid authority. Our problem was not whether data was encrypted. It was whether access remained justified, limited, and explainable across systems.
The safest place for a patient record is where it already is
The most useful sentence I heard all last year was not a compliment. We were sitting with an information-governance lead at an NHS trust, walking her through a tidy plan to pull several providers’ records into one place so a care team could finally see a patient whole. She let me finish. Then she asked why we wanted to make three fresh copies of the riskiest data she was responsible for. I did not have a good answer. That question is the reason this post exists.
The instinct we had to unlearn
For most of my career, the default way to share data was to move it. You copy it into a warehouse, a lake, a shiny new platform, and then you spend the next two years defending the copies. Every duplicate is a new thing to secure, a new place a breach can begin, a new entry on a register nobody enjoys keeping. UK GDPR has a word for the opposite of this. It is called data minimisation, and we had been quietly ignoring it while claiming to respect it. The uncomfortable truth is that most “secure data sharing” projects start by making the data less secure.
Where the better idea actually came from
I want to be precise about credit, because it matters and because our own website has been loose about it. We describe this way of working as something we build with, and the implementation is genuinely ours. The method underneath it is not ours. It was co-invented by Ramprakash Kalapala, a senior cloud architect at the State Compensation Insurance Fund in California and a Senior Member of the IEEE, whose writing on secure data sharing I had been reading for a while. He and his co-inventors set the method down in Indian Patent Application No. 202541120966, filed on 2 December 2025, titled “A Method and System for Secure Healthcare Data Sharing Using Blockchain-Backed Access Tokens.”
The idea is almost annoyingly simple. Leave the record where it lives. Let permission travel instead of data. A smart contract checks the patient’s consent rules and the requester’s credentials, a signed and time-limited token is issued, the source system verifies that token before it releases anything, and every request, allowed or refused, is written to a ledger that no single party can quietly edit. The parts we practise are the off-chain record with an on-chain pointer, the consent-driven token issuance, and the tamper-evident log. We built our version from his published method, on our own cloud work across AWS, Azure and OCI. No code changed hands, no fee, no consulting. I have never worked with the man.
Why it convinced me when the vendors did not
I have sat through a lot of demos. Central identity and access management, which is excellent right up to the point where the data leaves one organization and nobody owns the directory any more. Encryption everywhere, which protects the record at rest and says nothing about who was allowed to open it. Consent tools that capture a signature and then lose interest. Each of them, underneath, assumes there is a trusted party who keeps the true record of who did what. In a network of trusts, private providers and health-tech firms, there is no such party, and everyone in the room knows it.
That is the one thing Mr Kalapala’s method does that the others could not. It removes the trusted middle. A permission list can be changed by whoever holds it. A signed entry on a shared ledger is designed to resist unilateral alteration. When you can hand an information-governance lead a record of access that her own organization could not have altered, the conversation stops being an argument about whether to believe the log. It is a small change in where the trust sits, and it changes everything downstream.
What it looks like on a Tuesday
None of this is theoretical for us. It is how we now design healthcare engagements. Records stay in their source systems. Tokens are issued in a form that fits HL7 FHIR, so existing electronic record systems recognize them. The whole thing is built to sit inside UK GDPR accountability and the NHS Data Security and Protection Toolkit, with data residency kept in the UK because for our clients that is not negotiable. When an information-governance team asks the two questions that matter, who saw this and under what authority, we answer from the ledger rather than from a promise.
How the method works
In our implementation, permission moves through six explicit checkpoints: request, consent-and-context evaluation, token issuance, repository verification, release or denial, and finally recording or revocation. Keeping those checkpoints in one lifecycle means a reviewer can follow not only who asked for data, but why the request was allowed, limited, rejected, expired, or withdrawn.
What we can measure, and what we cannot yet
I am wary of case studies that arrive pre-loaded with round numbers, so here is the version we can defend. In a controlled pilot using synthetic patient identifiers, representative healthcare-access patterns, historical policy scenarios, and staged emergency events, we compared the architecture with our previous static-permission and conventional-log approach. Human clinical and governance oversight remained in place throughout.
The headline numbers point to three different kinds of improvement. Consent changes reached connected controls far faster, stale grants fell sharply, and a patient-specific access-history report moved from a multi-day reconstruction task to an eleven-minute retrieval. The point is not simply that the workflow became quicker; the authority behind each access became easier to test and explain.
| Before | After |
|---|---|
| Broad or lingering permissions could remain until someone removed them. | Access is bounded by consent, purpose, scope, and time. |
| Consent changes required coordination across systems. | Token authority can be invalidated when consent or policy changes. |
| Audit histories were reconstructed from separate mutable records. | Access, denial, expiry, and revocation evidence is retained in one lifecycle. |
| Emergency access could outlive the event that justified it. | Emergency authority is purpose-specific, logged, and self-expiring. |
Additional validation indicators
The same pilot also tested whether authority closed cleanly after its justification ended. Emergency-access overruns were eliminated in the staged scenarios, automatic revocation coverage rose to 96% from 12%, and complete access-event evidence reached 99.2% from 61%. Those indicators matter because a healthcare access model is only as trustworthy as its ability to close exceptions and preserve the evidence needed to review them later.
What we have not solved is the boring, decisive problem underneath all of this: getting different health systems to agree on one token format. That remains a coordination problem, not a technical one, and it will outlast any single project. I would rather state that limitation plainly than turn a useful architecture into a claim that it solves every part of healthcare interoperability.
Why this is bigger than one trust
We adopted this for our own clients, but the gap it closes belongs to the whole sector. The Information Commissioner’s Office holds UK organizations to accountability and data minimization under UK GDPR, and the NHS Data Security and Protection Toolkit sets the standard trusts are measured against every year. Neither is satisfied by a permission table that one party can edit after the fact. Cross-boundary sharing is where those requirements become operationally hardest and where centralized access models are weakest. Mr Kalapala’s method meets that requirement directly, by making access provable across organizations without a central gatekeeper. That is why I do not think of it as a healthcare trick or a Tan Tech trick. It is a better answer to a question every regulated sector is now being asked.
And so
We came in wanting to move data safely and left having decided not to move it at all. The best engineering advice I got last year came from someone who does not build systems for a living, in the form of a question I could not answer. The answer, it turned out, had already been worked out by someone I have never met.