Inside FDP – part 3: The data architecture that makes it work

What the best NHS data platforms have in common

The NHS data community includes people who have built genuinely sophisticated platforms: linked datasets spanning acute, primary, mental health, and community care; population-level risk stratification; near-real-time dashboards used 24 hours a day in system control centres; embedded analytics inside clinical systems; write-back capabilities pushing data into GP records.

These are not trivial achievements. They represent years of work by some of the most capable data professionals in the country.

But even the best of these platforms share a common architecture - the data lives in a warehouse, the descriptions live somewhere else (in a catalogue, a wiki, or a developer's head), and the applications that capture or display the data live somewhere else again. Three separate things, connected through extracts, feeds, and bespoke integrations that the team maintains by hand.

The analytical tools sit alongside the clinical systems, not inside the operational workflow - the clinician works in one place and the data team works in another. The two are connected, sometimes impressively, but the data, the tools, and the actions still live in separate places. A Frontline-First approach requires them to be in the same place.

This article is about an architectural choice that collapses that separation. It is not about whether existing platforms work. Many of them do, within their scope. It is about what becomes possible when the data, the description, the application, and the action all live in the same place.

What Palantir means by 'ontology'

The word "ontology" has become a source of confusion in the FDP conversation because it means different things to different communities.

In computer science and knowledge engineering, an ontology is a formal specification of what things exist in a domain, what properties they have, and how they relate to each other. It is a rigorous discipline with its own standards, including OWL (Web Ontology Language) and RDF (Resource Description Framework). It is not what the supplier of the FDP platform, Palantir, means by the word.

In Palantir’s Foundry software the ontology is something different. It is the operational layer of the platform where real-world concepts are represented as digital things that users interact with directly. It holds the data, hosts the applications, enforces access controls, and supports actions that change the state of the things it represents. It is closer to a living operational workspace than to a formal knowledge representation framework.

The double usage causes confusion in almost every conversation I have about FDP. Data architects hear "ontology" and think of formal knowledge engineering. Palantir engineers hear "ontology" and think of the operational layer their applications run on. Both are legitimate uses of the word – but they describe fundamentally different things.

For the rest of this article I am using the Palantir meaning - the ontology as the operational workspace, not the ontology as a formal logical framework for knowledge representation.

Object types: the building blocks

The foundation of Foundry's ontology is the object type. An object type is Foundry's way of representing a real-world concept that the NHS manages - a patient, a referral, a theatre session, a ward bed, a consultant, a waiting list entry, an appointment.

Each object type does two things that a traditional database table does not.

First, it holds both the data and its description in the same place. A theatre session object type does not just contain a row of values. It contains the definition of what a theatre session is, what its properties mean, how they relate to other concepts, and who is allowed to see or change them. The description travels with the data rather than sitting in a separate catalogue that nobody maintains.

Second, object types are connected to each other through link types, which are defined relationships that the platform maintains and resolves automatically.

'Actions' are the mechanism by which FDP applications capture new data at the point of care, not just present data that was captured somewhere else

In a relational database, the relationship between a theatre session and a patient exists as a foreign key. How that relationship gets resolved depends on what you are trying to do.

If you are an analyst running a query across all theatre sessions and all patients, the database engine performs an SQL JOIN, scanning both tables to find the matches. If you are a clinician looking up a single patient's theatre session, the system retrieves the linked record directly.

These are fundamentally different workloads, and traditional architectures handle them with fundamentally different systems: an OLTP system, such as an electronic patient record (EPR), for the clinician's individual lookup; and an OLAP system, such as a data warehouse, for the analyst's cross-population query. Data flows from the first to the second through overnight extracts and batch pipelines, and the two never share a live view.

Foundry's ontology resolves both queries from the same data. When a clinician views a theatre session, the platform performs what Palantir calls a "search-around" - starting from a single object and navigating its defined links to the patient, the consultant's schedule, the recovery bed status. This is operationally instant, like an OLTP lookup, but it draws on a data estate that spans domains no single operational system covers.

When an analyst needs to query across all theatre sessions Trust-wide, they work with what Foundry calls an "Object Set" - a filtered, aggregated view across a population of objects that supports grouping, counting, summing, and segmenting in the same way an analyst would query a warehouse, but running against the same live data the clinician is viewing.

The links and the aggregations always reflect the current state, so neither the clinician's individual view nor the analyst's population-level view is stale, and neither required extracting data from one system into another.

Actions: the part that changes everything

Object types that store data with descriptions and link to each other are valuable. A well-designed data warehouse with a good catalogue and a good data model can approximate the descriptive part - governed definitions, documented relationships, consistent naming.

What it cannot approximate is the live, navigable links between objects that users traverse in real time, or the dual-mode querying described above. To get that from a warehouse, you have to build an application layer on top of it, and at that point you are no longer comparing like with like.

What a warehouse cannot do at all is host actions.

An action in Foundry is a defined operation that a user can perform on an object type – for example: accept a referral; cancel a theatre session; discharge a patient; assign a recovery bed; escalate to a consultant.

Actions are not just buttons on a screen. They are transactions defined in the ontology itself, with validation rules, access controls, and audit trails built in. When a user performs an action, the action updates the relevant object types and all the linked relationships update with them.

This is the feature that makes FDP an operational platform rather than an analytical one. It is also what makes the Frontline-First approach possible, because actions are the mechanism by which FDP applications capture new data at the point of care, not just present data that was captured somewhere else.

Consider what happens when a theatre session needs to be cancelled. In a typical Trust today, the scheduler cancels the session in whatever system the Trust uses for theatre management. That information then has to reach other systems: the waiting list, the bed management view, the operational dashboard. Depending on how those systems are connected, that might take hours, or it might happen overnight through a batch extract. In the meantime, a waiting list manager may reassign the slot or contact a patient based on information that is already wrong, because the cancellation has not reached them yet.

In the ontology, the scheduler performs a "cancel theatre session" action. The action updates the theatre session object type, and because the theatre session is linked to the waiting list entry, the patient, the consultant, and the recovery bed, every linked concept reflects the cancellation immediately - the waiting list manager, the analyst, and the COO's dashboard all see the change at the same time. There is no overnight feed, no delay, and no reconciliation.

For analysts who need frozen reporting for board papers or national submissions, the platform also supports submission snapshots that lock the state at the end of a reporting period - the live view and the frozen view coexist.

Now consider something more important. A discharge coordinator uses an FDP application to manage the discharge pathway. They perform actions such as "confirm transport arranged"; "confirm pharmacy complete"; "confirm social care package in place". Each action creates new data on the platform, data that did not exist in any source system because no source system tracks the discharge pathway at this level of detail. The coordinator's spreadsheet used to hold this information. Now the FDP application holds it, with an audit trail, with access controls, and with live links to the patient, the ward, the bed state and the analytics layer above.

Actions can also trigger automated responses: a notification to the community team that the patient is ready; an API call to the transport booking system; an alert to the ward manager that a bed will be free. The platform supports scheduled and event-driven automation, which means actions do not always require a human to trigger them - a rule that fires automatically when a patient meets discharge criteria and initiates the coordination workflow is a different proposition from a coordinator clicking a button.

This is the point that most critics of FDP miss. They compare it to warehouses and dashboards because they are thinking about platforms that present existing data. FDP applications capture new data through actions, and that new data sits on the same platform as everything else. The discharge coordinator's "confirm transport arranged" action is as much a part of the patient record as the admission that came from the EPR. The secondary uses - such as, how many discharges were delayed by transport nationally - and the primary use - is this patient ready to go home today - are happening on the same data, on the same platform, in the same session.

The logic layer: an area to watch

There is a further capability in the ontology that FDP has not yet fully exploited in the NHS context but which has significant potential.

Palantir's description of its architecture identifies four components: data, logic, action, and security.

The logic layer is the set of business rules, algorithms, forecast models, optimisation models, and clinical pathways that sit between data and action. In a discharge pathway, the logic might determine which actions are prompted at which stage. In theatre scheduling, it might incorporate a capacity model that optimises slot allocation across surgeons and specialties. In population health, it might run segmentation algorithms that identify patients at risk of deterioration.

The logic layer allows these rules and models to be connected into the ontology alongside the data and the actions, so that AI agents and human users can draw on the same reasoning when making decisions. This is largely unexplored territory in the current FDP product set, but it is where some of the most significant operational value may sit in the years ahead.

What AIP adds to the platform

The Artificial Intelligence Platform (AIP) adds two capabilities that change what the platform can do.

The first is making analytics accessible without the traditional route through an analyst. Part 2 of this series of articles described the app called Ask FDP and its potential to change the culture of data use in Trusts. The technical reason it works is that the large language model (LLM) is grounded in the Trust's own data through the ontology, with the same access controls and audit trail that apply to every other interaction with the platform.

This is not a chatbot bolted onto a database. It is an AI capability that understands the relationships between object types and can traverse the ontology to answer questions that would otherwise require a skilled analyst and an SQL query.

The second capability is AI-FDE, or AI Forward Deployed Engineer, which provides an AI-assisted development environment powered by the latest LLMs. For professional engineers, AI-FDE accelerates their work - it can generate React applications, ontology configurations, Python scripts, and any other deliverable an engineer would normally produce by hand. For clinicians and operational staff with no engineering background, it lowers the technical barrier to entry dramatically. A discharge coordinator can describe the workflow they need and AI-FDE translates that into a working application on the platform. AI-FDE also works with Foundry's no-code features, including Workshop for building interactive applications visually, and Pipeline Builder for building data transformations without writing code.

This is not a chatbot bolted onto a database. It is an AI capability that understands the relationships between object types and can answer questions that would otherwise require a skilled analyst and an SQL query

This is the mechanism by which a Frontline-First approach scales beyond what a central development team can deliver. The Build with FDP event described in Part 2 saw clinical and operational staff building working applications in two days. The paramedic, the ward clerk, the discharge coordinator all have knowledge of their workflows that no nationally commissioned product can capture. AI-FDE lets them contribute that knowledge directly rather than waiting for someone else to build it for them.

There is also a longer-term opportunity in using AI to convert unstructured data into structured, actionable insight. Imperial College Healthcare NHS Trust developed a natural language processing tool that analyses free-text patient feedback comments, detecting sentiment and theming responses in minutes rather than days. The tool has since been adopted by nine NHS Trusts. The free text problem described in Part 1 – such as, DIALOG scores buried in progress notes, discharge letters sitting as inaccessible PDFs - is the same class of problem, and AIP on the ontology makes this kind of work architecturally simpler because the grounding, access controls, and audit trail are already in place.

A team building AI features on a freely engineered stack has to integrate the LLM externally, manage grounding manually, build audit trails separately, and worry about clinical data leaving the platform. The clinical coding AI assistant that came runner-up at Build with FDP is the AIP pattern - a small team built a clinically useful AI tool in two days because the platform already handled the plumbing underneath it.

The platform is also evolving toward autonomous agents that can orchestrate workflows across multiple steps, not just answer questions or build applications - an agent that monitors a ward's discharge readiness, identifies patients who meet criteria, and initiates the coordination workflow represents the next generation of what Frontline-First could deliver.

Why the orthodox data stack cannot do this

Anyone with a technical background will be asking why the orthodox data stack cannot replicate what the earlier sections described. The short answer is that Foundry collapses architectural separations that the orthodox stack treats as fundamental.

The standard enterprise data architecture separates the systems where things happen from the systems where things are measured.

The EPR is an example of the first type - an Online Transaction Processing (OLTP) system that records clinical events in real time, optimised for fast writes and looking up individual records.

The data warehouse is an example of the second - an Online Analytical Processing (OLAP) system that aggregates historical data, optimised for complex queries across large datasets.

In simpler terms, the app the clinician uses and the database the analyst queries are built on different technology for different purposes. Data flows from one to the other through overnight extracts and batch pipelines. This separation exists because the two workloads have different performance characteristics and historically could not be served by the same infrastructure.

Foundry's Object Storage V2 challenges this separation. It is built on a different architectural principle - data is indexed into specialised object databases through an orchestration layer (the Object Data Funnel), with indexing and querying decoupled into separate subsystems that scale horizontally.

The architecture is closer to an inverted index search engine than to a traditional relational database. It can serve both operational queries - give me this patient's current state, with all linked objects and available actions - and analytical queries - show me all patients across this Trust matching these criteria, aggregated by specialty - from the same data store, without extracting data from one system to another.

The difference is structural. A traditional warehouse join scans two full tables to find matches across all rows, but the ontology's search-around navigates from a single object to its linked objects, which is how a clinician thinks – “show me everything connected to this patient” - rather than how an analyst thinks – “show me all patients matching these criteria”.

The ontology supports both modes from the same data. This is what allows it to be both an operational workspace and an analytical platform simultaneously - a genuinely new concept for most NHS data professionals, and the reason FDP does not fit neatly into the categories people try to put it in. The ontology also supports media references, which means documents such as discharge letters and clinical images can be attached to objects as properties and accessed alongside the structured data.

Consider what it takes to build an equivalent operational capability on Azure. To create a discharge coordination product that captures new data at the point of care, you would need to wire together Azure Functions for the business logic, Cosmos DB or SQL for the data store, a custom API layer for the front-end application, Azure AD for authentication, a separate audit logging pipeline, and a manually maintained schema that describes what the data means.

Each component is mature and well-documented. But the integration is bespoke engineering for every product, and the semantic description of the data - what a referral means, how it relates to a patient, what actions are available on it - lives in your application code and your documentation, not in the data layer.

On Foundry, actions are defined in the ontology itself - the validation rules, access controls, audit trail, and linked object updates are handled by the platform. The semantic description travels with the data.

This has a direct consequence for AI. When AIP queries the ontology, it already knows what a referral is, how it relates to a patient, what properties it has, and what actions can be performed on it, because the semantics are embedded in the same layer as the data.

To achieve something comparable with Azure and Copilot, you would need to build a retrieval augmented generation (RAG) pipeline -extracting the data, writing grounding instructions that explain the schema and its meaning, managing the context window, and maintaining those instructions every time the data model changes. The semantics and the data live in separate places, maintained separately, and they can drift apart. On Foundry, they cannot, because they are the same thing.

Azure, Databricks and all the other reporting-first platforms are excellent at what they were designed to do. But they were designed within the orthodox OLTP/OLAP separation. Foundry was designed to collapse it. That is the architectural choice that makes the Frontline-First approach possible, and it is the reason I argue that FDP is not just another data warehouse with better marketing.

It is worth noting that the rest of the industry is moving in this direction, which validates the principle even if the implementations differ.

Microsoft launched Fabric IQ in late 2025, which introduces an ontology layer with entity types, relationships, and AI grounding through a unified semantic layer. Databricks has extended Unity Catalog with business semantics and AI agents. Both are building semantic layers that bring data and meaning closer together, and Gartner now treats universal semantic layers as critical infrastructure.

But neither yet offers what Foundry has in production - defined actions that create new data through transactions in the ontology, with validation rules, access controls, audit trails, and linked object updates handled by the platform. The semantic layer is necessary but not sufficient for Frontline-First - without actions, you have a smarter way to understand data, not a platform that captures it at the point of care. That is the gap the competitors have not yet closed, and Foundry has been in production with it for over a decade.

How this works across organisational boundaries

The architecture described so far operates within a single Trust's FDP instance. But the Frontline-First approach requires data to connect across Trusts and care settings. The mental health patient who attends A&E at the acute Trust needs their community mental health data to be visible and actionable through the same platform.

Foundry achieves this through shared spaces.

Each Trust has its own private space with its own ontology. When two or more Trusts want to collaborate across organisational boundaries, they create a shared space with a shared ontology. Each organisation controls which data it shares - the shared space provides the common ground where cross-organisational products operate.

One NHS Trust Group has already done this in production - they created a shared space across two Trusts, with a single cross-Trust patient tracking list that is live, with no issues of lag or latency. They are in the process of re-platforming all their core products into the shared space so that across both Trusts they run a single theatres product, a single Optica, and a single set of operational products, backed by permissions that control whether users see one organisation's data or both. Additional workflow features handle the practical realities, such as ensuring patients are not booked into the wrong site.

This is not a central hub pulling data from the periphery. It is a peer-to-peer collaboration model where each Trust retains control of its own data and the shared space provides the integration layer. The shared ontology ensures that the data model is consistent across both organisations, so a product built in the shared space works for both Trusts without separate configuration. This is the architectural mechanism that makes the cross-setting collaboration dimension from Part 2 possible at scale.

None of this removes the practical challenge of integrating Foundry with the existing Trust application estate. Getting data in and out of the platform, connecting to EPRs and the dozens of other systems a Trust runs, is an area the programme is actively working on and one where the experience of early adopters will be critical.

Can EPR implementation solve the same problems?

One concern raised by senior digital leaders is that the problems described in Part 1 are not architectural failures requiring a new platform, but implementation failures that better EPR deployment would solve. There is some truth in this.

Implementation quality matters enormously, and the same EPR system can be well or badly implemented. But even a perfectly implemented EPR cannot make a tool built in one Trust available to every other Trust without rebuilding it. EPR convergence programmes can link data across organisational boundaries within their footprint, but this is limited to Trusts that have adopted the same system and does not extend nationally. It cannot enforce semantic consistency across 220 Trusts running different EPR systems with different configurations.

And while some EPR suppliers are extending into operational territory with their own features for discharge tracking, bed management, and clinical coordination, these capabilities remain local to each Trust's implementation and are not portable across the 220 Trusts running different EPR systems with different configurations.

FDP does not replace the EPR. What it does is provide a layer alongside it where operational products can capture data that the EPR was never designed to hold

There are also entire data domains that will always be out of scope for any EPR, notably workforce and finance, which are critical to operational management but are not clinical data. National portability, semantic consistency across 220 Trusts, and coverage of non-clinical domains like workforce and finance are architectural properties of a platform, not implementation quality issues, and the Frontline-First approach cannot work without them.

FDP does not replace the EPR. What it does is provide a layer alongside it where operational products can capture data that the EPR was never designed to hold, in a structured form that is nationally consistent and immediately available to every other product on the platform. Trusts can choose to keep the EPR as the designated clinical record. FDP provides the operational data estate that the EPR was never asked to be.

The platform supports multiple writeback methods including API, HL7, and FHIR - the constraint on writing data back into the EPR is not technical but commercial. To date, the programme has not achieved sufficient traction with EPR providers to establish routine writeback into the clinical record. Trusts who are awaiting this functionality should understand that the barrier is supplier engagement, not platform capability.

FDP does not introduce divergence from the EPR. It replaces unaudited, ungoverned, invisible divergence with audited, governed, visible divergence. That is a net improvement in every dimension, even if it is not the clean single-record picture that information governance frameworks assume.

What the platform does not do well yet

Foundry is structured in a genuinely novel way and this is what makes it uniquely suited to the Frontline-First approach, but it does not make it a perfect platform. Teams I have worked with who have adopted Foundry have come across limitations that they have found frustrating, and it is likely that others will too.

The general frustration is about a tension between two types of analytical work.

Foundry prioritises users who are building repeatable, reusable analytical processes, an approach actively encouraged in NHS England under the Reproducible Analytical Pipelines (RAP) framework. For this kind of work, the platform is excellent - governed, auditable, shareable. But a large proportion of what analysts do day-to-day is not RAP. It is exploratory - quickly viewing a dataset, sharing rough cuts with colleagues, testing an approach before committing to it.

The platform makes the first type of work excellent and the second type harder than it needs to be. Getting data in takes more effort than analysts expect - getting data out is harder still. Analysts who needed spreadsheet functionality found it lacking, though the platform does support R, Shiny, and more recently SQL Studio, and Trusts can connect external tools like Power BI and Tableau. NHS England restricted some of this on its own instance, but individual Trusts make their own decisions.

Beyond the analyst experience, there were engineering challenges. Foundry's branching model allows developers to branch live data the way a software engineer branches code, test changes against real-world data, and merge back.

The national FDP team embraced this because it allowed them to move fast. But engineers who were new to the platform, many of whom had spent years managing data flows from Trusts to NHS England, found it deeply uncomfortable. They were accustomed to long-established best practices - test data, separate development, testing, and production environments, careful promotion between them. Branching real-world data on the master branch felt reckless by those standards.

Some teams tried to reconcile the two approaches by setting up test data and then branching it, which satisfied neither philosophy - the test data could not guarantee coverage of the edge cases that would break a pipeline in production, and the branching added complexity without the benefit of working against real data.

Foundry does support formal environment separation, but Palantir's engineers discouraged it because it added significant overhead to the development process. The result was a period where neither approach was followed cleanly, and teams were caught between two engineering cultures without a settled way of working.

None of this invalidates the architectural case, but it does mean that the journey from architectural promise to operational reality is harder and slower than anyone would like.

A change of this scale cannot be delivered by a national programme alone, nor Trusts developing FDP in isolation. It requires cooperation across the system - Trusts, integrated care boards (ICBs), and the national team learning together, adapting together, and being willing to change how they work.

The pace at which Frontline-First becomes real will be determined by the level of cooperation and willingness to adapt across all of these organisations.

Why "just an expensive data warehouse" misses the point

One of the most persistent criticisms of FDP, repeated in parliamentary debate and in media coverage, is that it is "a very overpriced data warehouse".

If you assess FDP as a warehouse, this is a defensible view. The dashboarding is limited. The analytical tooling is less mature than a well-configured Power BI or Tableau environment. For analysts whose entire frame of reference is the analytical layer, FDP looks underwhelming and expensive.

But the point of this article is that FDP is not primarily a warehouse. It is an operational application platform where the data, the semantics, the applications, and the actions all live in the same place. Calling FDP an expensive data warehouse is like calling a smartphone an expensive calculator. It is technically true that both can do arithmetic, and it completely misses what makes the smartphone worth having.

What comes next

The next article explains why the NHS needs both a shared data model and the consistent products to enforce it, and why their combination is the most important asset in the programme.