Key Takeaways
- Technology is last in Boundary Readiness dependency ordering — not because it is least important, but because digital infrastructure cannot enforce governance requirements that have not been defined by Legal, Clinical Safety, Process, and People pillars
- Interoperability does not equal governed crossing — FHIR and shared care records solve the technical problem of data exchange but not the governance problem of what happens when data crosses organisational boundaries
- Governance-preserving infrastructure must maintain all Seven Flows — identity verification, boundary-specific consent, provenance metadata, structured clinical intent, responsibility tracking, service routing with pre-condition checking, and outcome communication
- Shared care records can obscure governance boundaries — aggregating data from five organisations into a single view creates the appearance of a unified record while collapsing the data controller architecture that the Legal pillar establishes
- MVRT-capable systems require four functions — responsibility state tracking, bilateral confirmation, unacknowledged transfer alerting, and audit trail generation — none fully provided by mainstream NHS clinical systems today
This is the tenth and final article in the Architecting for Neighbourhood Health series. The first article examined why the current governance conversation addresses committee structures but not boundary governance. The second introduced the Seven Flows. The third went deep on clinical responsibility transfer and the MVRT principle. The fourth examined constitutional complexity. The fifth introduced the Boundary Readiness model. The sixth examined the Legal pillar. The seventh examined the Clinical Safety pillar. The eighth examined the Process pillar. The ninth examined the People pillar. This article examines the fifth and final pillar: Technology — why interoperability that does not preserve governance is interoperability in name only.
Technology is last in the Boundary Readiness model’s dependency ordering. Not because it is least important, but because it is dependent on everything else. Digital infrastructure cannot enforce governance requirements that have not been defined. It cannot mitigate boundary hazards that have not been identified. It cannot implement crossing choreography that has not been agreed. And it cannot compensate for people who do not understand the governance architecture within which their systems operate.
This ordering directly challenges the neighbourhood health implementation programme’s enabler structure, which leads with data and digital. The Neighbourhood Health Guidelines for 2025/26 position digital infrastructure as a foundational enabler. The ten-year health plan places the shift from “analogue to digital” alongside the shift from “hospital to community” as a core reform priority. Shared care records, the single patient record ambition, and the Federated Data Platform (FDP) are all positioned as infrastructure that enables integrated care.
The Federated Data Platform is particularly significant for boundary governance. FDP’s architecture aggregates data from multiple NHS organisations for population health analytics, operational planning, and service management. The governance question is not whether this aggregation is valuable — it is — but whether the FDP preserves the data controller boundaries, legal bases, and consent architecture that the Legal pillar establishes at each bilateral boundary. A federated architecture that respects organisational boundaries is fundamentally different from a centralised platform that collapses them.
These platforms can enable governed integrated care. But only if what they integrate is governed. Technology that connects ungoverned boundaries does not create governance. It amplifies ungoverned connectivity. And ungoverned connectivity at organisational boundaries is where clinical risk concentrates.
The interoperability assumption
FHIR — Fast Healthcare Interoperability Resources — is the global standard for healthcare data exchange, and the NHS has committed to it as the foundation for interoperability across England. The Transfer of Care APIs use FHIR-based payloads for discharge summaries and other clinical communications. Medicines Interoperability uses FHIR to standardise medication information across systems. GP Connect provides FHIR-based access to GP record data. Shared care records across ICS footprints aggregate data from multiple providers into a unified view.
These are significant achievements. They solve the technical problem of getting data from one system to another in a structured format. What they do not solve — and were not designed to solve — is the governance problem of what happens to that data once it crosses an organisational boundary.
FHIR can carry a discharge summary from a hospital’s patient administration system to a GP’s clinical system via MESH. It can structure the clinical content using PRSB standards so the receiving system can parse it. What it does not do is confirm that the GP has received the summary, that the GP has reviewed it, that the GP has accepted clinical responsibility for the patient, or that the patient’s ongoing care plan has been updated to reflect what happened in hospital. The data crosses the boundary. The governance of that crossing — the MVRT requirements from the third article, the pre-conditions from the eighth article, the bilateral confirmation that distinguishes a governed crossing from an unacknowledged data dump — is not part of the interoperability specification.
This is not a criticism of FHIR. FHIR is a data exchange standard. It does what data exchange standards are designed to do: define the structure, vocabulary, and transport of clinical information between systems. The problem is the assumption that data exchange equals governed crossing. It does not. Data exchange is a necessary condition for a governed crossing. It is not a sufficient one.
What governance-preserving infrastructure requires
What Is Governance-Preserving Interoperability?
Governance-preserving interoperability is digital infrastructure that maintains the legal, clinical safety, and operational governance properties of data as it crosses organisational boundaries — not just the technical ability to exchange data between systems. It requires identity verification via PDS, boundary-specific consent recording, data controller provenance, structured clinical intent, bilateral responsibility transfer confirmation (MVRT), service routing with pre-condition checking, and structured outcome communication across every crossing. FHIR can carry the data. Governance-preserving infrastructure ensures the governance crosses with it.
Technology at a neighbourhood health boundary must do more than move data. It must preserve the governance properties of each of the Seven Flows as data crosses from one organisation to another. Each flow creates a specific technical requirement.
Identity infrastructure must confirm that both organisations are referencing the same patient, using the same verified identifier. In the NHS, this means PDS — the Personal Demographics Service — as the authoritative source of NHS numbers. But PDS confirmation is not universal. Community pharmacies may verify identity from prescriptions rather than clinical systems. VCSE organisations using CRM platforms may not have PDS integration at all. A shared care record that aggregates data from multiple organisations assumes identity has been resolved. If it has not — if the pharmacy record is matched on name and date of birth rather than verified NHS number — the aggregation may be incorrect, and every clinical decision based on the aggregated record inherits that identity risk.
Consent infrastructure must record not just whether the patient consented but what they consented to, which organisation they consented to share with, and whether their understanding of the sharing reflects the reality of the data controller architecture. In a co-located setting where the patient sees “the team,” the consent infrastructure must be capable of recording consent that is specific to each data controller boundary — not just a blanket “I consent to my information being shared” that obscures the constitutional reality of who is sharing with whom.
Provenance infrastructure must ensure that clinical information arriving at the receiving organisation carries sufficient context for safe interpretation. A test result without the requesting clinician’s rationale. A referral letter without the current medication list. A care plan update without the organisation that generated it. FHIR resources can carry provenance metadata — the Provenance resource in FHIR R4 is designed precisely for this purpose. But carrying provenance metadata and requiring it are different things. If the sending system does not populate provenance fields, the receiving system receives data without context. The interoperability “works” — the data arrives — but the governance property of provenance is lost in transit.
Clinical Intent infrastructure must preserve not just what was done but why — what the referring clinician expected to happen, what the receiving service is being asked to do, what the clinical question is. A referral that arrives as structured data (patient demographics, clinical summary, investigation results) but without a structured statement of clinical intent leaves the receiving clinician to infer what is being asked. The e-Referral Service supports advice and guidance functionality that can capture clinical questions. But many cross-boundary interactions in a co-located setting bypass e-RS entirely — they happen through corridor conversations, internal messaging, or ad hoc system workarounds that carry no structured clinical intent at all.
Alert and Responsibility infrastructure is the MVRT requirement from the third article, expressed as a technical specification. The system must be capable of tracking which organisation holds clinical responsibility for a patient at any given time. It must require bilateral confirmation before responsibility transfer is marked complete. It must generate alerts when responsibility is in transit beyond a defined threshold. And it must produce the audit trail that Clinical Safety Officers need to monitor boundary safety.
No mainstream NHS clinical system currently provides this capability. EPR systems track patients within a single organisation. Shared care records aggregate data across organisations. Neither tracks which organisation currently holds responsibility for the patient, or whether the transition from one to another has been bilaterally confirmed. The 90-hour gap from the seventh article — hospital discharges Friday afternoon, GP reviews discharge summary Tuesday morning — exists partly because no system alerts anyone that the patient’s responsibility has been in transit for four days.
Service Routing infrastructure must ensure patients are directed to the right service, at the right time, with the right pre-conditions satisfied. In a co-located setting, service routing is often informal — the GP knows the community nurse is available and asks her directly. The technology must support this informality while capturing the governance properties: which service was the patient routed to, was the service within scope for the patient’s need (the Clinical Intent match from the eighth article), and were the pre-conditions for that crossing type satisfied.
Outcome infrastructure must close the loop. The originating organisation must receive structured outcome information from the receiving organisation — what happened, what was done, what the patient’s status is, whether further action is required. Without outcome data flowing back across the boundary, the GP’s record is incomplete, the clinical loop is open, and the referral is a one-way door. Transfer of Care FHIR specifications define discharge summary payloads. But discharge is only one crossing type. Outcome communication from an advice-and-guidance interaction, from a community pharmacy Pharmacy First consultation, from a VCSE social prescribing referral — these crossing types often have no standardised outcome communication mechanism at all.
Governance Requirements for FHIR Resources
Three FHIR resources are critical for governance-preserving interoperability at organisational boundaries:
- FHIR Provenance — records who created clinical data, when, under what authority, and from which organisation. Essential for preserving data controller identity when information enters a shared care record or crosses a bilateral boundary. Without populated Provenance resources, receiving organisations cannot distinguish data generated internally from data that arrived across a governance boundary.
- FHIR Consent — captures what the patient consented to, with which organisation, and for what purpose. In co-located neighbourhood health settings, consent must be boundary-specific rather than blanket — distinguishing between data shared for direct care under implied consent and data shared for wider purposes requiring explicit consent or statutory authority.
- FHIR Task — models responsibility transfer workflows including initiation, acceptance, rejection, and completion states. Provides the technical foundation for MVRT bilateral confirmation and unacknowledged transfer alerting. A Task resource tracking responsibility state across two organisations is the closest the FHIR specification comes to the MVRT orchestration layer described above.
These resources exist within the FHIR UK Core specification. The gap is not in the standard but in implementation: most current NHS deployments do not require these governance resources to be populated at organisational boundaries, meaning governance metadata is technically possible but practically absent from cross-boundary data flows.
The shared care record problem
Shared care records are positioned as the solution to fragmented patient data across organisational boundaries. The ambition is sound: clinicians should be able to see relevant patient information regardless of which organisation generated it. ICS-level shared care records, such as the Yorkshire and Humber Care Record using the Interweave platform, aggregate data from multiple providers into a unified view using FHIR-based integration.
The governance problem is not in the aggregation. It is in what the aggregation obscures. A shared care record that presents data from five organisations as a single patient view creates the appearance of a unified record. But the data in that record belongs to five independent data controllers. Each data item was generated under a specific legal basis, for a specific purpose, by a specific organisation. The shared care record makes it visible to clinicians in other organisations — but the legal architecture governing what each clinician can do with that data (the Legal pillar’s six domains — data controller identity, lawful basis, DSAs, DPIAs, consent architecture, and constitutional compliance) is not visible in the interface.
A community nurse viewing a GP’s clinical notes in a shared care record may be operating under a different legal basis from the GP who generated those notes. The GP recorded the notes for the purpose of direct patient care within the practice. The community nurse is viewing them for the purpose of delivering community services under a different organisational and contractual framework. Both may be lawful — but the legal basis for each is different, and the shared care record does not surface that distinction. The nurse sees the data. She does not see the governance boundary she has crossed to see it.
This matters when things go wrong. If the nurse acts on information in the shared care record and the outcome is adverse, the question of who held responsibility, under what legal basis the information was accessed, and whether the governance architecture of the crossing was satisfied becomes critical — and the shared care record, by design, has made those boundaries invisible.
Governance-preserving shared care records would surface data controller provenance alongside clinical data. They would indicate which organisation generated each data item, under what legal basis it was shared into the record, and what constraints govern its use by other organisations. They would distinguish between data shared for direct care (where implied consent may apply) and data shared for wider purposes (where explicit consent or statutory authority is required). This is technically achievable within FHIR’s resource model — the Provenance and Consent resources exist precisely for this purpose. It is not, in most current implementations, what shared care records actually do.
The enforcement function
The most important distinction in the Technology pillar is between infrastructure that enables governance and infrastructure that enforces it. Enabling governance means providing the capability for governed crossings — systems that can carry structured referrals, record consent, attach provenance, communicate outcomes. Enforcing governance means requiring that governance properties are satisfied before the crossing can proceed — systems that will not send a referral until the pre-conditions are met, will not complete a responsibility transfer until bilateral confirmation is received, will not accept a data flow that lacks the required legal basis documentation.
Most current NHS infrastructure enables governance. Very little enforces it. A GP can send a referral through e-RS without documenting clinical intent. A hospital can generate a discharge summary without verifying the receiving GP has acknowledged it. A shared care record can present data across organisational boundaries without confirming the legal basis for each cross-boundary access. The infrastructure allows the governed crossing to happen. It also allows the ungoverned crossing to happen. And in a pressured clinical environment where time is scarce and governance is invisible — where boundary hazards sit between organisations rather than within them — the ungoverned crossing is faster and easier.
The Technology pillar of Boundary Readiness assesses not just whether infrastructure exists to support governed crossings, but whether infrastructure enforces the minimum governance requirements that the Legal, Clinical Safety, and Process pillars define. Where enforcement is technically feasible (blocking a referral that lacks required fields, alerting when responsibility transfer is unacknowledged beyond a threshold, logging cross-boundary data access with legal basis), the Technology pillar expects enforcement. Where enforcement is not technically feasible (systems that cannot be modified, legacy platforms with fixed workflows), the Technology pillar expects compensating controls — manual processes, audit mechanisms, monitoring dashboards — that achieve the same governance outcome through different means.
DCB 0129 and DCB 0160 at the boundary
The seventh article established that NHS’s clinical safety standards — DCB 0129 for manufacturers and DCB 0160 for deploying organisations — are scoped to individual systems within individual organisations. The Technology pillar extends the clinical safety question to the boundary: when two systems, deployed by two organisations, exchange data across an organisational boundary, has the clinical safety of that exchange been assessed?
The Transfer of Care FHIR specifications include a clinical safety case and hazard log, assessing risks associated with the interoperability standard itself. This is essential but insufficient. The clinical safety of a specific implementation — GP practice A using EMIS sending a discharge acknowledgement to hospital B using Cerner via MESH — depends not just on the standard but on how both systems have been configured, what data is included and excluded, how the receiving system displays the incoming data, and whether the clinical workflow on each side supports safe processing of cross-boundary information.
DCB 0160 requires the deploying organisation to assess clinical risks of its system deployment. In a neighbourhood health centre, this should include the risks arising from cross-boundary data flows — but in practice, the hazard log typically covers risks within the organisation’s own use of the system. The Technology pillar assessment asks whether the clinical safety case for each system deployment includes boundary-specific hazards: what happens when data from the GP system arrives at the community Trust’s system, what clinical context is lost in translation, what workflow assumptions break when the data originates from outside the organisation.
What MVRT-capable infrastructure looks like
The third article defined the Minimum Viable Responsibility Transfer — the bilateral confirmation mechanism that ensures clinical responsibility is explicitly transferred rather than assumed. The Technology pillar translates MVRT into technical requirements.
An MVRT-capable system must support four functions. First, it must track responsibility state — which organisation currently holds clinical responsibility for the patient, since when, and under what terms. This is not the same as tracking where the patient is in a pathway. A patient can be in a hospital bed while clinical responsibility for an ongoing community condition remains with the GP. Responsibility state is independent of location.
Second, it must require bilateral confirmation. When Organisation A initiates a responsibility transfer to Organisation B, the system must require Organisation B to confirm acceptance before the transfer is marked complete. Until confirmation is received, the system must indicate that responsibility is in transit — and both organisations must be able to see this status.
Third, it must alert on unacknowledged transfers. If Organisation B does not confirm acceptance within a defined threshold (clinically determined, not technically arbitrary), the system must alert Organisation A that the transfer is pending. The alert must be visible to clinicians, not buried in a log. The 90-hour gap exists because no system alerts anyone that the patient is in governance limbo.
Fourth, it must produce an audit trail that records who initiated the transfer, when, what information accompanied it, when confirmation was received (or not), and what escalation actions were taken if the threshold was breached. This audit trail is what CSOs need to monitor boundary safety — and what the Clinical Safety pillar’s boundary incident pathway requires as evidence.
No mainstream NHS clinical system provides all four of these functions today. Achieving MVRT capability does not require replacing EPR systems. It requires a governance layer that sits across systems — an orchestration layer that tracks responsibility state, manages bilateral confirmation, generates alerts, and produces audit trails, regardless of which underlying clinical systems the co-located organisations use. This is infrastructure that can be built on existing standards. FHIR’s Task resource can model responsibility transfer workflows. FHIR’s Provenance resource can capture the audit trail. What is missing is not the technical standard but the governance specification that tells infrastructure vendors what to build.
The Data (Use and Access) Act
The Data (Use and Access) Act 2025, effective from June 2025, grants government new powers to establish implementable interoperability criteria for health IT systems, including the power to mandate standards for data sharing between NHS organisations. This is a significant development. If exercised effectively, these powers could require EPR vendors to support governance-preserving interoperability — not just data exchange but consent-aware, provenance-preserving, responsibility-tracking data exchange that satisfies the Seven Flows.
The Act also supports the ambition for a single patient record accessible through the NHS App. From the Technology pillar’s perspective, the governance question is whether the single patient record preserves or collapses the data controller boundaries that the Legal pillar establishes. A single patient record that aggregates data from five organisations and presents it as if it belongs to a single entity creates exactly the governance confusion this series has been documenting — the patient sees “their record” without understanding that the data in it is held by five independent controllers, shared under five different legal bases, and subject to five different sets of governance obligations.
The single patient record is clinically desirable and governmentally complex. The Technology pillar requires that the complexity is addressed in the infrastructure design, not obscured by the user interface.
The private sector technology challenge
Private healthcare’s technology landscape is more fragmented than the NHS’s, with no equivalent of FHIR UK Core, no mandated interoperability standards, and no shared care record infrastructure. Provider-to-provider data exchange often relies on PDFs, faxes, and manual transcription. Insurer-to-provider communication uses proprietary portals and bespoke integrations.
The governance challenge is the same — data crossing organisational boundaries must preserve identity, consent, provenance, clinical intent, responsibility, routing, and outcome — but the technical starting point is further back. The Technology pillar assessment in private healthcare often reveals that the infrastructure to support governed crossings does not exist, and must be designed rather than adapted.
The opportunity is that private healthcare is not constrained by legacy NHS systems. A private insurer designing a digital network from scratch can embed governance-preserving infrastructure from the outset — consent-aware data sharing, MVRT-capable referral workflows, provenance-preserving clinical communication. The question is whether the commercial incentives align with the governance requirements. Historically, they have not — insurers have optimised for claims processing efficiency rather than clinical governance at provider boundaries. The Technology pillar makes the governance requirements explicit, and therefore auditable.
The Technology pillar assessment
The Technology pillar assessment at Inference Clinical covers five domains at each bilateral boundary.
First, Seven Flows technical capability — whether the digital infrastructure at the boundary can preserve the governance properties of each of the Seven Flows. Can the system confirm identity using verified NHS numbers? Can it record boundary-specific consent? Can it attach provenance to cross-boundary data? Can it carry structured clinical intent? Can it track responsibility state and require bilateral confirmation? Can it route patients to appropriate services with pre-condition checking? Can it communicate outcomes back across the boundary in a structured format?
Second, enforcement capability — whether the infrastructure enforces the minimum governance requirements defined by the Legal, Clinical Safety, and Process pillars, or merely enables them. Where enforcement is technically feasible, is it implemented? Where it is not, are compensating controls in place?
Third, shared care record governance — whether the shared care record implementation preserves data controller provenance, surfaces legal basis for cross-boundary data access, and distinguishes between data shared for different purposes. Does the interface make governance boundaries visible or invisible?
Fourth, clinical safety at the boundary — whether the clinical safety case for each system deployment includes boundary-specific hazards, covering data transformation, context loss, workflow mismatches, and display assumptions when data crosses from one system to another. Does the hazard log address what happens between systems, not just within them?
Fifth, MVRT capability — whether the infrastructure supports the four MVRT functions: responsibility state tracking, bilateral confirmation, unacknowledged transfer alerting, and audit trail generation. If full MVRT capability is not present, what is the gap, and what compensating controls exist?
Technology is last because it depends on everything
The dependency ordering of the Boundary Readiness model — Legal, Clinical Safety, Process, People, Technology — is not a hierarchy of importance. It is a dependency chain. Technology implements the requirements that the preceding four pillars define. Without Legal in place, technology does not know what data flows are lawful. Without Clinical Safety, technology does not know which boundary hazards to mitigate. Without Process, technology does not know what pre-conditions to enforce. Without People, technology enforces requirements that the humans at the boundary do not understand, generating workarounds that bypass the governance architecture entirely.
The implementation programme’s instinct to lead with technology is understandable. Technology is visible, fundable, and measurable. You can count EPR deployments, measure FHIR message volumes, track shared care record coverage. What you cannot easily measure is whether the technology is enforcing governance or merely enabling connectivity.
The Boundary Readiness model makes that distinction explicit. Technology that enforces the governance architecture defined by the first four pillars is technology that makes neighbourhood health boundaries safe. Technology that provides connectivity without governance is technology that makes ungoverned crossings faster, easier, and harder to detect.
The choice between these two is not a technology decision. It is a governance decision. And governance decisions must come first.
This is the final article in the Architecting for Neighbourhood Health series. The ten articles together provide a comprehensive framework for boundary governance in neighbourhood health — from the governance gap in the implementation programme through the Seven Flows, MVRT, constitutional complexity, the Boundary Readiness model, and each of its five pillars. Inference Clinical’s Seven Flows Boundary Governance Audit assesses all five pillars at every bilateral boundary. To assess whether your boundaries are ready, book a scoping call.
Architecting Neighbourhood Health Series
- What the Implementation Programme Is Missing
- Mapping the Seven Flows in a Neighbourhood Health Centre
- Clinical Responsibility Transfer — Why Handover Frameworks Don’t Cross Organisational Boundaries
- Constitutional Complexity — Five Organisations, Five Legal Frameworks, One Building
- Boundary Readiness — Why “People, Process, Technology” Fails at Healthcare Boundaries
- The Legal Pillar — Data Sharing, Contractual Frameworks, and Constitutional Compliance
- The Clinical Safety Pillar — When the Hazard Sits Between Organisations
- The Process Pillar — Crossing Choreography and the Pre-Conditions Nobody Defines
- The People Pillar — Why Generic MDT Training Doesn’t Cross Organisational Boundaries
- The Technology Pillar — Why Interoperability That Doesn’t Preserve Governance Is Interoperability in Name Only (current)
Inference Clinical’s Seven Flows Boundary Governance Audit assesses the Technology pillar at every bilateral boundary — Seven Flows technical capability, enforcement capability, shared care record governance, boundary clinical safety, and MVRT capability. To assess whether the digital infrastructure at your boundaries preserves the governance architecture, book a scoping call.
