The Federated Clinical Data Nexus
Data fragmentation is the default state of clinical infrastructure. Ten systems. Five protocols. Zero unified view. This blueprint documents a federated approach to resolving it — without centralising patient records or incurring the compliance cost of a persistent data warehouse.
The Longitudinal Patient View — Why It Is Harder Than It Looks
The Longitudinal Patient View — a single, time-ordered timeline of every clinical event across a patient's care history — is the architectural objective that defines serious HealthTech products. Laboratory results, EHR encounter notes, radiology reports, discharge summaries, prescriptions: aggregated into one coherent record that a clinician, a patient-facing application, or a clinical decision support system can query in a single call.
The business case is unambiguous. A clinician reviewing a patient without a longitudinal view must mentally reconstruct that history from several disconnected systems: opening the EHR for encounter notes, navigating to a separate laboratory portal for blood panel results, launching a PACS viewer for imaging, and checking a pharmacy system for current medication status. The cognitive overhead is real. The risk of missed or delayed information is real. The cumulative time cost — per clinician, per shift, across an organisation — is substantial.
The engineering problem is that this view does not exist in most clinical environments. It must be constructed. And the most common approach — ingesting, transforming, and centralising all clinical data into a persistent data warehouse — creates a second set of problems that frequently rivals the ones it was meant to solve.
In the UK NHS, a typical patient's record spans primary care (EMIS Health or SystmOne), acute trust EPR systems (System C, Cerner, Epic), pathology laboratories, radiology PACS, community pharmacy, and mental health services. None of these systems share a common data model. The NHS Spine provides a national patient summary — not a longitudinal clinical record.
The centralisation approach fails for three predictable reasons. First, it requires a migration project — extracting data from each source, transforming it into a canonical schema, and loading it into a warehouse — expensive in engineering effort and highly sensitive to source schema changes. Second, it creates a new compliance surface: every patient record held in the warehouse is a new data processing obligation under GDPR, the NHS Data Security and Protection Toolkit, or HIPAA. Third, it produces stale data: a warehouse that synchronises every four hours is a reporting tool, not a clinical tool.
The Federated Nexus Pattern addresses all three failure modes by inverting the premise: instead of bringing data to a central store, it brings queries to the data.
HL7 v2 vs FHIR — The Standards Gap That Breaks Integration
The clinical data landscape is not unstructured chaos — it is structured chaos. Decades of interoperability work have produced genuine standards: HL7 v2, HL7 v3, CDA, FHIR R4, DICOM, SNOMED CT, LOINC, RxNorm. The problem is that these standards co-exist in production rather than converge. A single patient's record may span systems using HL7 v2 ADT messages for admissions, HL7 v2 ORU for laboratory results, DICOM for imaging, CDA for clinical documents, and proprietary vendor formats for everything else.
| Dimension | HL7 v2 (Legacy) | FHIR R4 (Current Standard) |
|---|---|---|
| Protocol | Pipe-delimited message segments | RESTful API · JSON or XML resources |
| Data model | MSH / PID / OBX / PV1 segments | Patient / Observation / Encounter resources |
| Query method | Event-driven ADT / ORU messages · no standard query API | HTTP GET with structured search parameters |
| Terminology | Local codes · inconsistent LOINC / SNOMED use | Mandatory binding to SNOMED CT, LOINC, RxNorm |
| Regulatory status | Entrenched in legacy EHR systems since 1987 | Mandated by US ONC (2023) · NHS FHIR roadmap active |
The architectural consequence is the N×M Integration Problem. Ten source systems, each requiring a custom adapter to query, normalise, and reconcile, produces up to 45 unique integration paths. Each path must be maintained independently. A schema change in one source system propagates as a breaking change across every adapter that depends on it — creating a maintenance surface that grows quadratically with the number of sources.
The performance consequence compounds the structural one. Legacy EHR systems were not designed for real-time API queries from an aggregation layer. Response latency of 2–15 seconds per source under concurrent load is common. Querying ten sources synchronously produces a wall-clock response time that is clinically unusable.
The Federated Nexus Pattern — Federate, Don't Centralise
The Federated Nexus Pattern leaves clinical data in its source system and builds the aggregation layer above it. Rather than solving the N×M integration problem by centralising data, it solves it by introducing a normalisation layer that each source connects to once — reducing N×M to N×1. Three mechanisms make this operational.
-
1AI Semantic Mapper. Each source system exposes data in its native schema. The Semantic Mapper normalises all source output to a canonical target —
HL7 FHIR R4— without requiring hand-coded transformation rules per source. A trained mapping model resolves semantic equivalences: an HL7 v2 OBX segment becomes a FHIR Observation resource; local laboratory codes are reconciled against LOINC; patient identities are resolved across systems without a master patient index. Source schema changes are absorbed at the mapper rather than propagating as breaking changes to every downstream consumer. -
2Asynchronous Orchestrator. The Orchestrator decouples the aggregation request from the source system response cycle. When a longitudinal query is initiated, the Orchestrator dispatches parallel sub-queries to all relevant source systems and assembles the patient timeline as data arrives — applying configurable timeout thresholds per source and returning partial results when a slow or unavailable system does not respond within the threshold. A laboratory system responding in 300ms and a legacy EPR responding in 9 seconds do not block each other. The Orchestrator manages the latency variance that legacy clinical systems introduce as a structural property of their architecture.
-
3Mediated Schema — Virtual State. The assembled FHIR R4 response is held in a session-scoped ephemeral cache within the secure VPC — not written to a persistent data store. This
Virtual Stateprovides the unified query interface the consuming application requires without creating a new data processing obligation. When the session ends, the state is discarded. The patient record remains under the governance of its originating system. No new data retention policy is required. No new GDPR Article 30 processing activity is created beyond the query audit log.
This pattern follows the Data Mesh architectural philosophy introduced by Zhamak Dehghani (2019). Data Mesh treats each domain as the authoritative owner of its data — responsible for exposing it via a well-defined interface — rather than centralising ownership in a single platform team. The Federated Nexus applies this principle to clinical data: each source system remains the authoritative owner, and the Nexus layer provides the federated query surface.
Architecture — From Legacy Silos to Longitudinal View
Unified timeline · Real-time
FHIR R4 API surface
Each column in the architecture produces a durable artefact. The source column exposes native clinical data via existing interfaces — no migration, no schema modification, no vendor engagement required. The Nexus VPC transforms that data into a common FHIR R4 representation, assembles it asynchronously across sources with variable latency, and holds it in session-scoped state. The clinical interface receives a unified FHIR R4 API it can query with standard HTTP GET requests — with no awareness of the source protocols or their inconsistencies.
The critical property this architecture preserves is that the patient record never leaves its source system. The Nexus holds only a transient, session-scoped representation. Compliance obligations remain with the originating systems. No new GDPR Article 30 processing activity is introduced beyond the query audit log at the Nexus layer.
Data Availability Over Data Centralisation
The governance question in clinical data architecture is not whether to build a unified patient view — it is whether to achieve that view through centralisation or federation. These are not equivalent choices. The compliance cost, the engineering cost, and the operational risk profile differ substantially between the two approaches. The positions below explain why this pattern holds on centralisation as a deliberate architectural decision, not a technical limitation.
Governance positions
Hold on Centralisation — The Compliance Cost Is Structural
Centralising patient data in a new persistent store creates obligations that federated queries do not. Under GDPR and the UK NHS Data Security and Protection Toolkit, every new processing activity involving patient-identifiable data requires a Data Protection Impact Assessment, a lawful basis under Article 6, and explicit processor arrangements under Article 28 if a third party holds the data. A centralised clinical data warehouse aggregating records from ten source systems must satisfy all of these obligations — for all ten sources — before processing a single query. The federated approach limits new processing obligations to the query audit log. This is not a compliance preference; it is a structural cost difference that affects feasibility for smaller HealthTech organisations building without a dedicated information governance function.
FHIR R4 as the Canonical Interface — Regulatory Alignment by Design
Normalising all source data to HL7 FHIR R4 at the mapping layer maintains forward compatibility with the regulatory direction of travel in both the US and UK markets. The US Office of the National Coordinator for Health IT mandated FHIR R4 APIs for certified EHR systems in 2023 under the 21st Century Cures Act Interoperability Rule. NHS England's FHIR roadmap is actively transitioning national services — the NHS App, the Summary Care Record FHIR API, and the Patient Access API all target FHIR R4. An architecture that adopts FHIR R4 as its canonical schema today is tracking a mandate already in motion, not speculating about future standards.
Audit at the Nexus — Federated Access Requires Centralised Logging
The access control surface that a centralised warehouse provides through permissions on a single data store must, in a federated architecture, be provided through a centralised audit trail. Every query passing through the Nexus is logged: requesting application, patient identifier, data sources queried, FHIR resources returned, response latency, and session identifier. This log satisfies GDPR Article 30 records of processing activities, NHS DSP Toolkit Assertion 4.3, and HIPAA 164.312(b) audit controls. It provides a single point of audit accountability that mirrors the access control surface of a centralised store — without the compliance overhead of being that store.
AWS HealthLake and Google Cloud Healthcare API implement an architecturally equivalent position: both provide a FHIR R4 API surface that normalises ingested clinical data from heterogeneous sources and exposes it via a unified query interface. Both position themselves as federated aggregation layers rather than authoritative data repositories — reflecting the same governance reasoning documented here. The pattern is consistent with the architectural direction of the two largest clinical data infrastructure providers.
Interoperability as a Valuation Signal
Interoperability is an increasingly explicit criterion in HealthTech M&A and investment diligence. These are the structural advantages the Federated Nexus delivers to that process.
No ETL pipeline, no schema migration, no warehouse provisioning. Source data stays in its originating system. Engineering effort concentrates on the Nexus layer — not on moving records that are already safely stored.
New processing obligations limited to the query audit log. No DPIA for a new data store. No Article 28 processor agreements for centrally held patient records. No additional NHS DSP Toolkit evidence assertions.
Adding a new clinical data source requires a new mapper profile and Orchestrator route — not a new ETL pipeline, schema change, or warehouse migration. Each source is an independent mapping unit.
The architecture produces a FHIR R4 API surface as its primary output — directly measurable against ONC interoperability criteria and NHS FHIR conformance profiles. A technical due-diligence reviewer finds a standards-compliant API, not a proprietary query layer.
Every query produces a structured audit log entry at the Nexus. GDPR Article 30, HIPAA 164.312(b), and NHS DSP Toolkit access logging requirements are satisfied structurally — not retrospectively added as a compliance retrofit.
US ONC FHIR mandates are live. NHS England's FHIR roadmap is progressing. The architecture adopts FHIR R4 as its canonical interface now — not as a future migration target. No technical debt accrues against the mandate.
Is the Federated Nexus the right architecture?
This pattern fits when
Clinical data lives across three or more source systems with distinct schemas and no existing common query interface
The target product requires a real-time or near-real-time longitudinal view — not a batch analytics report or scheduled cohort export
Centralising patient data would create unacceptable compliance overhead under GDPR, HIPAA, or NHS DSP Toolkit obligations
FHIR R4 is the mandated or preferred interoperability standard for the target market or regulatory environment
The product is a clinical decision support tool, patient portal, or care coordination layer — not a primary system of record
This pattern does not fit when
The use case is large-scale retrospective analytics across a historical cohort — a centralised data warehouse is more appropriate for batch processing at that scale
Source systems cannot expose read APIs in any form — HL7 v2 feeds, FHIR endpoints, or direct database access under a data sharing agreement are all unavailable
The clinical environment requires full offline capability — the federated pattern requires network access to source systems at query time
The team lacks senior clinical informatics expertise to design and validate the FHIR R4 mapping layer — incorrect terminology binding produces patient safety risk, not merely incorrect data
Building a HealthTech product on fragmented clinical data? Start a conversation →