Written for a mixed-seniority interoperability audience: NHS IT leads, digital leads, CTOs, and IG leads who know these systems, alongside clinic managers and founders who need the shape of the problem without the schema-level detail. The piece is pitched as a technical explainer with thought-leadership framing rather than an architecture deep-dive, so it stays readable across that range while still respecting the technical end of the audience.
TOFU positioning throughout: the goal is to build authority and frame the problem correctly, not to convert. There is no CTA, and WeHub appears once, contextually, in the "What good looks like" section, immediately subordinated to the principle ("the platform matters less than the principle"). The closing reduces the next step to a single concrete action, mapping one real flow end to end, rather than a generic "talk to us", which keeps the credibility a top-of-funnel reader is testing for.
The editorial thesis is consistent with the wider WeHub line: the integration layer is the decisive factor stakeholders systematically underestimate. Here that surfaces as the gap between data a clinician can see and data a clinician can use, and the governance latency that sits invisible on an architecture diagram.
The 2am problem
It is 2am in A&E. A patient arrives confused, unable to give a clear history, registered at a GP practice forty miles away and recently discharged from a different trust. The clinician in front of them needs three things quickly: current medications, recent investigations, and whether anything was flagged on that last admission. In theory, all of that exists somewhere in the NHS. In practice, getting to it might mean logging into a separate shared care record portal, squinting at a read-only summary that does not quite line up with the local system, and phoning a ward at the other trust to confirm a detail.
This is the gap that sits underneath every conversation about cross-organisational data sharing. The data exists. The standards exist. The legal basis for sharing it for direct care exists. And yet at the exact moment it matters, the clinician is still working harder than they should to assemble a picture the systems already hold between them.
For NHS IT leads, digital leads, and IG leads, this is the real subject. Not whether data can be shared, but whether it flows to the right person, in a usable form, with the governance properly handled, at the point the decision is being made. This piece walks through how that actually happens across NHS organisations, where it tends to break, and why the hardest part is rarely the technology.
What does cross-organisational data sharing actually mean in the NHS?
It helps to separate three things that often get lumped together, because they have different mechanics, different governance, and different failure modes.
The first is **viewing**. A clinician in one organisation looks at data held by another, usually through a shared care record. The record is assembled from multiple sources and presented as a read-only view. Most Integrated Care Systems in England now run one of these, often launched directly from within the local EPR so the clinician does not have to log in twice.
The second is **flowing**. Structured data moves from one system into another and lands as actionable information: a discharge summary that populates the GP record, a referral that arrives in the receiving service's worklist, a result that files against the right patient. This is harder than viewing, because the receiving system has to understand and trust the incoming data well enough to act on it.
The third is **analysing**. De-identified or controlled data is pooled across organisations for population health, planning, and operational management rather than the care of a named individual in front of a clinician. This sits under a different governance regime entirely, because it is not direct care.
Most of the frustration clinicians feel lives in the gap between the first and the second. They can often see the data. They frequently cannot use it without retyping it. And every time someone retypes a medication list from a portal into their own system, a transcription risk is introduced that the original integration was supposed to remove.
Why "secure" is a governance question before it is a technical one
Ask an engineer how to share patient data securely and you will get answers about encryption, authentication, and transport. All necessary, none sufficient. In the NHS, "secure" means lawful and appropriate first, and technically protected second.
Sharing for direct care rests on a stack of obligations that has to be satisfied before a single byte moves. The common law duty of confidentiality governs whether the sharing is permitted at all. UK GDPR and the Data Protection Act 2018 set the lawful basis, which for direct care typically combines a public task basis with the specific health and social care provisions rather than relying on consent. The Caldicott Principles, overseen at each organisation by a Caldicott Guardian, govern whether the sharing is proportionate and justified. The National Data Opt-Out has to be respected where it applies.
On top of that sits the paperwork that makes inter-organisational sharing real: Information Sharing Agreements between the participating organisations, Data Protection Impact Assessments for the flows themselves, and registration on the Data Security and Protection Toolkit so each party can demonstrate it meets the national standard. None of this is optional, and most of it is negotiated between organisations rather than handed down ready-made.
This is why a technically trivial integration can take months to go live. The connection is not the bottleneck. The agreement about who is allowed to share what, with whom, for which purpose, and on what legal basis, usually is. Any IT lead who has waited on an ISA to clear three organisations' governance committees knows this is where the calendar actually goes.
How the data actually moves
Once the governance is settled, the NHS has a reasonably mature set of mechanisms for moving the data. The challenge is that there are several of them, layered over two decades, and most trusts run a mix.
**NHS Spine** remains the central spine of national services. The Personal Demographics Service (PDS) is the authoritative source for matching a patient to the right NHS number, which is the precondition for safely joining records held in different places. The Summary Care Record provides a national baseline of medications, allergies, and adverse reactions. The National Record Locator points to where fuller records are held.
**GP Connect** lets GP clinical systems share data with other authorised systems, so a clinician outside the practice can view the GP record or, increasingly, retrieve it in a structured form. For acute-to-acute and acute-to-community exchange, **shared care record platforms** aggregate feeds from the local providers and present the combined view.
Underneath those programmes sit the transport and content standards. **HL7 v2** still carries a large share of operational messaging inside and between trusts, including admissions, discharges, and transfers. **FHIR**, aligned to UK Core, is the direction of travel for newer APIs because it makes structured data far easier to request and consume. **MESH** provides the national store-and-forward channel for moving files and messages between organisations reliably. Authentication runs through smartcards and CIS2, and transport is protected with mutual TLS so both ends of a connection are verified.
The point for a digital lead is not to memorise the alphabet soup. It is to recognise that a single cross-organisational flow usually touches several of these at once: PDS to confirm identity, a shared care record or GP Connect to source the data, FHIR or HL7 to carry it, MESH or a direct API to transport it, and CIS2 to authorise the person asking. Every one of those is a place the flow can succeed technically and still fail operationally.
Where cross-organisational sharing quietly breaks
The failures are predictable once you know where to look, and they are rarely about the network.
The first is the **view-versus-flow gap** already described. A shared care record a clinician has to open in a separate window, during a consultation, while the patient is talking, is better than nothing and worse than integration. If the data cannot land in the system the clinician is already working in, much of the value leaks away.
The second is **identity matching**. If the NHS number is wrong, missing, or not verified against PDS, records that belong to the same person stay separated, and records that belong to different people risk being merged. Patient matching is the unglamorous foundation everything else depends on, and it fails silently.
The third is **the snowflake problem**. Trusts run different EPRs, configured locally, with local code sets and local workflows. A flow that works perfectly between two organisations often has to be partly rebuilt for the third, because the assumptions baked into the first integration do not hold. Cross-organisational sharing at scale is less a single connection than a portfolio of them, each with its own drift.
The fourth is **governance latency**. The technical capability to share frequently outpaces the agreements that permit it. The result is a backlog of flows that could exist, are wanted clinically, and are stuck in committee. That gap is invisible on an architecture diagram and very visible in a clinician's day.
What good looks like: from viewing to flowing
The organisations making real progress tend to be moving deliberately from viewing towards flowing, and treating the integration layer as a first-class part of the architecture rather than a set of one-off connections.
In practice that means a few things. Identity is resolved against PDS as a standard step in every flow, not an afterthought. Newer integrations are built FHIR-first, so structured data can be requested and consumed rather than read off a screen. Flows are designed as reusable, monitored workflows, so a connection built for one pair of organisations can be extended to a third without starting over, and so a partial failure surfaces immediately instead of in a complaint weeks later. And the governance work runs in parallel with the technical work, not after it, so the ISA and the connection arrive together.
This is the layer platforms like WeHub are built to handle: normalising data between systems that were never designed to talk to each other, resolving identity, and making a flow repeatable and observable across organisational boundaries. The platform matters less than the principle. Any NHS organisation serious about cross-organisational sharing should be able to point to identity resolution, structured flow, reusable workflows, and parallel governance in how it is set up.
The bottom line
Cross-organisational healthcare data sharing is not held back by a shortage of standards or a lack of legal basis. Both exist. It is held back by the gap between data a clinician can see and data a clinician can use, and by the governance work that has to clear before either is possible.
If the 2am scenario at the top of this piece is familiar in your organisation, the most useful first move is not a new platform. It is to map one real cross-organisational flow end to end: where identity is resolved, where the data is sourced, how it is transported, where it lands, and where the governance sits. That single map will show you which of the four break points is costing you most, and that is the one worth fixing first.
