The FDP debate is looking in the rear-view mirror – what’s around the next bend?

Understanding the cutting edge of AI in healthcare

The first Nature paper describes MIRA, an agentic AI system designed to operate inside a hospital emergency department. It takes a patient history, queries results, orders tests, prescribes medications, and produces a full end-to-end management plan. Tested against 500 real emergency cases, MIRA achieved 87.8% diagnostic accuracy compared with 78.1% for board-certified physicians. It correctly ordered surgical procedures like appendectomies at a rate of 53.5% versus 38.3% for the physicians. Of 468 medications it prescribed, 99.8% were correct for indication, safety, allergy interactions, and kidney dosing.

The second, called AMIE, was built for longitudinal outpatient care. Across 100 patients and three visits spanning multiple specialties, it produced management plans rated by independent assessors as superior to those of 21 board-certified primary care physicians. By the third visit, AMIE’s plans were rated appropriate 98% of the time versus 81% for the physicians. Its treatment precision was 95% against 67%.

Eric Topol, one of the most cited medical researchers in the world, described these results as moving medical AI beyond narrow diagnostic support into full autonomous clinical management. Both systems were tested in controlled research settings with curated data and text-only interaction. But they demonstrate where clinical AI is heading, and the speed at which it is arriving.

Why this is not just a reporting problem

The instinctive reaction from experienced NHS digital leaders will be: we could achieve something similar if we connected our existing systems properly. Pull data from the EPR, the labs, the monitors, score it, alert a team. That’s integration, not a new platform.

That reaction is understandable. It describes only half of what these systems do.

MIRA uses 11 different tools and chooses from more than 85,000 action options. It orders blood tests, imaging, and medications. It triages for admission. It prescribes specific antibiotics adjusted for kidney function and allergy history. Each of those is an action written into a clinical system, not a report displayed on a screen.

In an NHS Trust, executing those actions means writing simultaneously to the EPR, the pharmacy system, the pathology order comms, and the patient administration system. That requires a unified operational data platform where the patient, their medications, their results, their ward location, and their care plan exist as linked objects that the AI can both read from and write back to.

A data warehouse is read-only by design. A shared care record provides a view of the patient but has no write-back and no development environment. An EPR can act within its own boundaries but cannot reason across data from systems it doesn’t own.

Tampa General Hospital in Florida demonstrates what happens when this distinction is understood in practice.

The Tampa example, and why EPRs couldn’t solve it

Since August 2022, Tampa General’s Sepsis Hub, built on Palantir’s Foundry platform (the same underlying technology as FDP), has monitored roughly 1,000 patients in real time. It pulls together data from the electronic patient record, lab results, clinician notes, and bedside monitors into a unified patient object model. When the system detects early signs of sepsis, it doesn’t just alert clinicians. It triggers a structured rapid response workflow, and patients receive antibiotics within an hour. The hospital estimates 886 lives saved, a 68% reduction in 48-hour sepsis mortality, and a 30% reduction in the length of stay for sepsis patients.

Tampa already ran Epic, one of the world’s most capable EPR systems. Epic has its own built-in sepsis prediction model. That model was independently validated at an AUC of 0.63, which external researchers described as substantially below Epic’s own claimed performance of 0.76 to 0.83. Tampa replaced Epic’s native sepsis alerting with the Foundry-based Sepsis Hub because the EPR’s own product could not combine data sources outside Epic’s walls, could not iterate fast enough when the model underperformed, and could not support the rapid response workflow that turned early detection into clinical action within an hour.

The operational loop at Tampa is not detect-and-report. It is detect, alert with context, act, record the outcome back into the system, and recalibrate the score based on what happened. That loop requires the platform to read from clinical systems and write back to them through a shared data model. It requires the ontology’s representation of actions, not just records: what should happen next, triggered by what is happening now. Tampa now runs more than 60 operational products on the same platform because each one can be built on the same unified data layer.

Their chief digital and innovation officer described it as “the operational backbone, or operating system, of our health system”. That is what I have called the frontline-first argument. An operational platform where clinicians act on data in real time.

The portability problem

An experienced CIO could build something resembling Tampa’s sepsis system locally, using their own integration engine, their own data feeds, and their own clinical team. Some already have at considerable cost and effort.

But it would work only in their Trust. Every local build depends on local integration patterns, local data formats, local coding practices. Scaling that to a second Trust means rebuilding the integrations from scratch, because the data model is different.

FDP solves this. The Canonical Data Model standardises how patients, encounters, results, medications, and actions are represented across every Trust on the platform. The ontology provides the semantic layer that links those objects together and defines how actions flow between them.

The development environment means a product built at one Trust runs at another without being rebuilt. And because every Trust instance shares the same architecture, AI interacts with the data consistently everywhere. A sepsis product built at one Trust can in principle be deployed at 136 others without rebuilding the data integrations, because the data model, the product interfaces, and the way AI interacts with the ontology are consistent across every site.

Portability does not eliminate the need for local implementation, change management, and operational engagement. But it removes the need to rebuild the integrations from scratch at every site, which is where most cost and delay currently sits. At 137 Trusts, building bespoke integrations at each site is not viable. A shared, governed platform is the only way to make clinical AI portable across the NHS at the speed these developments demand.

