A federated approach to joining up data
Recent work testing federated data sharing in an adult social care context has demonstrated how established NHS interoperability principles can be extended beyond traditional healthcare settings. Using a derivative of an existing NHS-owned platform and working collaboratively with digital social care record suppliers, this approach has shown how data can be discovered, accessed, and combined across organisational boundaries in practice. While joining up data across health and care remains challenging due to fragmentation and differing ownership, data federation offers a scalable alternative to centralised repositories and point‑to‑point integrations, enabling data to remain with providers while being accessed through a unified interface as if it were a single dataset.
TL;DR
🌍 Joining up health and care data remains challenging due to fragmentation across systems and organisations
🔀 Federation keeps data local while enabling access when needed
🏗️ A shared platform provides security, routing, orchestration, and aggregation
🔗 Systems integrate once, avoiding complex point‑to‑point connections
📡 Queries are sent only to relevant providers and results are combined
📍 Data stays with the originating organisation as the system of record
📘 FHIR provides a consistent, standards-based RESTful API
🔄 Bi-directional transformation enables participation without changing internal models
🧭 Data discovery ensures targeted and governed access
🧠 Federation relies on strong central services such as identity, orchestration, and audit
⚖️ The model balances access with control, without centralising data
🧩 A scalable, sustainable approach to joining up data across organisations
Bringing together data across health and care settings has long been a challenge. Information sits in many different systems, owned by different organisations and governed by different rules. Approaches to addressing this may include centralising data into shared repositories or creating point‑to‑point integrations between systems.
An alternative architectural approach is data federation, where data remains within local systems but can be accessed when needed. This is not a new concept; federated models have been successfully implemented within the NHS, supported by unified, distributed data model architectures. In this model, data remains distributed across providers, but is exposed through a unified interface that allows it to be discovered, queried, and aggregated as if it were a single dataset.
Recently, we have been testing these established principles within an adult social care context, using componentry derived from the NHS-owned Interweave product set. Alongside this, collaborative engagement with digital social care record system suppliers has helped to demonstrate how a federated approach can be adopted more widely, and what it could enable for more joined‑up care.
The Architecture: Connecting Systems Without Centralising Data
At the heart of the approach is a Federated Integration Platform, a shared layer that sits between systems that provide data and those that consume it.
Rather than systems integrating directly with each other, they integrate once with the platform. The platform then handles security, routing, orchestration, transformation, and aggregation of data.
Key architectural principles
-
Federation over centralisation Care data remains with the organisations that provide it; the platform coordinates access rather than acting as a central store.
-
Loose coupling
Systems do not need to know about one another — they simply connect to the platform once. -
Single point of access
An API Gateway provides a unified entry point, handling authentication, security, and routing. -
Shared platform services
Core services include identity and access management, orchestration, record location, aggregation, transformation, and audit.
In practice, this means a system needing information about a person makes one request to the platform, rather than connecting to multiple providers individually.
Understanding Data Federation
Federation is often described in technical terms, but at its core it is simple: data remains where it is created and managed, while the results of queries across that data are brought together into a single, coherent view.
1. Distributed query and result aggregation
When a request is made (for example, to retrieve information about a person), the platform:
🔍 Identifies which providers may hold relevant data
📤 Sends the query only to those providers
📥 Receives responses from each
🧩 Aggregates them into a single response
This “fan‑out and aggregate” model enables systems to present a unified view without centralising data.
2. Data remains at the provider boundary
A key principle is that data is not centralised:
🗂️ Providers remain the system of record
⚡ Data is accessed on demand
⏳ The platform may cache data briefly for performance, but it is not a long‑term record store
3. Standard API layer using FHIR
All interactions with the platform are performed via a standard FHIR API.
FHIR is a widely adopted standard within healthcare, designed to enable interoperability between clinical systems. It combines a consistent data model with modern web technologies, using RESTful API principles rather than older SOAP-based web service patterns. This makes it simpler to implement, more flexible, and better aligned with how modern systems exchange data.
The platform adopts FHIR R4, a mature and widely supported version of the standard, which aligns with NHS APIs and national services that also use FHIR R4.
FHIR provides:
🧩 A consistent data model
🔎 A standard, RESTful way to query and retrieve data
🗣️ A shared language across disparate systems
4. Controlled dispatch and data discovery
Not every query is sent everywhere.
Participating systems register that they “know” about a person, allowing the platform to maintain a record of data availability without centralising the data itself. This forms the basis of the platform’s data discovery capability.
The platform then determines:
📍 Which providers may hold data about a person (based on subject of care/patient registration by participating providers) 🎯 Which providers should be queried
This enables controlled query dispatch, ensuring that requests are only sent to relevant providers and that data sharing remains targeted, governed, and efficient.
Why FHIR? A Foundation for Interoperability
FHIR provides a shared language across health and care, supporting interoperability between clinical systems. It is widely established within healthcare and forms a solid, proven foundation for interoperability across organisational boundaries.
A key strength of FHIR is its conformance and profiling capability. Using these features, it is possible to define constrained, domain-specific models tailored to particular use cases, while still remaining aligned to a common standard. This allows different systems to exchange data that is both structurally consistent and semantically meaningful, without sacrificing flexibility.
In practice, the source system providers we engaged with were not FHIR-native. Within this architecture, systems operate using a common operational data standard, with transformation into FHIR handled centrally using FHIR’s StructureMap capability. This enables bi-directional transformation between local data models and standardised FHIR representations, allowing integration without requiring systems to fundamentally change how their data is structured or managed.
FHIR is also built on RESTful API principles, aligning closely with modern web standards. This is an important distinction from older SOAP-based web service approaches, which can be more complex to implement and harder to evolve. The use of RESTful APIs enables simpler integration for system suppliers and is generally more compatible with contemporary development practices.
Importantly, the platform supports a broad range of the FHIR standard, enabling access to data not just as documents, but as structured, queryable information. This allows consumers to retrieve specific data elements (e.g. observations, medications, care plans) and assemble them into meaningful views, rather than relying solely on static document exchanges.
Taken together, these characteristics make FHIR well suited to supporting a wide range of current and future use cases, including:
🔗 Integrations with Shared Care Records
🌐 Cross-sector data sharing between health and care
📡 Event-driven use cases (e.g. notifications and subscriptions)
📬 Reliable messaging workflows supporting operational processes (e.g. hospital transfers of care and discharge notifications)
Federation Needs Central Capability
Although the model is federated, it depends on a set of centrally managed platform services to function effectively.
These services do not act as a central store of care data. Instead, they provide the coordination, control, and assurance required to enable secure and reliable data sharing across organisational boundaries.
Core capabilities include:
🔐 Security and identity management
🔎 Data discovery and record location
🔄 Query orchestration and controlled dispatch
📊 Aggregation of distributed results
🔧 Data transformation and standards alignment
📋 Audit and governance
Together, these services enable federation to operate safely and at scale, ensuring that data can be accessed when needed, while remaining under the control of the organisations that provide it.
Bringing It All Together
This approach combines established architectural principles with modern interoperability standards to enable data to be joined up without centralising it.
At its core, it brings together:
🌐 Federation, allowing data to remain at the point of origin
🧩 A unified, distributed data model, enabling consistent access across systems
🔥 FHIR, providing a standard, RESTful interface for interoperability
🏗️ A shared platform, delivering the services required to discover, request, and aggregate data securely
Rather than creating new point‑to‑point integrations or central repositories, the platform provides a consistent way to access data across multiple providers, supporting a more scalable and sustainable model for interoperability.
Final Thought
Recent work tested that a platform-based approach to federated data sharing can be successfully applied beyond traditional healthcare settings. By building on established principles, an existing platform and applying them within a broader care context, it has been possible to show how data can be discovered, accessed, and combined across organisational boundaries.
At its core, this approach provides:
A way to discover where data exists, securely request it, and combine it into a coherent view when needed.
By applying a federated model, supported by a platform that provides security, data discovery, orchestration, and aggregation, it becomes possible to deliver meaningful, joined‑up access to data while preserving local ownership and control.
