logo

The NHS Federated Data Platform Memo

A proposal for a policy memo. Comments welcome.

Cover note

The Problem: The NHS is handing Palantir a monopoly over managing its data. It needs better tools but it has chosen to lock-in to a proprietary solution.

Core tension: Operational urgency versus strategic sovereignty.
Goal for the memo: Show a path to maximise public value & minimise vendor-lock in.

Key words to know
Foundry: Palantir’s cloud platform for managing, visualising, and acting on data.
FDP: Federated Data Platform: Rebranding of the Foundry platform for the NHS.
CDM: Canonical Data Model: The standard shape that NHS data should be in.
ICB: Integrated Care Board: NHS sub-divisions that fund GP & Hospital care in a region.

Context
Some hospitals are still managing waiting lists on Excel spreadsheets. To make a diagnosis and schedule an appointment, doctors have to find data split across dozens of siloed IT systems. Errors happen daily; people wait longer for cancer diagnoses and operating theatres sit idle.

The Federated Data Platform (FDP) tackles the problem. It lets hospitals merge data from separate systems and build and share the missing apps they need to catch those errors and make decisions. It offers a single source of truth for operational data. Each hospital has limited capacity to do complex technical work. Foundry lets hospital staff build new apps and dashboards using proprietary, low-code tools.

Apps built that way are the hardest to move to another provider. The FDP contract is up for renegotiation in 2027. Once the NHS depends on it, Palantir can name its price. Distrust of Palantir has slowed the rollout. There is an argument for aborting the project completely, but as a policy memo to the NHS board today, that suggestion would likely be ignored.

So the proposal is to lean into it. Let hospitals build what they need. Find the apps and dashboards that actually get continued daily use across multiple sites. Extract just those parts as nationally owned alternatives. Use Foundry for exploration. Let it help identify the data integrations and interfaces that work. But once an app proves truly useful we don’t need the full power of a general purpose data platform to keep it running.

The NHS Federated Data Platform Memo

To: NHS England Executive board
Subject: FDP - Mitigate vendor lock-in. Maximise public value.

The NHS faces a conflict between operational urgency and strategic sovereignty.

Hospitals desperately need better tools to see and act on their data. Mapping the raw data from each hospital to the Canonical Data Model (CDM) is a huge task. The Foundry Platform provides polished tools that let each hospital do that work for themselves.

The strategic risk is that a successful rollout hardwires essential operational functions to Palantir’s proprietary tools. The current architecture creates dependency. The FDP contract expires in 2027 at which point Palantir could name its price. We need to get value from the Foundry platform, but we must avoid creating a monopoly over NHS data.

Owning the Canonical Data Model does not protect us. A marketplace of apps built on top of it and an ever growing pool of data being copied into Foundry make the idea that we could move to another provider less and less plausible.

We recommend a “Pathfinder Strategy”: use Foundry for what it is good at as a data exploration environment and app prototyping platform and implement a strict “Graduation Process”. Identify the high-value data integrations and apps that actually get sustained daily usage. Once a workflow reaches a critical threshold of national utility, it must be rebuilt as open Digital Public Infrastructure (DPI).

This allows us to divide and conquer the problem. Hospitals continue to rapidly map their siloed data to the CDM and build the missing apps they need. The Foundry platform usage analytics will show us what is delivering value. Rather than leave that work in a general purpose data platform, we extract just those clearly defined key components. This approach leverages the “pay-as-you-go” nature of the FDP contract to maintain fiscal control as well as strategic autonomy.

The Problem: Speed versus Sovereignty

Operational Urgency: Hospitals are drowning in siloed data. They lack engineering capacity to build bespoke integration layers. Foundry resolves this with out-of-the-box tools (Pipeline Builder, Slate) that allow them to link datasets and build dashboards rapidly.

Strategic Risk: As hospitals build on Foundry, the cost of switching rises. We depend on Palantir’s tools to collect data from our systems, transform it, visualise it, and act on it. We plan to grow an ecosystem of apps that build on top of it. As the ecosystem grows, the cost of migrating becomes prohibitive.

The Canonical Data Model: The NHS ownership of the CDM doesn’t currently prevent lock-in. The only implementation of the CDM is in Foundry. External apps, when they exist, must rely on Palantir’s specific API implementation. Apps built within Foundry (e.g. Cancer360) do not use that API and are tightly coupled to the platform.

Key facts

Adoption is high: With 41 ICBs and 150 hospitals signed up, the roll-out phase has succeeded.1 Resistance from privacy groups remains, but strong demand for better data visibility has driven uptake in spite of it.

Capacity is low: It is unclear if hospitals have access to the engineers required to build open-source alternatives from scratch. The FDP is interesting because it works now.

Precedent of Cost: The recent £25m “Transition & Exit” contract awarded to Plantir to migrate the NHS COVID apps from Foundry to the new FDP Foundry account shows that even a minor platform migration can incur significant costs.2

Contractual leverage: The FDP contract is consumption based. We pay for what we use. This is our primary lever: The £330m figure is a predicted usage estimate, not a committed amount.3

What happens if we do nothing?