The data foundation, not the platform

Neither MIRA nor AMIE was built on Foundry. Both used standard clinical data formats: FHIR, ICD-10, SNOMED-CT, published clinical guidelines. The AI layer is not dependent on any specific platform. What it is dependent on is structured, standardised, real-time clinical data from multiple sources, available in a form it can both reason about and act on.

In the research settings where these systems were tested, that precondition was a given. The data was already curated and accessible. The researchers could focus on the AI because the integration problem had been solved for them before they started.

The question for the NHS is not which platform to use. It is whether any platform exists that solves the integration problem at national scale, with a governed data model, real-time connectivity to clinical source systems, the ability to write back actions as well as read data, and an AI layer that can reason across the unified dataset.

Foundry’s AIP capability, which has driven much of Palantir’s recent commercial growth, provides exactly this: an AI layer that operates directly on the ontology rather than being bolted on afterwards. The Canonical Data Model that sits at the heart of FDP is NHS-owned intellectual property, published openly on GitHub, and could in principle be reimplemented on a different platform. But no one has built that alternative. The only operational implementation across 137 Trusts is the one Parliament is currently debating whether to abolish.

The NHS data gap

Walk into any NHS trust and you will find clinical information distributed across 30 or more formal IT systems. The EPR holds some of it. Pathology, radiology, pharmacy, maternity, theatres and community systems each hold their own slice. Many of these systems do not talk to each other in real time. They use different data models, different coding practices, and have no common master or reference data linking a patient, a clinician, or a ward across systems.

Alongside this formal landscape sits an informal layer that no one has audited. Spreadsheets tracking patient cohorts. Whiteboards listing today’s discharges. Printed patient lists carried between meetings. Access databases recording outcomes. Shared drives with clinical data that has no access controls, no audit trail, and no connection to any other system.

In a live NHS trust, the data integration problem has not been solved. Progress has been made over 25 years through HL7, FHIR, shared care records, and local integration engines, but none of these efforts has produced a single national operational data model with common master data, shared reference data, and a consistent way of representing clinical objects across organisations. FDP’s ontology and CDM represent the first time the NHS has had a governed, portable model that does this.

Without that foundation, deploying agentic AI means solving the same integration problem independently at each of 137 trusts, with different EPRs, different coding practices, and different local systems. The pattern of NHS digital programmes from Connecting for Health onwards suggests exactly that outcome.

Change management is not the counterargument, but the reason

The most thoughtful objection to all of this comes from experienced NHS digital leaders who argue that the problem is not technology but change. Invest in helping clinical teams use what they already have, the argument goes, and the spreadsheets and whiteboards will disappear without a new platform.

There is truth in this. A trust implementation lead described to me how the same FDP theatre scheduling product, deployed to two hospital sites within the same trust group, produced strong improvement at one site and a slight decline at the other. The difference was entirely organisational: leadership quality, team structure, willingness to redesign processes around the new tool. Technology without change management fails. That has always been true and will remain true through the AI transition.

But the argument is incomplete because it assumes the existing systems can support the change that’s coming. You cannot invest in change management for AI-driven clinical products when the data those products need is fragmented across systems that don’t talk to each other. The NHS has a painful history of building platforms and assuming adoption would follow. FDP must not repeat that pattern.

The NHS also cannot afford to wait this out. Its workforce is shrinking, not growing. ICB analytical teams have lost half their capacity in the past year. The government’s answer to the clinical capacity shortfall is AI deployment. That answer depends on a data foundation that most trusts have not built. Every year a trust delays is a year in which it runs with fewer staff and without the tools that could compensate. The infrastructure and the change investment need to be built together.

The cost of delay

The NHS is so far behind the technology curve that basic infrastructure failures still dominate. The Health Secretary admitted earlier this year that three trusts still use fax machines. While Tampa General is already saving lives with AI-driven sepsis detection built on this same technology, parts of the NHS are managing patient flow with tools that predate the internet.

The consequence of this gap is measured in lives. Sepsis kills approximately 48,000 people a year in the UK. The UK Sepsis Trust estimates that around 25% of those deaths are preventable with timely diagnosis and appropriate treatment, precisely the kind of early detection and rapid response that Tampa’s system delivers. The gap between Tampa’s outcomes and the NHS’s comes down to whether clinical data exists in a structured, connected, governed form that AI can both reason about and act on.

For NHS digital leaders, the question is not whether this is coming. It is whether your Trust’s data infrastructure will be ready when it arrives, or whether your clinical teams will be trying to plug an agentic AI system into 30 disconnected systems and a whiteboard. If you do not know the answer, start by asking three questions: what operational data infrastructure does your Trust currently have and where are the gaps? What clinical information are your staff managing outside formal IT systems, and who owns the risk? And what is your trust’s plan for being ready when AI-driven clinical products move from Nature papers to operational deployment?

Tom Bartlett is the founder of Bartlett Data Ltd and former deputy director of data engineering at NHS England, where he led the approximately 150-person engineering team that built the national FDP products.