Key Takeaways
- Healthcare consent is not a boolean — it has at least six dimensions: subject, scope, purpose, recipient, duration, and revocability
- The hardest part of consent is not capturing it — it is making revocation propagate reliably across every system that received data under its authority
- When patient pathways cross organisational boundaries, each transition requires its own consent determination, its own lawful basis, and its own audit record
- FHIR R4’s Consent resource already supports granular, hierarchical consent modelling — the gap is in healthcare organisations not having the infrastructure to consume it
- Consent is the second of the Seven Flows — not a compliance checkbox but the continuous thread of patient authority that gives the entire data mesh its legitimacy
Picture a patient who has been referred by their NHS GP to a private digital health provider. Before their first consultation, they’re presented with a consent screen. They read it — or don’t — and they tick the box.
Job done. They’ve consented.
But consented to what, exactly?
To sharing their medical history? All of it, or the parts relevant to this referral? With this provider’s clinicians, or also their administrators, their AI triage system, their data science team? For this appointment, or indefinitely? And when they want to withdraw that consent three months from now — when the relationship with that provider has ended and they’ve moved on — what actually happens to it?
The honest answer, in most healthcare systems operating today, is that nobody knows. The consent was captured. It was recorded somewhere in a local system, possibly as a PDF attachment, possibly as a database flag. Whether it travelled with the patient across organisational boundaries, whether it can be audited under GDPR Article 7, whether revocation would actually propagate to every system that received data under its authority — these are questions that the checkbox was never designed to answer.
This is a governance infrastructure problem. And it is the second of the Seven Flows that Inference Clinical’s platform treats as first-class infrastructure.
What consent actually is
When we strip away the paperwork, consent in healthcare is a structured claim about permission. It says: this patient, at this time, with this understanding of what they were agreeing to, granted this specific organisation permission to process this category of data for this stated purpose, for this period, subject to these conditions.
That is not a boolean. It has at least six distinct dimensions:
If your consent infrastructure cannot represent and enforce all six of these dimensions, then what you have captured is not informed consent in any meaningful governance sense. It is a signature on a document that may offer you legal cover but will not withstand serious scrutiny — and in a post-Caldicott, post-UK GDPR environment, serious scrutiny is exactly what healthcare data governance faces.
The propagation problem
The hardest part of consent is not capturing it. It is making revocation work.
Consider what happens when a patient withdraws consent from a private provider. In a well-designed system, the signal should propagate: the provider stops processing new data under that consent, any downstream services that received data on the basis of that consent are notified, and an audit record is created showing what data was processed under the consent during its validity period, and what action was taken on revocation.
In practice, none of this happens reliably. Data has already been copied into systems that have no connection to the original consent record. The patient’s revocation hits a wall at the first organisational boundary. Support staff at the provider update a flag in their CRM. The analytics platform continues to process historical data. The referral partner was never notified the relationship ended.
This is not a hypothetical edge case. It is the default state of most healthcare data sharing today. And it creates genuine liability for every organisation in the chain, not just the one who handled the revocation badly.
The reason this happens is structural. Consent is treated as a document you file rather than a live artefact you maintain. There is no persistent consent record that all participating systems can reference. There is no event-driven mechanism that propagates consent changes to downstream consumers. There is no audit trail that ties data processing events back to the consent authorities under which they were authorised.
Building that infrastructure is what makes consent real rather than theatrical.
Consent across organisational boundaries
The problem compounds significantly when a patient pathway crosses institutional lines — which is, of course, exactly the scenario that Inference Clinical is built for.
An NHS GP refers a patient to a community mental health trust. The trust refers to a social care team. The social care team coordinates with a housing association. Each of these organisations operates under different legal bases for data processing, different data controller responsibilities, and different consent frameworks. NHS consent flows under the Health and Social Care Act. Social care consent flows under the Care Act 2014. Housing sits outside both.
When a patient gives consent at the GP practice, they are not giving consent that automatically extends to every downstream organisation in their pathway. Each transition requires its own consent determination, its own lawful basis, its own audit record. But the patient’s lived experience of their care is a single continuous journey.
The Consent Flow in our platform models this by treating consent as a versioned, signed artefact that travels with the patient event rather than being siloed in the originating system. When a responsibility transfer event occurs — when a GP formally hands over to a specialist, or when a community trust hands over to an acute trust — the consent artefact travels with it, is reviewed against the new context, and is either confirmed, modified, or flagged for explicit re-consent before data is shared under the new arrangement.
This is not how existing systems handle consent. Most systems assume that if data is flowing between two organisations, somebody somewhere has handled the consent question. That assumption is the governance gap that patient harm often falls through.
The FHIR representation
Technically, the Consent resource in FHIR R4 is one of the richer resources in the specification. It supports:
- Policy references (which regulations or agreements govern this consent)
- Provision trees (nested, hierarchical rules that override each other with explicit precedence)
- Actor references (specific practitioners, organisations, or roles covered by each provision)
- Data references (specific FHIR resources or categories of resource)
- Period bounds (start and end dates, review triggers)
- Status transitions (draft, proposed, active, rejected, inactive, entered-in-error)
What this means practically is that a properly implemented FHIR Consent resource can represent “this patient has consented to Dr. A at Organisation B processing their cardiology data for direct clinical care from 1 March 2026 until discharge, but has explicitly excluded data from a previous mental health episode, and has stated that consent should be reviewed if their care is transferred to a third organisation.”
That level of granularity is achievable today with published standards. The gap is not in the specification. The gap is in healthcare organisations not having the infrastructure to consume it.
Consent as infrastructure, not paperwork
The shift in framing that matters is this: consent is not a compliance activity you perform before doing the real work. It is operational infrastructure that governs what the real work is permitted to be.
When consent is infrastructure — versioned, auditable, portable, event-driven — several things become possible that are currently very difficult. You can answer, at any point in time, under what consent authority a specific piece of data was processed. You can demonstrate to a regulator that revocation was propagated completely and promptly. You can give patients a genuine view of who has accessed their data and why, which is their legal right and currently largely theoretical in practice.
More importantly for the clinical organisations involved: you can stop carrying the liability that comes from not knowing. The question of whether your data processing is properly consented moves from an audit risk you manage retrospectively to a continuous state you verify in real time.
That is what we mean when we say compliance as infrastructure rather than overhead. The Seven Flows framework treats consent not as a field in a database but as a live, travelling, auditable artefact that governs every data exchange in a patient’s journey. It sits alongside Identity, Provenance, Clinical Intent, Alert and Responsibility, Service Routing, and Outcome — not as one compliance checkbox among many, but as the continuous thread of patient authority that gives the entire data mesh its legitimacy.
If you are building patient pathways that cross organisational boundaries — and in neighbourhood health, in integrated care, in private-NHS partnerships, almost every pathway now does — this is the infrastructure question that determines whether your governance holds up when it is tested.
And it will be tested.
