Written by Technical Team | Last updated 06.03.2026 | 18 minute read
The NHS Federated Data Platform is often discussed in terms of procurement, policy and public scrutiny, but the real story for digital teams begins much deeper in the architecture. Integration is where the platform either proves its value or becomes just another layer of technical overhead. For NHS organisations, integrated care systems, delivery partners and solution developers, the central question is not whether data can be connected, but how that connection can be made repeatable, governed, understandable and operationally useful. That is where Palantir Foundry pipelines and ontology layers become especially important.
In practical terms, the NHS Federated Data Platform is designed to support a landscape in which different NHS organisations, services and applications can work from a more standardised, reusable and trustworthy data foundation without collapsing everything into one monolithic local system. The integration challenge is substantial. Acute trusts, community services, mental health providers, pathology systems, scheduling tools, patient administration systems and national datasets all produce information in different formats, at different speeds and with different assumptions embedded in their schemas. An effective platform needs to absorb those differences without allowing them to dominate every future build.
Palantir Foundry provides a way to do that through two complementary capabilities. The first is the pipeline layer, where raw and semi-structured data are ingested, transformed, validated and prepared for use. The second is the ontology layer, where data is translated into a business-ready operational model built around real entities, relationships and actions. In the NHS Federated Data Platform context, these two layers are especially significant because they sit alongside the Canonical Data Model. The Canonical Data Model acts as the common structure that reduces repeated translation work, while Foundry pipelines and ontology patterns help make that structure executable in day-to-day NHS workflows.
This matters because NHS integration is not only about connecting records. It is about making patient flow, waiting list management, discharge coordination, theatre productivity, diagnostics planning and workforce visibility work across fragmented source systems. A technically elegant integration that fails to support frontline decisions has limited value. Equally, a visually attractive dashboard built on brittle mappings and inconsistent semantics will not scale. The real promise of the NHS Federated Data Platform lies in combining robust data engineering with a semantic layer that gives clinical and operational teams a clearer model of the world they actually work in.
What makes this especially relevant now is the emergence of the Solution Exchange model within the NHS Federated Data Platform. Instead of every organisation building from scratch, the platform increasingly points towards reusable dashboards, reusable data pipelines, reusable data models, templates and developer resources. That changes the economics of integration. If pipelines and ontology mappings are designed well, they can become portable implementation patterns rather than one-off local artefacts. This is where careful architectural design becomes a multiplier. A good integration does not merely solve a local problem; it becomes something other NHS organisations can adopt, adapt and trust.
Traditional NHS integration projects have often revolved around point-to-point interfaces, bespoke extracts, overnight batch files and local reporting databases that gradually become mission-critical without ever being governed as such. That approach can work for isolated use cases, but it tends to break down when organisations need cross-functional visibility, faster operational decisions and confidence that metrics mean the same thing in different settings. The NHS Federated Data Platform shifts the architectural centre of gravity away from isolated local reporting and towards a shared, governed data environment built around standardisation, deployment repeatability and common data semantics.
A major implication of this model is that integration is no longer just an ETL exercise. It becomes a product discipline. Pipelines are expected to do more than load rows from one table into another. They must produce outputs that can support reusable applications, common dashboards and scalable solution patterns across NHS organisations. That means the integration layer needs stronger conventions around dataset design, testing, lineage, schema management and release processes than many legacy reporting stacks were ever built to support.
The Canonical Data Model is central to this shift. In essence, it creates a structured target language for integration. Rather than every source system talking directly to every application in its own dialect, the Canonical Data Model provides a common model for representing entities, events and relationships across the NHS Federated Data Platform. That does not eliminate complexity, but it relocates it. Instead of hard-coding source-specific logic into every downstream application, organisations can handle transformation complexity once within the pipeline layer and then reuse standardised outputs more widely.
The value of this approach becomes especially clear in operational domains such as referrals, care contacts, activities, diagnostics, workforce and patient-level events. These are not abstract data categories. They are exactly the kinds of concepts that need to line up if trusts want to understand pathway bottlenecks, measure delays between referral and treatment, coordinate care transitions or compare operational performance over time. When a canonical structure is used consistently, the platform becomes more capable of supporting shared logic across different applications and local instances.
This is also why the NHS Federated Data Platform should not be thought of as a single giant database. It is better understood as a federated operating environment in which local and wider use cases can be supported through common integration patterns, controlled data flows and reusable application components. Integration therefore has to balance local flexibility with platform-wide discipline. Foundry pipelines are valuable here because they give teams a way to express that discipline through managed transformations, versioning, validation and release controls, rather than relying on undocumented scripts and institutional memory.
Palantir Foundry’s pipeline capabilities are well suited to NHS environments precisely because they combine engineering rigour with collaborative usability. In Foundry, pipelines are not simply hidden back-end jobs. They are visible, governable assets with lineage, branching, health checks and release processes. Pipeline Builder allows teams to design transformations in a graph-driven environment that supports both technical and non-technical collaboration, while Code Repositories support code-first development in languages such as Python, Java and SQL for teams that need greater control or more specialised logic.
That combination is important in the NHS Federated Data Platform because integration work rarely sits neatly within a single professional boundary. Data engineers may need to build ingestion and standardisation logic, analysts may need to validate metric definitions, operational leads may need to check whether the outputs align with frontline reality, and product teams may need to package the result as a reusable deployable asset. A pipeline environment that can support code-heavy and low-code collaboration within a governed framework offers a practical route through that complexity.
A robust NHS FDP pipeline normally needs to do several things well at once:
The most mature implementations treat these as distinct layers rather than compressing them into one opaque transformation step. Raw ingestion datasets should remain as close to source as possible for traceability. Standardisation layers should resolve obvious technical inconsistencies. Canonical mapping layers should align the data to NHS FDP structures. Curated output layers should then expose trusted datasets for downstream applications. This layered approach creates clarity, improves testing and makes it easier to diagnose where a problem originates when source systems change.
Foundry’s release and collaboration model strengthens this further. Branching, committing, code review and controlled deployment are not luxuries in NHS data integration; they are essential safeguards. Source systems evolve, data quality drifts, local workflows differ and business logic changes under policy pressure. Without disciplined change management, an operational dashboard can silently diverge from reality. By contrast, a managed pipeline approach allows teams to test changes before they reach production, compare outputs and preserve a more auditable record of how data products evolve.
Another major strength is reuse. Within the Solution Exchange direction of travel, reusable pipelines and reusable data models are not side benefits; they are core assets. A waiting list integration pattern that works in one trust may not be portable in full, but its design patterns often are. The same is true of discharge events, theatre sessions, care activities or referral flows. When pipeline logic is modular, well-documented and aligned to the Canonical Data Model, it becomes much easier to package and redeploy across the wider NHS FDP landscape. That is the difference between a local implementation and a platform contribution.
For NHS organisations, this suggests a practical design principle: build pipelines as products, not just as project deliverables. A project mindset tends to optimise for today’s deadline. A product mindset optimises for maintainability, discoverability, deployment repeatability and future adoption. In the context of the NHS Federated Data Platform, that distinction could determine whether integration effort compounds into a growing ecosystem of solutions or disappears into another generation of hard-to-maintain local workarounds.
If pipelines are the machinery that prepares data, the ontology layer is what turns that data into an operational model. This is one of the most misunderstood but important aspects of integration in Palantir Foundry. Many health organisations are familiar with data warehouses, semantic models for BI tools and master data management concepts, but the Foundry ontology goes beyond those patterns. It creates an operational layer that maps datasets and models to real-world entities, relationships and actions. In effect, it gives applications a structured way to work with concepts such as patients, referrals, wards, care activities, clinicians, theatres and discharge events rather than simply reading disconnected tables.
That distinction matters enormously in NHS settings. Frontline decision-making is relational. A delayed discharge is not just a row in a table. It exists in relation to a patient, a ward, an expected discharge date, a care team, an onward care requirement, a capacity constraint and a sequence of operational actions. Likewise, a waiting list pathway is not useful merely because the data has been loaded; it becomes useful when the platform can model the pathway, its status, its dependencies and the actions available to staff. The ontology layer is what allows those relationships to be represented explicitly and consistently.
A strong ontology model in the NHS Federated Data Platform usually depends on four building blocks. Object types represent key entities or events. Properties describe their characteristics. Link types model how objects relate to one another. Action types and functions introduce the ability to interact with the model operationally, including write-back and governed business logic. This makes the ontology more than a passive metadata layer. It becomes a bridge between trusted data and real work.
That has several direct advantages for NHS application delivery:
In many NHS organisations, one of the biggest barriers to digital adoption is not lack of data but lack of trust in how that data is structured and interpreted. Different teams often use the same words to mean different things, or different words to mean the same thing. The ontology layer helps resolve this by making semantics explicit. A referral object can have defined properties, defined relationships to activities or care contacts, and defined logic for state changes. A ward object can be linked to beds, patients, staffing signals and discharge metrics. The model becomes understandable not only to engineers but also to product owners and operational stakeholders.
This is also where the ontology becomes strategically important for reusable NHS FDP applications. If the pipeline layer handles local source variation and maps into canonical structures, the ontology layer can offer a more stable application-facing contract. That makes solution portability more realistic. A product deployed through the Solution Exchange does not need to know every nuance of each trust’s source systems if it can rely on a sufficiently well-modelled set of ontology objects and relationships backed by canonical data. In other words, the ontology can reduce coupling between applications and local integration complexity.
There is another crucial point here. In healthcare, context changes the meaning of data. A timestamp, a coded observation, a referral event or a staff assignment can mean very different things depending on where it sits in the care journey. Ontology design forces teams to model that context deliberately. It asks not merely what data exists, but what the data represents in operational reality. That is why ontology work should never be treated as cosmetic labelling after pipeline delivery. It is a core part of making the platform intelligible, governable and useful.
The most effective integration pattern for the NHS Federated Data Platform is not pipeline first or ontology first in isolation. It is canonical first, pipeline enabled and ontology aware. In practical terms, that means source data should be transformed through disciplined Foundry pipelines into structures aligned with the Canonical Data Model, and then exposed through ontology objects designed around operational use cases. This avoids two common failure modes: forcing applications to read directly from raw transformed tables, and building ontology objects on unstable, poorly governed data foundations.
A strong design starts with source decomposition. Teams should identify which source systems contribute to the target use case, which entities they own, which identifiers are stable, how frequently updates arrive and where semantic conflicts already exist. In a patient flow scenario, for example, this may include PAS events, bed management data, discharge milestones, clinic or theatre scheduling signals, and staffing or escalation data. The purpose at this stage is not to build everything, but to understand what reality the use case is trying to represent and where the source truth is strongest or weakest.
The next stage is canonical alignment. Here, local source fields are mapped into NHS FDP canonical structures using explicit transformation logic. This is where developers must handle code sets, date normalisation, identifier reconciliation, null handling, event sequencing and local exceptions. It is tempting to rush through this part in order to reach visual outputs quickly, but that usually creates downstream fragility. The canonical layer is the foundation on which reuse depends. If one trust maps referral closure differently from another and the logic is buried inside a dashboard calculation, solution portability is immediately weakened.
Only after canonical alignment is stable should the ontology design be shaped around the user journey. This is where teams ask what objects users need to reason about, which properties are essential, what links reveal the workflow, and which actions or functions the application must support. For example, a discharge coordination solution may require objects for patient, encounter, ward stay, discharge barrier, expected discharge date and responsible team. A waiting list solution may require objects for pathway, procedure, diagnostic dependency, priority, site and booked slot. The ontology should reflect the workflow logic of the use case, not simply mirror the source schema.
There is a practical architecture pattern that works especially well in this environment. Pipelines should produce clean, curated canonical datasets that are purposefully shaped for ontology ingestion rather than dumping every possible field into a universal table. Then the ontology should expose a concise operational view, with additional depth available through linked objects and shared properties where needed. This avoids overwhelming application teams and keeps the object model coherent. Overly bloated ontologies can become as hard to work with as poorly designed databases, whereas a well-curated ontology encourages adoption because it feels intuitive.
Governance is critical all the way through this pattern. Version control, branch-based development, validation checks and release discipline belong in the pipeline layer, but semantic governance belongs in the ontology layer as well. Teams need agreement on naming, ownership, property definitions, object boundaries and action behaviour. Without that, ontology sprawl can emerge, especially when multiple teams contribute solutions at pace. The best NHS FDP implementations will likely be those that combine local innovation with a strong centre of architectural guidance around canonical mappings and ontology conventions.
This is where the secure developer workspace and Solution Exchange direction become particularly relevant. A developer environment with sample or synthetic data makes it possible to build and test reusable logic safely before production deployment. That lowers the barrier to experimentation while preserving governance. It also encourages a healthier software lifecycle for NHS data products, where developers can prototype canonical mappings, validate ontology behaviour and package solutions for wider adoption rather than building directly against live local data from day one.
Ultimately, a canonical-to-ontology integration pattern should aim to make complex NHS workflows simpler without pretending the underlying complexity does not exist. The platform should absorb that complexity in disciplined engineering layers so that operational users can work with meaningful, trusted concepts. That is the architectural promise at the heart of the NHS Federated Data Platform when implemented well.
The long-term success of the NHS Federated Data Platform will depend less on isolated technical wins and more on whether it can support a durable ecosystem of reusable solutions. That is why integration architecture deserves so much attention. Every pipeline, every canonical mapping and every ontology object either contributes to a scalable platform model or adds to future fragmentation. The difference often comes down to whether teams build with reuse, trust and operational clarity in mind from the outset.
Scalability in this context does not simply mean handling more data volume. It means supporting more use cases, more organisations and more contributors without a corresponding explosion in bespoke integration effort. Reusable data products are central to that aim. A data product in the NHS FDP sense should include more than a dataset. It should include transformation logic, schema expectations, quality controls, semantic definitions, access assumptions and a clear intended use. Where appropriate, it should also include the ontology mappings and application-facing abstractions that make the product immediately usable in workflows and analytics.
Trustworthiness is equally important. NHS users do not adopt platforms because the architecture is elegant. They adopt platforms because the outputs are reliable enough to influence real decisions. That trust is earned through visible lineage, consistent definitions, controlled releases, sensible validation and the ability to trace metrics back to their origins. Foundry’s data lineage, managed repositories and ontology tooling all support that, but the tooling alone is not enough. Teams still need to embed disciplined operating habits into their delivery model.
For organisations and suppliers building on the NHS Federated Data Platform, several habits stand out as especially valuable:
This is also where the platform’s wider marketplace direction becomes highly significant. A central catalogue of reusable tools, pipelines, models and templates changes incentives for development teams. It rewards assets that are explainable, portable and governed. In that environment, integration quality becomes a strategic advantage. A supplier or NHS team that can deliver a solution with clean canonical mappings, strong ontology design and repeatable deployment logic is far more likely to produce something that can travel across the system.
There is an important cultural point here too. Many NHS digital programmes have been shaped by the tension between central standardisation and local autonomy. The NHS Federated Data Platform does not remove that tension, but it offers a more workable balance. Local organisations can retain their source systems and operational realities while contributing to a shared platform model through canonical integration and common application patterns. Foundry pipelines and ontology layers help make that balance technically feasible. Pipelines absorb source diversity; ontology layers create operational coherence.
Seen this way, the most insightful way to understand NHS FDP integration is not as a back-office technical activity but as a foundation for operational software. The pipeline layer is where data becomes trustworthy. The canonical layer is where it becomes standardised. The ontology layer is where it becomes meaningful and actionable. When those layers are aligned, the platform can support not just reporting but decision-making, workflow improvement and solution reuse at scale.
That is the real opportunity. The NHS Federated Data Platform can move integration away from a cycle of duplicated local engineering and towards a model in which trusted data products, reusable pipelines and ontology-driven applications become common infrastructure for the health and care system. Achieving that will require careful architecture, strong governance and disciplined delivery, but the path is clear. Build pipelines that standardise and validate. Map into the Canonical Data Model with precision. Expose the result through ontology layers that reflect the reality of NHS operations. Do that well, and integration stops being a constraint and starts becoming the mechanism through which the platform delivers lasting value.
Is your team looking for help with NHS Federated Data Platform integration? Click the button below.
Get in touch