Every time a copy of a patient record is sent from one organisation to another, the risk attached to that record doesn't move — it multiplies. There are now two copies to secure, two access logs to reconcile, and two places a breach can happen. Scale that across a referral pathway touching a GP practice, an acute trust, a diagnostics lab and an insurer, and the surface area becomes very hard to defend.
For years the default answer to "how do we share this?" has been "send a copy." It is intuitive, and it is how most integrations were first built. But in a healthcare context it quietly works against the things that matter most: patient consent, data minimisation, and a clean audit trail. There is a better default, and it inverts the question.
Move the permission, not the data
The alternative is simple to state. The record stays where it already lives — in the source system that is already accountable for it. What moves between organisations is not the data but a short-lived, cryptographically signed token that says, in effect: "the bearer is allowed to read this specific slice of this specific record, for this purpose, until this time."
The requesting clinician presents that token to the system holding the record. The system checks it, confirms it is valid and unexpired, and releases only the portion the token covers — a discharge summary, say, but not the full psychiatric history. Nothing is copied wholesale, and nothing is released that the token doesn't explicitly authorise.
Consent stops being a checkbox
This model only works if the rules behind each token are genuinely the patient's. In a token-based design, consent is encoded up front as policy — which data categories, which institutions, for how long, and under what circumstances (including narrow emergency exceptions). When a request arrives, that policy is evaluated automatically before any token is issued. The patient's preferences are doing real work on every single request, not sitting in a consent form nobody reads again.
It also makes revocation meaningful. Because the token is the thing that grants access — and it is short-lived by design — withdrawing consent or detecting a problem invalidates access quickly, rather than chasing down copies that have already been distributed.
Every request becomes auditable
When access is mediated by tokens recorded on a tamper-evident ledger, you get something that copy-based sharing struggles to provide: a complete, ordered, immutable record of who requested what, when, on what basis, and whether it was granted or refused. That is precisely the evidence an information-governance team needs for UK GDPR accountability, and the kind of trail that makes an NHS Data Security and Protection Toolkit submission far less painful.
Crucially, refused requests are logged too. A pattern of denied attempts is often the earliest signal that something is wrong — and in a copy-based world, those attempts frequently leave no trace at all.
What it doesn't mean
This is not an argument for putting medical records "on a blockchain." Large clinical datasets belong in the secure, regulated, off-chain systems that already hold them. The ledger's job is narrow and specific: to hold the metadata — token identifiers, hashed pointers, consent rules and access logs — that makes verification trustworthy. The heavy data stays exactly where it is.
- Records remain in their source systems, under their existing controls.
- Only scoped, time-limited permissions move between organisations.
- Consent is evaluated automatically on every request.
- Every access — granted or refused — is logged immutably.
None of this is theoretical for us. This approach is the basis of Tan Tech AI's own method for secure healthcare data sharing, and it shapes how we design consent, access control and auditability for the healthcare organisations we work with.
This article is general guidance, not legal or regulatory advice. Information-governance obligations vary by organisation and context; we're happy to walk your IG team through how the model maps to your specific requirements.