Inside FDP – part 2: Delivering on the NHS vision for data
In the second of an exclusive series of articles by the former deputy director of data engineering at NHS England, we examine the key elements of the data architecture that supports the Federated Data Platform programme
Inside FDP is an exclusive series of articles written by the former deputy director of data engineering at NHS England, Tom Bartlett, who led the 150-person team that built the Federated Data Platform (FDP), the controversial Palantir-supplied system linking data across the health and care service. His insights into the challenges facing NHS data, and the solutions available to resolve them, make essential reading for anyone who wishes to understand what’s really happening with FDP in the NHS. This is part 2 of the series - read part 1 here: Inside FDP - Understanding the problems facing NHS data.
For decades, NHS data investment has followed a reporting-first approach. Leaders want visibility into one of the largest organisations in the world, for legitimate reasons, at a time when the pace of technology has been extraordinary. They have poured investment into back-office data teams - expensive engineering and analytical staff, expensive software, expensive consultancies.
But they have hardly invested in frontline data capability. Some NHS Trusts have retained a small team to tailor the electronic patient record (EPR) and add bolt-on modules for popular use cases, such as ward observations, but that was never going to address the scale of the problems created by retrofitted data plumbing.
The result is an estate with thousands of manual cross-organisational data flows. Entire national programmes are dedicated to burden reduction and data flow transformation, programmes that exist solely because the current model creates the burden in the first place.
Analytical infrastructure is duplicated at every level of the system. And the cost of shadow IT is absorbed invisibly by clinical staff time that should be spent on patients.
None of this was obvious at the time those decisions were made. Technology was moving fast, the demands on the NHS were relentless, and it was genuinely hard to step back and see that the reporting-first approach was creating the very problems it was being asked to solve.
Data vision
The vision that NHS England's leadership wanted to realise, but rarely articulated in public, was to stop treating data as something extracted from the frontline and start treating it as something that serves the frontline - this is what I call a Frontline-First approach.
My understanding of that vision can be defined through seven dimensions of value, each with a direct impact on what patients experience: operational tools at the point of care; frontline participation in development; enrichment of data at the point of need; AI-driven analytics at the frontline; live integration through the platform; cross-setting collaboration; and scalable portable products available to every Trust. The first two are the foundation. The rest build on them.
NHS data architecture - how FDP supports the seven dimensions of data value
1. Operational tools at the point of care
Picture the scene. A discharge coordinator in a busy acute Trust is managing 30 patients across four wards. Their tool is an Excel spreadsheet, updated manually after each phone call to the ward, each conversation with the family, each check on community services availability. Nothing is linked to the EPR. Nothing is visible to the bed management team. Nothing feeds the board’s dashboard. The data exists only on that spreadsheet and in the coordinator's head.
Now picture the alternative. Instead of the spreadsheet, an FDP application tracks the patient through the discharge pathway, prompts the right actions at the right times, and integrates with bed management. Instead of the theatre scheduler working from a whiteboard, an FDP application holds the session list with live links to the waiting list, the surgeon's availability and the equipment booking.
The data captured by these tools enters the formal data estate for the first time, visible to the analyst, the board dashboard and the commissioner, rather than locked in a local file nobody else can see.
The cost of leaving these workflows on shadow IT is real. A delayed discharge costs a Trust roughly £400 per day in excess bed days. Every unnecessary day in hospital increases the risk of healthcare-associated infection, deconditioning, falls, and loss of independence, particularly for frail elderly patients. Optica, the FDP discharge application, has delivered a 28% reduction in average delay days across adopting Trusts. The patient impact? They get home sooner, to a more therapeutic environment, with lower risk of hospital-acquired harm.
2. Frontline participation in development
These tools do not have to be built centrally by NHS England. The platform allows frontline teams, data engineers working alongside clinicians and operational staff, to build their own applications for their own workflows. The nationally developed products like Optica and the Care Coordination Solutions are the starting point, not the ceiling. A Trust team that knows its discharge pathway better than any national programme ever could, can build an application that fits that pathway precisely, capture data that would otherwise live on a spreadsheet, and then share the application with other Trusts through the Solution Exchange.
Foundry – the Palantir software at the heart of FDP - includes no-code tools for building applications and data transformations without engineering skills. On top of this, Palantir's AI capabilities allow clinicians and operational staff to describe what they need in plain language and have the platform generate a working pro-code application. Part 3 of this series explains how this works in more detail.
For CIOs managing development backlogs that stretch years into the future, this is a route to clearing demand that traditional software development cannot match.
The patient impact? The gap between an operational need being recognised and a working tool being available shrinks from months or years to days or weeks. This capability will need quality assurance and governance as it scales, because frontline-led development without standards risks creating a new form of technical debt - but the answer is to govern it well, not to prevent it from happening.
3. Data enrichment
This is enrichment [of data] by reasoning, not just enrichment by visibility, and it represents a step change in what a data platform can do for a clinician at the point of care
Tom Bartlett
Once a clinician is working through an FDP application rather than a disconnected EPR, the platform can enrich the data they see with information from elsewhere in the system.
This is the logic layer - the platform does not just store data, it connects it and surfaces what is relevant at the moment a decision is being made. The clinician's field of view expands beyond what they personally know and what is in front of them to include what the system knows.
A clinician considering an onward referral can see that the receiving service has a six-week wait while an alternative has a two-week wait, and can make a better decision for the patient in the room.
A discharge coordinator can see that the community team has already arranged a package of care, rather than duplicating the call.
A consultant completing a procedure record gets an immediate comparison - consultants with your case mix at similar Trusts achieve a complication rate of X, yours is Y.
A mental health clinician reviewing a patient can see that the same patient attended A&E twice last week, information that sits in a different organisation's data but is now visible through the platform.
In every case, the act of recording stops being a bureaucratic overhead and starts being a moment where the clinician learns something useful. Good data becomes a by-product of useful work rather than a chore imposed from above.
But enrichment is not just about making more data visible. It is about applying logic to the data in real time.
If a patient has a high frailty score and three or more A&E attendances in the last 90 days, surface them for proactive review before the next admission.
If a discharge is planned but no community care package is in place, flag it before the patient leaves the ward.
If a prescribed medication conflicts with an allergy recorded in another care setting, send an alert.
None of this is new to business intelligence (BI) teams. They build these alerts already, in dashboards, in near-real-time reports, in exception lists emailed to service managers. But the clinician still has to work across the BI report, the EPR, and the shadow IT spreadsheet to act on what the alert tells them.
What changes with a Frontline-First approach is the level of integration - the alert is inside the operational tool, at the point of the decision, connected to the action the clinician needs to take. The logic and the workflow are in the same place.
As the platform matures, large language models (LLMs) will extend this further. Where rule-based logic handles known patterns with defined thresholds, LLMs can reason across unstructured and structured data together, identifying that a combination of symptoms, test results, and medication changes over several months resembles a deterioration pathway that no single data point would flag.
This is enrichment by reasoning, not just enrichment by visibility, and it represents a step change in what a data platform can do for a clinician at the point of care.
The best existing example of enrichment for clinicians illustrates what changes. The National Consultant Information Programme (NCIP), part of Getting It Right First Time (GIRFT), provides consultant-level benchmarking across 12 surgical specialties. It is clinically led, well designed, and widely used. But it is a reporting-first approach to enrichment.
The consultant visits a separate portal, reviews quarterly data drawn from Hospital Episode Statistics, and takes the insight back to their practice. On FDP, the same enrichment would be integrated into the operational tool the consultant already uses, updated in near-real-time rather than quarterly, and extended beyond surgical specialties to mental health, community, primary care and ambulance through the Canonical Data Model (CDM). The difference is not the insight - it is when and where the clinician receives it.
The patient impact? Clinicians make better decisions because they see what the system knows, not just what is in front of them. Unnecessary referrals are avoided. Duplicate work is eliminated. Variation in clinical practice is surfaced and addressed in real time rather than discovered years later through audit. Harm is prevented by logic that connects data across settings before the clinician has to ask.
4. AI-driven analytics at the frontline
Today, when a ward manager wants to know their current caseload, or a service lead wants to understand their team's referral patterns, or a clinical director wants to see how their specialty compares to peers, they send a request to the BI team. The BI team, already stretched, adds it to the queue. The answer comes back days or weeks later as a spreadsheet or a static report. By the time the frontline has the information, the question has moved on.
A new tool in development at NHS England called Ask FDP changes this. Using large language models connected to the Trust's data through the ontology, frontline staff can query the data estate in plain English and get straight answers without going through the BI team.
What is my caseload? Which patients on my ward have been here longer than seven days? How does our readmission rate compare to the national average? These are not complex analytical questions. They are the everyday operational queries that currently consume a disproportionate amount of BI team capacity.
There is a further shift that matters. When a BI team responds to these queries today, they typically produce a set of charts or data tables that require further interpretation. Is that variation genuine or within the range of normal fluctuation? What is driving the trend? The person who asked the question is left looking at 30 graphs wondering what is going on.
Ask FDP does not just return the data. It synthesises the analysis, explains what the numbers mean, and flags what requires attention. Analytical skills are in shorter supply than BI dashboards. An AI-powered analyst that can interpret as well as present is a step change in how quickly the frontline can act on what the data is telling them.
The consequence is a cultural shift in how data is used.
The BI team can pivot away from ad-hoc reporting and toward the higher-value work of building Frontline-First tools, maintaining data quality, and developing the ontology.
The frontline gets instant, informed answers from an AI analytical capability that knows the Trust's data.
The culture moves from manual analysis of data provided by a busy central team to self-service intelligence at the point of need. The patient impact? Clinical decisions are informed by data in real time rather than waiting for a report that may arrive too late to matter.
5. Live integration
In the current architecture, data moves between layers through overnight extracts, monthly submissions, and manual uploads. A change in one system is not reflected in another until someone runs a process to move it.
Within a Foundry tenant, the ontology changes this. Data on the platform is connected in real time.
When a theatre session is cancelled, every linked concept updates immediately - the waiting list entry, the bed allocation, the consultant's schedule, the utilisation dashboard. There is no overnight feed, no reconciliation, no delay. For an average Trust with over 250 different clinical teams, this means all of those teams are working from the same live picture of the organisation for the first time.
This matters for the timeliness problem described in Part 1 of this series. When data is live on the platform rather than extracted in batches, the information available to the clinician, the manager and the analyst is the same and it is current. Cross-Trust integration requires additional architectural mechanisms which are described in Part 3, but the direction of travel is clear - from monthly extracts and manual submissions toward a connected, live data estate.
The patient impact? Decisions are informed by data that reflects what is happening now, not what happened weeks or months ago.
6. Cross-setting collaboration
A mental health patient turns up in A&E. In the current model, the A&E clinician has no way of knowing about the community mental health history unless they happen to have access to the shared care record and think to look.
On FDP with the national Canonical Data Model, the mental health data and the acute data sit on the same platform with the same definitions. New FDP apps that are bespoke to the intersection of those care settings become possible at a larger scope than point-to-point record sharing. But visibility is only the starting point.
In this hypothetical FDP app, the A&E clinician can also see capacity in the receiving mental health service, request an admission informed by the full clinical picture, and have that request received and accepted by the ward team with all the relevant detail attached.
The same applies to out-of-area placements, where a receiving Trust currently has no visibility of the placing Trust's clinical intent, risk assessment, or care plan.
This is not just data sharing. It is clinical teams collaborating across organisational boundaries through a shared platform, informed by consistent data, in real time. The patient impact? They are treated by clinicians who know their history and can coordinate their care across settings rather than working in the dark.
7. Scalable, portable products
Over time, the first six dimensions produce something the NHS has never had - a growing library of operational tools, built by the people closest to the work, available to any Trust on the same platform.
The mechanism for this is the Solution Exchange, a commercial and technical framework that allows FDP applications to be packaged, quality-assured, and made available to other Trusts.
This is not limited to applications built by NHS teams. Third-party healthtech companies can build products on the platform and distribute them through the Solution Exchange, creating a marketplace for NHS operational tools.
NHS England is currently working with invited early adopters this year to establish the framework and the first wave of commercially available products. In 10 years, there could be thousands of these products, all portable across Trusts because they share the same data model. The current handful of nationally built products is like the calculator app on a smartphone. The platform can run anything.
The marketplace model introduces something the NHS has rarely had in its data tooling - genuine competition between products on the basis of clinical usefulness.
Where multiple products address the same workflow, clinical teams will prefer the one that works best for them. The better product gets adopted more widely. The weaker product either improves or is replaced. This creates incentives for innovation and brings the urgency to improve that is often absent when tools are nationally commissioned and centrally maintained. The NHS remains the commissioner and the governor. The energy to build, iterate, and improve comes from teams and companies who are motivated to make something clinicians actually want to use.
The cost of switching from one product to another is also reduced, because every product runs on the same platform with the same data model. A Trust is not locked into a product the way it is locked into a bespoke system that took years to integrate.
The patient impact? A tool that works well in one Trust becomes available to every Trust, so improvements in care are shared nationally rather than staying local.
Frontline-First in practice: a real national collection
These seven dimensions are abstract until you see them working together. The Mental Health Services Data Set (MHSDS) illustrates what the shift from reporting-first to Frontline-First would look like in practice, because it shows both the scale of the current problem and the potential of a different approach.
Today, the MHSDS is a national collection built on the reporting-first culture that has dominated NHS data investment for decades. Someone nationally said, "I want to know what is happening in mental health services," found some money, and built an entire reporting industry that is almost entirely separate from the frontline.
Clinicians in mental health trusts are required to record data to the MHSDS specification in their EPR. Much of what they record is not directly useful to their clinical work. It creates friction. The data feeds into a submission process that still relies on Microsoft Access databases as an intermediate stage, is processed centrally, and arrives at the national level months after the clinical event.
The FDP programme has achieved remarkably fast-paced progress under sustained political and media pressure that would have stalled most national programmes entirely
Tom Bartlett
From the clinician's perspective, the MHSDS is a black hole. Data goes in. Nothing useful comes back.
There is a further inefficiency. The MHSDS, while quite a comprehensive analytical base, is almost always entirely separate from the analytical base held within the Trust's own data team. The same data is extracted, transformed, and stored twice: once for the national collection and once for local reporting. The local version is almost always more accurate, because it has not had to be translated into a national specification that is in many places distant from the local data structures.
This duplication exists because of semantic inconsistencies in the data and the inconsistent platform technology deployed across Trusts and NHS England. It is pure waste. Part 4 of this series explores this semantic gap in more detail.
A critic might say the answer is to make the EPR better - configure it to capture the MHSDS data more naturally. But the EPR is a monolithic system that tries to serve every clinical setting with the same application. A crisis team, a rehabilitation ward, a community Child and Adolescent Mental Health Services (CAMHS) service, an early intervention in psychosis team - these are vastly different clinical settings with vastly different workflows. Forcing them all through the same EPR interface is part of why clinicians find recording burdensome and why shadow IT emerges to fill the gaps.
A Frontline-First approach would look fundamentally different. As well as the monolithic EPR, you would build a fleet of FDP apps, each tailored to the specific workflow of the team using it.
The crisis team gets an app designed for rapid assessment and handover. The rehab ward gets an app designed for long-stay progress tracking and outcomes. The CAMHS service gets an app designed for managing referrals and family work.
Each app is modular, built close to the clinical team it serves, and captures data in a way that makes sense for that team's work. The sum of the data captured across all of these apps flows to MHSDS automatically, because each app is built on the same platform with the same CDM.
The national collection becomes a by-product of useful clinical work rather than an administrative overhead imposed from above. The archaic Access-database submission process disappears because the data is already on the platform in a nationally consistent format.
This is what Frontline-First means in concrete terms. The clinician gets a tool they want to use, designed for their workflow rather than a generic compromise. The data quality improves because the recording is clinically meaningful rather than bureaucratically mandated. Modular apps built for specific workflows can also capture data in structured fields that the generic EPR progress note cannot, making data like DIALOG scores accessible to the data estate for the first time rather than buried in free text.
The national collection gets better data, faster, with less processing. The duplication between local and national analytical bases disappears because both draw from the same dataset on the same platform, harmonised through the CDM. The patient gets a service that is tracking their outcomes and learning from the comparison with peers. Every layer benefits, and the starting point is a useful tool at the point of care rather than a data extraction requirement.
The production evidence
Two things need to be evidenced before the Frontline-First argument can stand.
The first is that FDP can host operational applications that produce measurable outcomes.
The second is that it is feasible for frontline teams to build their own tools on the platform, because if every FDP application has to be nationally commissioned and centrally built, the approach will never cover the breadth of shadow IT that exists across the NHS.
On the first, NHS England publishes quarterly figures on FDP uptake and benefits. The Inpatient Care Coordination Solution (IP CCS) reports an average 6.6% increase in booked theatre utilisation across adopting Trusts. Unused theatre time is cancelled elective procedures, longer waiting lists, patients waiting in pain or at risk of deterioration.
The Outpatient Care Coordination Solution validates waiting lists and removes unnecessary appointments. Optica reports a 28% reduction in average delay days across adopting Trusts.
These figures should be read with caution. The journey is still at an early stage and the production evidence is still building. There will be challenges and limitations, and some are already being publicly stated. An independent three-year evaluation by Imperial College Projects, commissioned by NHS England at a cost of £700,000, began in March 2026 with findings expected in 2029.
I would welcome that evaluation going further than measuring the benefits of the current products. It should seek to understand the true comparator costs and relative benefits of a Frontline-First approach versus the reporting-first approach the NHS has followed for decades. Without that comparison, neither the advocates nor the critics of FDP have the evidence they need.
The figures I cite in this series are NHS England's published cross-trust numbers. This is the beginning of the journey, and as the platform matures these problems will be addressed if the programme keeps its focus on the Frontline-First vision.
On the second, the Build with FDP event in October 2025 offered the most direct evidence that frontline-led development is feasible on the platform. Some 120 NHS staff - a mix of data engineers, developers, clinical and operational staff - spent two days building working operational tools on FDP. The winning team built an Ambulance to Ward handover product. The runner-up built a clinical coding AI assistant. The next event runs in Leeds in May 2026, and the best applications from previous events are being sponsored by NHS England for national rollout.
How these dimensions address the data problems
The following table shows how the seven Frontline-First dimensions address each of the eight problems described in Part 1.
How the seven dimensions of value address each of the eight key data problems facing the NHS
The financial case
There is also a practical dimension that matters to any Trust finance director or CIO.
Trusts that adopt FDP as their core data infrastructure can replace their local data warehouse entirely. The licensing costs for SQL Server, Databricks or similar, the staff costs to maintain bespoke infrastructure, and the analyst time spent manually extracting and uploading national submissions all reduce significantly. National submissions can happen automatically through the platform rather than through the monthly grind of manual extracts.
FDP is centrally funded, cloud-hosted, and already in place. For a Trust paying £100,000 or more a year in data platform licensing alone, before staff costs, the financial case for adoption is straightforward.
There has been hesitancy among CIOs about what happens to funding arrangements after the current contract ends. This is understandable but should not be a reason to delay adoption. The savings from warehouse replacement, automated submissions, and reduced duplication will over time far outweigh the local implementation costs, and in my view central funding is extremely likely to continue given the strategic significance of the platform.
Trusts are expected to invest in ensuring FDP runs well and is developed within their organisation. The implementation costs should not be understated, but they are not new costs unique to FDP. They are the kinds of costs Trusts routinely incur when adopting operational tools: a System Coordination Centre, a data warehouse capability, a job planning system. All of these require staff, training, configuration, and ongoing support.
The investment varies significantly depending on approach. Trusts that have embedded FDP adoption into their existing transformation programmes, treating it as a set of tools to deliver improvements the Trust was already planning, rather than running it as a standalone digital programme, have found costs significantly lower than those that stood up dedicated teams.
The major investment for most Trusts is the data warehouse migration, which would apply to any platform change regardless of supplier. These costs should be weighed against the costs of maintaining duplicated data infrastructure, manual submission processes, and the shadow IT that a Frontline-First approach is designed to replace.
What the programme has achieved, and what it costs to transform at this scale
The FDP programme has achieved remarkably fast-paced progress under sustained political and media pressure that would have stalled most national programmes entirely. It has had the ambition to tackle the biggest problem in NHS informatics, one that has sat in the "too difficult" box for decades.
The NHS is the seventh largest organisation in the world. A transformation of this scale will inevitably create losers as well as winners, and even despite the pace, some things will not be done fast enough to prevent genuinely avoidable loss. There will not be enough focus, enough shared knowledge, or enough capacity to avoid every mistake that should have been avoided. That is the price of transformation at this scale. The best hope is that as the programme matures it can reduce this cost, and the evidence from the ground suggests it is already doing so.
Many Trusts have invested significantly in their own data infrastructure, such as on-premise SQL Server estates, and in some cases cloud-based BI stacks on Azure or AWS. These investments have genuine merit and have delivered real value within their scope.
At regional level, Greater Manchester and London have both built excellent data infrastructure, and the people who built them are some of the most capable data leaders in the NHS.
Shared care records have gone further, giving clinicians visibility of patient records from other care settings at the point of care.
These are genuine achievements. Some regional teams are going further still, linking data across acute, primary, and community care settings, applying population-level risk scores, and beginning to extend into operational use cases with write-back into clinical systems. This work is real, well-governed, and in some cases ahead of what FDP has delivered nationally.
But visibility is not the same as integration. Shared care records let a clinician see what happened elsewhere. They do not let the clinician act on it through the same platform, create new data, or collaborate with teams in other organisations through shared operational tools. The Frontline-First approach requires all of these.
The regional and local platforms were designed to analyse data, not to host the operational applications that create it. FDP was designed to do both on the same platform, with the same data model, the same access controls, and the same national consistency layer. That is the architectural distinction that makes Frontline-First possible, and the next post explains the architecture in detail.
Trusts with strong existing BI estates will benefit from FDP adoption not by discarding what they have built, but by connecting it to a national platform that addresses what their local infrastructure cannot.
Local data leaders who invested in infrastructure as NHS England previously directed, and who now feel that investment is being overridden by a national programme they had no role in shaping, have legitimate cause for frustration. That frustration needs to be heard and addressed, not dismissed as resistance to change.
NHS chief data officers concerned by FDP roll-out - The Chief Data and Analytical Officers Network has raised concerns over the way the NHS Federated Data Platform is being implemented and NHS England’s approach to its adoption.
The frustration is sharpest where mature, operationally proven products already exist. The NHS has System Coordination Centre tools that have been managing urgent and emergency care flows since 2013. Job planning systems embedded in Trust workforce processes. Locally built operational tools with years of frontline refinement behind them, trusted by the staff who use them. In some cases, the national programme has built FDP products that overlap with existing functionality rather than integrating what already works.
The Solution Exchange model described above should be the answer to this - bringing mature third-party products onto the platform so that Trusts retain what works while gaining the benefits of a shared data model and national portability.
Getting this right matters, because if Trusts feel their existing tools are being displaced rather than integrated, they will resist adoption, and they will have a point. This is an avoidable loss, and it is within the programme's power to fix.
There is a practical step that would help. While I have elaborated, named and communicated the Frontline-First concept, I did not create it. Leaders in NHS England did, and so NHS England should publicly name the Frontline-First vision, explain it to the wider data community, and invite collaborative development of the operational application roadmap.
If the programme had clearly stated from the outset that FDP's purpose is to put useful tools at the point of care, with good data as a by-product, the conversation would be about how to make that work locally rather than about whether the programme has drifted from its original brief. The drift is in the communication, not in the architecture.
The investment case
A true Frontline-First approach needs significant investment. Consider the context - even over the last five years.
EPR investment alone has come to around £2bn. One single geography will spend £200m on an electronic health record (EHR) upgrade and nobody blinks.
In that context, a £330m contract to address the data plumbing looks like what it is - a modest beginning of a much larger endeavour. The cost of FDP is criticised, and the total cost of ownership is genuinely unknown. But the cost of the alternative, continuing with the reporting-first approach, is also unquantified, and it is almost certainly higher.
If the NHS data problems described in Part 1 had been properly addressed 10 years ago, instead of investing further in centralised data collection and reporting, the NHS would have a far more effective data estate than it does now. Criticism of FDP's cost is incomplete without the comparator.
Why Foundry?
The next post explains why Palantir's Foundry is the only platform I have seen that is capable of delivering a Frontline-First approach at NHS scale.
NHS needs to get data basics right before rushing into AI - During a panel discussion at a Women in Data event, speakers from across the public healthcare sector outlined the groundwork that has to be laid for artificial intelligence to take the NHS by storm.