We continue the current rollout strategy, strongly encouraging deep integration and usage of all Foundry’s tools to maximise operational gains without a credible exit strategy.

The Risk: Vendor lock-in. By 2027 critical workflows will exist solely inside Foundry. Replacing the system would cost millions and take years. We would be a captive customer. There will be an incentive to keep ever more data inside foundary and we will pay a premium for every bit.

We recommend two ways of intervening that balance strict governance with rapid innovation.

Recommendation 1: Open Standards Mandate

We should encourage “code hygiene” within Foundry. Where local capacity allows, hospitals should be directed to write transformation logic in portable Python or SQL rather than relying on the proprietary low-code tools to generate it.

The Risk: “Stalling out” - If we enforce open standards too rigidly (e.g. banning low-code tools) we raise the barrier to entry. Hospitals with less capacity may disengage, and the rollout could stall.

The trade off: We accept that some value captured in proprietary tools is better than non-usage. The more we push open standards, the easier extraction becomes; the less we push them, the less we put in the way of adoption. We should bias towards adoption now to realise operational gains from integration work quickly.

Recommendation 2: The “Pathfinder” Strategy

Use Foundry as a rapid prototyping engine to find the path, then pave that path with open infrastructure.

Encourage proliferation: Help hospitals use the tools to solve immediate problems. We need to discover what data integrations actually matter.

Find the value: Monitor dashboard and app usage in Foundry. When an application achieves high adoption (e.g. daily usage by >20% of hospitals) it is flagged for “Graduation.”

Graduation: The NHS (or a delivery partner) uses the FDP tools to quickly identify the data sources and integrations that the successful app depends on, and rebuild it as a Digital Public Infrastructure (Open table formats, standard APIs, commodity web apps), reducing ongoing Foundry usage costs and owning the app logic.

RiskImplicationMitigation
Duplication of Effort“Graduating” means building a tool twice: once in Foundry, once in open code.The cost of rebuilding proven software is far lower than the cost of building speculative software that fails. We only rebuild what we know works.
Migration FrictionHospitals may not want to switch from a Foundry tool to a national tool.The “Graduated” tool must be better and cheaper. We can incentivise the switch by subsidising any cost to move to the open tool.
No clear winnersThere are few integration patterns that are useful for other hospitals, so nothing meets the graduation threshold.If the level of divergence across all hospitals is so high that we can’t find any common integration patterns then Foundry may be the best tool for the job. This proposal triggers no extra work in this case.
Vendor RelationsPalantir may resist a strategy designed to reduce NHS dependence.The contract is signed. As a “pay-as-you-go” customer, we are exercising our right to manage consumption. Keeping Foundry as an “innovation layer” grants them a long term, less mission critical role.

Summary

We recommend pushing an “Open standards mandate” to capture the value in a portable form and adopting a “pathfinder” strategy for mission critical apps. By using Foundry for exploration (finding the paths) and strictly graduating successful products to NHS owned open infrastructure we achieve:

  1. Speed: We get any immediate benefit of the FDP rollout.
  2. Sovereignty: We own the code for our most critical high-volume operations.
  3. Leverage: When contract negotiation begins again in 5 years, we hold the option to walk away because our core operations are no longer dependent on the vendor.

We will be a smart customer, maximising the utility of the investment while securing a credible exit strategy.

Sources

  1. NHS Federated Data Platform uptake and benefits - https://www.england.nhs.uk/digitaltechnology/nhs-federated-data-platform/impact/fdp-uptake-and-benefits/

  2. Palantir Foundry Transition & Exit Contract - https://www.contractsfinder.service.gov.uk/Notice/d1df0a11-60ad-4fa5-b375-986b972bc006

  3. Federated Data Platform and Associated Services Contract - https://www.contractsfinder.service.gov.uk/Notice/0f8a65b5-23a2-4294-abb1-a7fd8efb3ad0

Sources for cover note and futher reading

  1. “North Cumbria’s booking and scheduling processes relied on basic excel spreadsheets and manual data entry.” - https://www.england.nhs.uk/long-read/staff-time-savings-and-more-surgeries-for-patients-in-north-cumbria

  2. “less anxious waiting for patients and faster access to life-saving treatment” - https://www.england.nhs.uk/long-read/cancer-360-streamlines-patient-pathways-across-nhs-trusts

  3. DHSC Briefing paper on the Federated Data Platform, 2023 - https://data.parliament.uk/DepositedPapers/Files/DEP2023-0696/23083011.docx

  4. Palantir Foundry Developer Documentation - https://www.palantir.com/docs/foundry/ontology/overview/

  5. NHS Chief Data and Analytical Officer Network open letter to Ming Tag about FDP - https://www.aphanalysts.org/cdao-network-news/chief-data-and-analytical-officer-network-position-on-the-federated-data-platform-fdp/

  6. Apperta Foundation: Defining an Open Platform (what better looks like) - https://apperta.org/assets/Apperta_Defining_an_Open_Platform.pdf

  7. The CDM API is tied to Palantir’s Foundry platform - https://github.com/nhsengland/fdp-canonical-data-model/issues/2