Written by Technical Team | Last updated 06.03.2026 | 18 minute read
Hospital data integration in England has entered a different phase. The challenge is no longer simply collecting more information from more systems. It is making operational, clinical and administrative data usable across care settings, products and decision-making contexts without forcing every trust to rebuild its information architecture from scratch. That is where the NHS Federated Data Platform, the FDP Canonical Data Model and local Electronic Patient Record integration come together.
For NHS trusts, the hardest part of FDP adoption is rarely the dashboard, workflow or user interface. The real work happens much earlier, in the disciplined translation of source data from one or more hospital EPRs into a consistent, governed and reusable canonical structure. Mapping an EPR to the FDP Canonical Data Model is therefore not a narrow technical task. It is the foundation for product deployment, operational reporting, pathway visibility, cross-system interoperability and trustworthy automation.
This matters because hospital EPR estates are rarely neat. Most trusts operate a primary EPR alongside departmental systems, PAS platforms, scheduling tools, theatre systems, pathology feeds, diagnostic systems, bed management applications, cancer tracking tools and locally built databases. Even where one vendor dominates, the underlying data is fragmented by workflow, specialty, history and implementation choice. Different trusts can use the same EPR vendor and still represent appointments, encounters, waiting list events, admissions, referrals and outcomes in materially different ways. A canonical model exists to absorb that variation without losing the operational meaning required by the NHS.
The FDP Canonical Data Model is particularly important because it is not simply a passive storage schema. In practice, it becomes the common structural layer that supports FDP products, repeatable logic, shared semantics and, in an implementation built on Palantir Foundry, a governed ontology-driven operating model. That makes mapping quality a strategic issue. Poor mappings produce superficially populated tables and misleading outputs. Strong mappings create a reusable data foundation that supports elective recovery, flow, discharge, outpatient transformation, cancer operations and future solution exchange products with less rework.
Done well, this mapping effort does more than connect systems. It converts local hospital data into operationally coherent objects and relationships that the wider FDP ecosystem can understand, validate and use.
The first mistake many organisations make is to think of the FDP Canonical Data Model as just another target schema for ETL. It is more useful to view it as the formal expression of how the NHS wants operational and healthcare data to be structured so that products can consume it consistently. In that sense, the canonical model sits between local source-system complexity and usable platform capability. It gives trusts a standard way to represent core entities such as patients, appointments, encounters, admissions, observations, procedures, pathways and linked operational events, while preserving the detail needed for local and national use cases.
This is especially significant in the NHS context because the Canonical Data Model is intended to be technology-neutral at the logical level, while still supporting concrete implementation in physical data products. That distinction matters. A trust does not map directly from an EPR screen to a dashboard tile. It maps from source-system data structures into a logical model with defined entities, attributes, identifiers, relationships and code systems, and then that model is materialised in platform-specific ways for applications, workflows and analytics. This is why organisations that treat the exercise as a basic field-to-field export often struggle later. They may achieve population of tables, but not semantic consistency.
The structure of the FDP Canonical Data Model also reflects the reality that healthcare operations are event-rich and relationship-heavy. A patient is linked to pathways, referrals, appointments, admissions, diagnoses, procedures, care professionals and time-based milestones. An outpatient appointment is not simply an isolated row with a date and specialty. It may carry administrative category, attendance status, consultation mechanism, RTT context, clinical appropriateness dates, outcome of attendance, treatment function and links back to the relevant patient and referral context. Likewise, an encounter is not merely a generic visit record. In operational terms, it can drive waiting list position, admission intent, removal reason, treatment responsibility and downstream product logic.
That relational depth is what makes canonical mapping powerful. It allows a trust to load information once in a standardised structure and then reuse it in multiple FDP capabilities. An elective care product may need pathway timing, breach logic, specialty context and waiting-list metadata. A discharge or flow product may need admission state, care professional relationships, ward movement and observation signals. A population view may need the subject-of-care structure to remain consistent even when source systems disagree. The canonical model is what makes those uses coherent rather than bespoke.
There is also an architectural point that often gets overlooked. In a Foundry-based implementation, the canonical model does not live in isolation from the platform’s broader data and application model. It can be surfaced through datasets, transformations and ontology objects, with typed properties, links and governed logic layered on top. That means a trust’s mapping decisions affect not only storage but also downstream object models, workflow actions, application behaviour, lineage, access control and product extensibility. In other words, the mapping is not just integration plumbing. It defines how the hospital will be represented inside the platform.
A conventional data migration usually aims to move data from one application to another with enough fidelity to continue business operations. FDP integration is more demanding. It is not only about preserving source data, but about normalising local variation into a shared operational language. That creates a different class of design decisions.
The first difficulty is semantic mismatch. Hospital EPRs frequently mix clinical, administrative and workflow concepts in ways that make perfect mapping impossible without interpretation. One source may treat a clinic booking, attendance event and care contact as the same underlying object. Another may split them across scheduling, attendance and encounter tables. A trust may use local workflow statuses that look equivalent to national concepts but actually mean something narrower, broader or temporally different. Even apparently simple fields such as appointment type, cancellation reason or discharge status can contain years of local convention embedded in picklists, free text, interface logic and staff workarounds.
The second difficulty is temporal truth. The FDP Canonical Data Model is valuable precisely because it supports operational decision-making, and operational decisions depend on when something happened, when it changed and what was known at the time. Many EPR implementations contain both current-state fields and event-history tables, but not always cleanly. An appointment record may carry the latest status only, while historical changes sit in an audit log that is hard to use. A pathway may have a current RTT position, but the clock-start derivation lives elsewhere. An admission may be straightforward for completed spells but ambiguous for in-flight cases where the trust runs parallel bed management and PAS workflows. Mapping to the canonical model therefore requires a clear policy on event capture, state derivation and late-arriving changes.
The third difficulty is that trusts rarely integrate from a single source. Even where there is a dominant EPR, some of the most important data required by FDP products is often held elsewhere. Referral detail may be in a PAS or elective care module, observation data in a specialist monitoring tool, discharge planning information in a separate operational application, and clinician assignment in another workflow system. A hospital therefore does not truly map an EPR to the canonical model. It maps a local digital estate to the canonical model, with the EPR acting as one major source among several. This is why source-to-target mapping documents that focus only on one database often collapse under real operational use.
A fourth challenge is identifier strategy. Canonical models depend on stable keys and trusted relationships. Local environments do not always provide them cleanly. Patient identity may involve NHS number, hospital number, local patient ID and merged records. Appointment identity can be reshaped by rescheduling and rebooking logic. Encounter IDs may be absent from some departmental systems or reused in ways that do not behave like a durable enterprise key. If the trust does not design clear survivorship and key-management rules, the result is duplicate objects, broken links, drifting histories and inconsistent counts across products.
A practical way to understand the integration challenge is to break it into the dimensions that usually fail first:
These pressures explain why successful FDP integration programmes are typically iterative rather than one-off. Trusts start with a product-driven minimum viable mapping, but mature implementations steadily harden the underlying canonical layer until it becomes reusable across multiple use cases. The best programmes recognise that every shortcut in the early source-to-canonical design eventually reappears as product debt, reconciliation pain or user distrust.
A robust mapping programme starts with use cases, not fields. That may sound obvious, but it is one of the most important disciplines in FDP delivery. A trust should begin by identifying which FDP products, workflows or operational questions the data must support, because that determines the level of semantic precision required. Mapping appointments for a simple activity feed is not the same as mapping them for elective pathway prioritisation, PIFU management or validation of RTT-sensitive operational logic. The target is not merely the canonical model in the abstract. It is the canonical model as used by real products and decisions.
Once the use case is defined, the next step is object-first analysis. Instead of producing a giant spreadsheet of source fields and target columns, the integration team should first define the core business objects and relationships that need to exist in the canonical layer. For most acute trusts, that usually begins with patient, appointment, encounter, admission, pathway, diagnosis, procedure, care professional and location or ward context. The essential question is not “where can we find field X?” but “what local records together constitute this canonical object, and what rules determine its identity, lifecycle and relationships?” That shift in framing dramatically improves mapping quality.
This is also the stage at which source-system profiling becomes indispensable. Local data must be examined for null patterns, value distributions, code sets, update frequency, duplicate behaviour, audit availability and specialty-specific variation. Teams often discover that a field thought to be authoritative is only populated for one division, or that the source uses several local status columns with overlapping meaning. Profiling should therefore be done alongside workshops with operational owners, EPR analysts and service managers. Technical metadata alone rarely captures how frontline workflow actually creates data.
A dependable source-to-canonical method usually follows a sequence like this:
In practice, mapping rules need to be more expressive than direct field assignment. Consider outpatient appointments. A trust may have booking tables, slot records, attendance outcomes, clinic metadata, referral context and patient communication history spread across several structures. The canonical appointment object may require start time, booked time, cancellation timestamp, attendance status, consultation mechanism, treatment function, specialty, provider details and linkage to patient and referral. Some of those attributes come directly from source fields. Others need derivation, precedence rules or code translation. For example, consultation mechanism may need to be derived from local clinic template types and telephony flags; attendance outcome may need to reconcile conflicting statuses from booking and attendance subsystems; earliest reasonable offer dates may depend on elective pathway logic rather than appointment scheduling alone.
The same principle applies to inpatient and elective flow objects. Encounter and admission modelling often requires trusts to separate business concepts that local systems have conflated. A planned admission request, a waiting list entry, a hospital spell and a consultant episode are related but not identical. The canonical model is valuable precisely because it can represent these distinctions cleanly. The integration team therefore has to decide which source events instantiate which canonical object, when a new object begins, when an existing object is updated, and how status is represented over time. Without those decisions, downstream products end up operating on blended records that seem complete but behave inconsistently.
A mature implementation also creates a canonical mapping playbook, not just a one-off mapping document. That playbook should include naming standards, code translation policy, identifier rules, late-data handling, deletion policy, historical restatement rules and validation thresholds. As a trust moves from one FDP product to several, that playbook becomes the main control mechanism preventing every new team from reinterpreting the same source systems differently.
The most successful FDP integrations are not those with the most elegant pipelines. They are the ones with the clearest governance around meaning, ownership and trust. Canonical mapping magnifies both good and bad data management. If a trust has weak control over identifiers, local codes, status definitions or change management, the canonical layer will expose those weaknesses quickly.
Identity is usually the first major governance issue. Patient identity sounds simple until merged records, temporary identifiers, cross-site numbering practices and incomplete NHS number coverage begin to appear. A trust needs explicit rules for how patient keys are generated and matched in the canonical layer, which identifiers are mandatory, how merges are propagated and how orphaned records are handled. The same logic applies to operational identities. If an appointment is cancelled and rebooked, does the canonical object retain continuity or represent a new appointment linked by lineage? If a pathway is administratively split, how does the model preserve performance reporting truth without double-counting? These are governance decisions with technical consequences.
Terminology management is the next decisive area. The FDP Canonical Data Model is designed to support standardisation, but local hospitals inevitably use a mixture of national standards, vendor-specific enumerations and local values. Some are fully mapped to NHS Data Dictionary concepts; others exist only in local configuration tables or free text. A serious integration programme therefore needs a terminology crosswalk layer. This is where local values for attendance status, clinic type, cancellation reason, priority, specialty, treatment function, ward state or referral source are translated into governed canonical values, with exceptions documented and reviewed. Without this layer, trusts often believe they have mapped data when they have merely copied source values into a standard-shaped column.
Data quality assurance must then move beyond row counts and null percentages. Because FDP products rely on operational truth, the trust should validate canonical data in scenario form. That means tracing known patient journeys through the canonical layer and asking whether the platform would draw the same conclusions as frontline teams. A pathway close to breach should look close to breach. A discharged inpatient should no longer appear as occupying a bed. A virtual appointment should not be reported as face-to-face because a legacy clinic code was poorly translated. Quality in this context is not cosmetic completeness. It is business fidelity.
Strong governance usually includes several linked controls working together:
This is where the broader FDP and Foundry architecture becomes strategically useful. A well-governed implementation can combine source ingest, transformation logic, lineage, branch-based development, review processes and ontology-driven usage in one controlled environment. That allows trusts to treat canonical mapping as a living product rather than a fixed migration artifact. Changes can be proposed, reviewed, tested and deployed with traceability. When a source field changes its meaning after an EPR upgrade, or when a new FDP use case requires a richer relationship model, the trust has a way to evolve the integration without losing control.
There is also a cultural point worth making. Governance is often framed as friction, but in canonical integration it is what creates speed later. Once the trust has a governed identity model, standardised code translations and reusable validation scenarios, new FDP products can onboard much faster. The effort shifts from rediscovering what local data means to extending a trusted canonical foundation.
A trust that approaches FDP mapping as a single product implementation may succeed tactically and still miss the strategic opportunity. The real long-term value comes from building a scalable integration architecture in which source-system ingestion, canonical transformation, object modelling, validation and product enablement all reinforce one another. This is the difference between a one-project pipeline and an enterprise canonical layer.
At the ingestion level, the architecture should be designed to accommodate multiple refresh patterns and source modalities. Some hospital data can be synchronised in near real time, while other domains remain batch-oriented. The key is to preserve enough timing fidelity to support operational use without introducing uncontrolled complexity. Canonical integration pipelines should therefore separate raw source capture, conformed transformation and product-ready outputs. That layered approach makes it easier to restate history, investigate anomalies and add new data consumers without destabilising the trust’s core mappings.
The transformation layer should then be engineered around canonical contracts rather than product-specific extracts. In practical terms, that means building durable datasets or tables representing canonical objects and relationships, complete with validation rules and business logic tests. This is where many organisations gain leverage from a platform approach: they can use governed transformation tooling, code repositories where needed, release processes, lineage views and object-oriented outputs that connect cleanly to downstream applications. The more product logic that depends on canonical objects rather than bespoke source extracts, the more reusable the trust’s data estate becomes.
Validation deserves equal architectural weight. Too many programmes treat testing as a final check before go-live. In a scalable FDP implementation, validation is continuous. Pipelines should detect schema drift, code-set expansion, duplicate keys, broken relationships, missing timestamps and suspicious metric deltas. Operational dashboards for the integration team should track not only pipeline success but semantic quality, such as unexplained drops in active pathways, sudden changes in clinic attendance classifications or unusual inflation in open encounters. This is the discipline that keeps canonical data usable month after month, especially when local source systems evolve.
A future-ready architecture also plans for ontology and application usage from the beginning. In a Foundry-based environment, canonical objects can be surfaced into an ontology with typed properties, links and governed behaviour that support applications, workflows and reusable products. That has two implications for trust integration design. First, object identities and relationships must be stable enough to support user-facing operational tools, not just backend reporting. Secondly, the trust should think carefully about which fields belong as first-class object properties, which should remain lower-level technical attributes, and how operational actions will rely on them. Good ontology-aligned design makes it easier to build applications that let users reason about patients, appointments, admissions and pathways as coherent objects rather than disconnected records.
This is also where Solution Exchange becomes strategically important. If the NHS wants trusts and suppliers to discover, share and adopt proven FDP solutions at scale, those solutions need consistent underlying data structures. A trust with a mature canonical integration layer is far better placed to adopt or extend products without lengthy bespoke data engineering each time. In effect, strong mapping to the FDP Canonical Data Model is what turns the platform from a local implementation into a reusable product ecosystem.
The trusts that will gain the most from the FDP over time are unlikely to be the ones with the simplest source estates. They will be the ones that treat canonical mapping as an enterprise capability. They will build disciplined source-to-canonical rules, align local semantics to NHS-standard concepts, govern identity and reference data properly, and invest in validation that reflects real patient journeys and operational workflows. Once that foundation is in place, products become easier to deploy, local innovation becomes easier to scale and operational data becomes much more than an extract from an EPR.
Is your team looking for help with NHS Federated Data Platform integration? Click the button below.
Get in touch