Many people - in the NHS, in Parliament, in the tech sector and beyond - have raised objections to FDP and its supplier. Some have merit, others less so
The previous four articles in this series have described a connected set of problems the NHS has never addressed, an approach called Frontline-First that would address them, the architecture that makes it possible, and the data model and consistent products that make it work at national scale.
The case for delivering this is strong, and the platform to deliver it exists.
The supplier has been chosen – despite the strong opinions that supplier, Palantir, arouses - and there is nothing practical that can be done to change that unless the NHS is forced to go backwards and then stand still until another supplier emerges, perhaps in five years, perhaps in 10, perhaps never.
While our heroic NHS teams press on with making the Federated Data Platform (FDP) work for them, they are doing so against a relentless backdrop of controversy that puts delivery at risk, and not because the architecture is wrong.
Trust chief executives who could be leading adoption are hesitant, uncertain about what the system actually does, never mind whether the political environment will support them. I have spoken to senior NHS staff in Trusts who are asking whether they should invest locally, whether they should push their staff on this, whether they should get involved at all.
Technology companies who could be building products for the Solution Exchange are holding back - at a recent supplier event I heard companies say they had read about a contractual break clause in the press and could not justify the investment if the programme might be pulled.
Local data leaders who built impressive platforms over many years feel their work is being sidelined rather than integrated, and their frustration is genuine.
And MPs who see an opportunity to build political capital with their base have turned FDP into a proxy for broader anxieties about US technology, public sector outsourcing, data privacy, and the ethics of Western governments.
Meanwhile, patient opt-outs from NHS data sharing have accelerated sharply, causing long-term damage to the very people opting out and to other citizens who share their demography and health needs.
The cumulative effect is organisational drift, where the people who need to act are waiting for clarity that the debate is not providing. Public trust matters, and the UK government's unsuccessful attempts to secure it have had real consequences.
Some commentators have drawn parallels with Care.data, the national programme withdrawn in 2016 after public concern made it politically costly to defend. I do not think we are there. Cross-party political will for FDP remains strong, and the Westminster Hall debate attracted barely a dozen backbenchers.
The risk is not that FDP will be cancelled. It is that it will drift while the noise consumes the bandwidth of the people who should be delivering it. The answer to a trust deficit is not to abandon the approach - it is to be transparent about what the platform does, why it matters, and how the data is protected. That is part of what this series has tried to do.
The government's reorganisation of the NHS has accelerated the drift. Arbitrary and untargeted cuts to central services have made it harder for the national team to coordinate the most ambitious data programme the NHS has ever attempted. No staff group or programme has been protected - all are subject to disruption with no apparent strategy beyond reducing headcount.
This article engages with the objections that are causing that drift, takes them on their merits, and makes the case for why constructive engagement matters more than any of the individual arguments.
These are the arguments I have heard, in good faith, from NHS leaders, clinicians, technology companies, and parliamentarians since I left NHS England. Some of them I might once have made myself, before I saw FDP up close.
"We don't need it. We already have platforms that do this."
This is the objection I hear most often, and it rests on a misunderstanding of what FDP is.
It takes several forms. Senior Integrated Care Board (ICB) leaders have reported to their boards that local capability exceeds anything FDP currently offers. Trusts have told NHS England in FOI responses that adopting FDP tools would cause them to "lose functionality rather than gain it."
In Parliament, FDP has been framed as an overpriced analytics subscription, or "an expensive data warehouse." Freedom of Information responses from multiple Trusts described FDP as "a step backwards" compared to existing tools.
But every one of these statements frames FDP as an analytics platform competing with existing business intelligence (BI) tools. That is not what FDP is.
Could a home-grown system do what FDP does? In principle, yes. The ideas underneath the Foundry application are knowable and implementable. But
Tom Bartlett
The confusion is understandable - when you describe FDP it genuinely does sound like a cloud data platform, with waiting list dashboards, productivity metrics, care coordination insights and so on. But operational FDP products are already running in production across adopting Trusts - theatre scheduling, discharge coordination, waiting list validation, pathway tracking.
These are workflow applications where clinicians and operational staff make decisions, record them, and have those decisions update the underlying data. They are not dashboards. They are tools.
The Frontline-First vision that this series has described was in the original procurement specification, which explicitly required operational tools, a marketplace for sharing products, and the capability for Trusts to develop their own digital solutions.
But the programme's communications did not land this. The result is that even people inside the NHS data community describe FDP using analytics vocabulary, talking about dashboards and data warehousing, when its production applications are operational products designed for clinical and operational workflows.
"This is not what we procured"
The CDAO Network wrote in their open letter of February 2025 that the original business need for FDP was "about creating a data connection capability" and "about federating data and interoperable standards," and that it "should not be about imposing or advancing adoption of specific software solutions." The group described the shift toward operational tools as "programme drift."
These statements reveal the scale of the misunderstanding. The contract explicitly covers operational applications and the Solution Exchange. The original procurement prospectus, published in January 2023, explicitly stated that the platform would "provide Trusts and Integrated Care Systems (ICSs) with the capability to develop their own digital tools that address their most pressing operational challenges" and that its connectivity would "enable us to rapidly scale and share innovative solutions."
A separate Marketplace procurement was published in May 2023 covering "the creation and delivery of use cases and products by other suppliers and subsequent publishing of operational products and solutions."
Operational tools, use cases, and a marketplace for sharing products were in the procurement from the start. They were not added later as programme drift. The community either did not read the procurement closely enough or read it through a reporting-first lens and assumed "tools" meant dashboards.
How has this misunderstanding happened? Look at the programme's own communications, largely confined to the NHSE website. The language used reinforces the misunderstanding by describing FDP in phraseology used extensively in analytics.
The programme's communications were narrower than the procurement, and the Frontline-First vision was never publicly articulated. Where NHS England leaders have described the system it has often been indirect, at times over-simplified to the point where meaning is lost, and at times wrapped in Palantir marketing, an immediate turn off to many who might otherwise have listened.
The message should have been clear - FDP supports a Frontline-First approach that requires operational products at the point of care, and those products need to sit on the same platform as the data to deliver the benefits.
I described this at length in Parts 2 and 3 of this series. The name of the programme was never going to do the communication on its own, but it is in itself confusing. Data federation alone doesn't give a clinician a useful product, doesn't replace the spreadsheet, doesn't produce better data at source. What drifted was the communication, not the programme.
"Why not build our own?"
This is the most politically prominent objection. Martin Wrigley, MP, has called in Parliament for "a staged exit with a retender for British companies to build a replacement for Palantir" and argued that "a UK tech consortium" could "build UK sovereign solutions, tech skills and competencies."
An NHS developer, quoted by Julian Smith, MP, in the same debate, wrote: "There are any number of reassuringly boring companies that could deliver this contract, many of them based in the UK." The BMA has called for termination of the Palantir contract.
Could a home-grown system do what FDP does? In principle, yes. The ideas underneath the Foundry application are knowable and implementable.
But "in principle" is doing a lot of work. Foundry is not a product that was built by a project team. It is the output of a $328bn company that has employed thousands of engineers over 20 years, unconstrained by NHS pay scales, headcount ceilings, or recruitment timelines, and funded by billions of dollars in commercial and government contracts across defence, intelligence, and the private sector.
The NHS would not be replicating a team - it would be replicating a company. A contract worth £330m over seven years is not remotely close to that. It is enough to use Foundry. It is not enough to build it.
Critics will say they would do it differently, using a combination of existing open-source components and cloud services, and they may be right that a different route is possible. But nobody has yet demonstrated an alternative that delivers the combination of capabilities described in Part 3 at the scale the NHS requires.
The UK consortium version is the argument that gets put to me most often when the home-grown option runs out of road. The UK does have genuine data companies. Quantexa, which bid for the FDP contract in 2023 alongside IBM, is a serious UK-founded firm with strong entity resolution and decision intelligence capability. Voror Health Technologies, Eclipse and Black Pear formed an all-British consortium that also bid. Both lost to Palantir.
The reason matters more than the result. Neither Quantexa nor any other UK data company currently offers a platform with the combination of capabilities I described in Part 3 – that is, object types that hold data and descriptions together, live navigable relationships between them, actions that create new data through operational applications, writeback into the same data fabric, and a national data model hosted in the same layer.
The UK has strong data companies solving adjacent problems. Since I began writing publicly about FDP, I have invited anyone who knows of an alternative platform that delivers this combination to tell me about it. Several have tried, but nobody has come close to describing the functionality needed. I acknowledge that I can only speak to what I have seen - there may be a platform in development that has not yet declared its capability. I would welcome being shown one, and I will need more than vague declarations or lists of company names.
FDP is a multi-year endeavour even with Palantir's two decades of platform R&D behind it. Anyone hoping for a different answer in the next 18 months, whether by intervention or by break clause, is asking for a delivery timeline that does not exist on any platform of this scale anywhere in the world.
"Why does it have to be one platform?"
This is the most substantive objection, because it accepts most of the argument I have been making and proposes a different deployment model. Martin Wrigley, MP, called in Parliament for "a distributed, interoperable UK sovereign solution," comparing it to "how massive systems, such as the internet or mobile phone networks, work. They do not rely on one single system or supplier." The CDAO Network's open letter argued that the original business need was to federate data, not to impose a single platform.
There is broad agreement across the NHS data community, including from the strongest critics of FDP, that a common data model is needed. The disagreement is not about whether the NHS needs a canonical data model (CDM). It is about whether the NHS needs a single platform to implement it.
The alternative position is that different parts of the NHS can run different platforms, all conforming to the same CDM but implementing it locally on their own technology. This position has surface appeal - it preserves local autonomy, avoids single-vendor dependency, and lets each region use the tools its teams know best.
But there are things it cannot deliver that a single platform with the CDM can.
First, application portability. An application built on FDP cannot run on an Advanced Data Services Platform (ADSP) any more than an iPhone app can run on Android, even if both work with the same underlying data model.
On a single platform, a Trust in Dorset builds an application and a Trust in Newcastle installs it through the Solution Exchange without rewriting. On multiple platforms, the application has to be rebuilt for each one. That is the difference between interoperability – where systems can talk - and portability, where the same thing runs in both places.
Second, semantic consistency. As I argued in Part 4, a consistent data model is necessary but not sufficient. You also need consistent products that constrain recording to produce data of known meaning. On a single platform with the Solution Exchange, those products are portable and enforceable. On multiple platforms, conformance becomes aspirational rather than structural.
My view is that a single platform makes national consistency structurally achievable. Multiple platforms make it aspirationally possible but operationally much harder, and we can already see this if we look at the current state of electronic patient records (EPRs).
There is one area where the distributed model has a legitimate case - the analytical layer. As I acknowledged in Part 3, Foundry's native analytics are less mature than a well-configured Power BI or Tableau environment, and Trusts with strong analytical infrastructure should not be forced to abandon tools that work well for that purpose. Their data team will have to justify to their CFO each year why they have to rebuild and maintain analytics locally when every other Trust is collaborating on shared infrastructure.
But for the operational layer, where the Frontline-First products sit, the case for a single platform with a shared data model and portable products is structural, not a matter of preference. The evidence from the next few years of FDP delivery will make this clearer. But it is worth naming the category error in this objection.
Consider a fleet of mobile phones. Nobody argues there should be five competing operating systems on the same device. The operating system is standard; the apps are diverse. Apple’s iOS does not compete with the apps that run on it - it enables them. In this analogy, FDP is the operating system, not the device. The Solution Exchange is the App Store. The CDM is the API standard. The products that run on the platform are built by Trusts, by NHS England, and by third-party suppliers, all competing on the basis of clinical usefulness. The interoperability that critics, including Wrigley, call for is the very thing the platform provides.
A related argument deserves attention.
There is strong NHS data work at regional level, where dedicated teams have spent years linking data across acute, primary, mental health, and community settings, applying population-level risk scoring, and embedding analytics inside clinical systems.
But this work tends to produce a collection of separate specialist tools for separate use cases - one for the shared care record, another for waiting list prioritisation, another for GP prescribing interventions, another for the system control centre. The tools do not share a common data model. They are not portable to other regions. They are not built using AI-assisted development that allows non-engineers to contribute. And they are not integrated into a single operational workflow where data created in one tool is immediately available to every other.
The tools do not share a common data model. They are not portable to other regions. They are not built using AI-assisted development that allows non-engineers to contribute. And they are not integrated into a single operational workflow. This is excellent analytics infrastructure with operational extensions bolted on. It is not a Frontline-First approach.
The question is whether 26 ICBs can each build their own version independently, maintain semantic consistency across them, and make the resulting tools available to every Trust in the country. The CDM and the Solution Exchange exist because the answer is no.
"The cost is too high"
Senior NHS data leaders have asked for independent evaluation of costs and benefits and they are right to do so. The published contract value of £330m significantly understates the true cost of FDP adoption, and as I described in Part 2, implementation costs vary significantly depending on how a Trust approaches adoption.
There are also operational costs that early adopters are still defining - incident management, change control, monitoring, and the service management model for a platform that runs clinical tools. These day-to-day realities of running FDP in production are not yet fully established, and Trusts considering adoption should factor them in.
But the evaluation must also account for the costs of the status quo. The hidden costs of operating without a Frontline-First approach are real and large - data quality failures that distort commissioning decisions and funding allocations; clinical variation that persists for years because enrichment never reaches the consultant; the information governance and data loss risks created by shadow IT that sits outside the formal data estate; analyst time spent reconciling data that should have been consistent at source; and the downstream research and policy consequences of working from data that looks reasonable but is silently wrong.
The information governance risks presented by current practice of using whiteboards, spreadsheets and paper have not gone away, and are costing the NHS millions each year. These costs are harder to quantify but they are borne every day by every Trust in the country. An honest evaluation would put the cost of FDP adoption alongside the cost of not adopting it, and let the numbers speak.
There is a further cost that is harder to see but may prove the largest of all - the opportunity cost of falling behind on AI.
Every major health system in the world is investing in AI capabilities that depend on consistent, structured, semantically coherent data. Implementing AI across the pre-FDP data landscape, with its fragmented systems, inconsistent semantics, and data locked in siloed warehouses, would require building bespoke grounding and integration for every Trust, every data source, and every use case.
The operational AI capabilities on the platform (Ask FDP, AI-FDE, the emerging agentic workflows described in Part 3) work because the ontology provides the semantic layer that AI needs to reason across the data. Without that layer, AI in the NHS will be confined to isolated local experiments that cannot scale.
Other countries are not waiting. The cost of delay is not just what the NHS loses today - it is the widening gap between what the NHS can do with its data and what comparable health systems will be able to do with theirs.
The cost comparison that puts this in context is the EPR investment. The NHS has spent roughly £2bn on electronic patient records over the past five years, with single geographies spending £200m on a single EPR upgrade. In that context, £330m for a national operational data platform looks like what it is - a modest beginning, not an extravagance.
The objections so far have been about whether FDP is needed and whether it is worth the cost. The next set are about the supplier - who owns what, how dependent the NHS becomes, and whether Palantir is an acceptable partner.
"The NHS owns no intellectual property"
This is the most disingenuous claim in the debate. Martin Wrigley stated in Westminster Hall that the FDP contract delivers "no software, not one line" and that "all the specially written software and intellectual property rights belong to the supplier." I wrote to Wrigley before the debate explaining why this was wrong. He repeated the claim regardless. The minister, Zubir Ahmed, contradicted him in the debate: "The NHS owns the intellectual property for all products and it is possible to migrate them to other providers."
The accompanying diagram shows the layered architecture and where intellectual property (IP) ownership sits at each level.
The NHS Trust owns its network infrastructure, its connection agent host, its connector configurations, and its ETL pipeline logic, all written in standard open-source languages (SQL, Python, PySpark, React) that can be lifted and run on any platform.
The Canonical Data Model belongs to the NHS, is licensed via the Open Government Licence, and is available to all on GitHub.
Every FDP product built by NHS engineers belongs to the NHS. Every Trust-built application, dashboard, and report belongs to the Trust.
What Palantir retains is intellectual property in Foundry itself - the platform engine, and the proprietary tools like Quiver, Workshop, Contour, and the Ontology Engine. This is no different from Microsoft retaining IP in Excel while users own the spreadsheets they create.
If Palantir lost the contract tomorrow, the NHS would retain all of its data, all of its code, all of its products, and all of the CDM. Only the Foundry platform engine and Palantir's own tools would need replacing. That is a significant migration task, but it is not "no software, not one line."
FDP integration architecture
The IP ownership question is separate from the vendor lock-in question, and it is worth being clear about both. Everything built on FDP is technically portable - the code is in open source languages, the CDM belongs to the NHS, the data belongs to the Trusts. But portability on paper and migration in practice are very different things.
If the break clause were triggered and Palantir's software became unavailable, the migration task would be monumental. Every pipeline, every ontology configuration, every application would need to be rebuilt on whatever platform replaced it. The CDM would need to be reimplemented. The integrations with Trust source systems would need to be reconnected. And the NHS would need to have a platform to migrate to, which, as I have argued above, does not currently exist.
This is not unique to FDP - any platform migration at this scale is a multi-year programme in its own right. The SAS to Foundry migration that NHS England undertook was a significant project and that was one analytical platform within one organisation. Migrating 220 Trusts' operational products would be orders of magnitude harder.
The challenge to migrate away from FDP is significant, but it is operational rather than legal, and it is the same kind of challenge that applies to every EPR, every data warehouse, and every enterprise system the NHS runs.
Data sovereignty and the Cloud Act
A persistent claim in the debate is that the NHS has handed its data to Palantir. It has not. The data remains under NHS data controllership. Palantir provides the platform software under contract - it does not own, control, or have the right to use NHS data for any purpose outside the contracted services.
The contract explicitly prohibits commercial or research use of the data by the supplier. This is the same arrangement that applies to every other technology supplier the NHS uses - Microsoft hosts NHS data on Azure, Epic hosts clinical records, and neither owns the data they process. The minister confirmed this in the Westminster Hall debate - the NHS owns the data and can migrate it to other providers.
A related concern is that Palantir is a US company and that the US Cloud Act could theoretically compel disclosure of NHS data to the US government. This is a legitimate concern in principle. It is also one that applies equally to any US company including Epic, Microsoft, Apple, and Google. There is unlikely to be anyone in England who has not already willingly shared their personal data with at least one of those firms. The NHS runs on Microsoft infrastructure. Most Trusts use Microsoft 365. Many are migrating to Azure. Epic and Oracle Health, both US companies, provide the EPR systems that hold the most sensitive patient data in the NHS.
The Cloud Act requires US law enforcement to obtain a warrant from a US court, demonstrating probable cause that the data sought contains evidence of a crime. The warrant must describe with particularity the data to be obtained, and the provider can challenge the order in court. It is a targeted legal process, not a mechanism for bulk data extraction.
Campaigners have suggested that FISA, separate US surveillance legislation designed for counter-terrorism, could be used to compel bulk access to NHS data without individual warrants, bypassing the safeguards described above. FISA authorises the surveillance of foreign intelligence targets, not the bulk extraction of datasets from commercial platforms. Using it to obtain NHS patient records would require a US intelligence agency to persuade the FISA Court that millions of NHS patient records are relevant to a foreign intelligence investigation.
There is no credible technical mechanism by which this could happen without triggering every alarm in NHS England's cyber security monitoring and becoming instant headline news. The fact this has never happened to any US-hosted NHS data, despite UK citizens using US software since the start of the information age, is telling. The concern is understandable given the political climate and media coverage, but it is not supported by the evidence of how these legal instruments work in practice.
If data sovereignty from US jurisdiction is the standard, the NHS would need to exit not just Palantir but its entire cloud and EPR infrastructure. That is not a realistic proposition, particularly when the UK government is actively inviting US technology companies to invest in the UK.
The sovereignty argument is worth having as a matter of national policy. It is not a credible basis for singling out FDP while leaving every other US technology dependency in the NHS untouched.
The ethics of the supplier
There is a further objection that this series has deliberately not addressed until now, because it sits outside the architectural argument - the ethics of Palantir as a company.
Palantir's involvement in military operations, immigration enforcement, and intelligence work is a matter of public record. The company has attracted intense criticism, and some of the language used to describe it and its employees has been extreme. NHS staff, including data analysts who are asked to work on the platform, have raised sincere objections to working with a company whose other contracts they find morally unacceptable.
I have listened to the frustration local leaders feel and it is real. The programme was operating under continual, near-unmanageably high pressure for years. Both things are true, and both need to be acknowledged if the relationship between the national programme and the local teams is going to work.
Tom Bartlett
The tension is understandable. The NHS is built on values of care, compassion, and the equal treatment of every patient. Military and security organisations operate on different values - national defence, deterrence, and the use of force where necessary. Both sets of values exist within British society.
The UK funds its armed forces, operates intelligence services, and contracts with companies that support them. These are not fringe activities - they are functions of a democratic state. The discomfort that NHS staff feel when those two worlds intersect through a shared supplier is real, but it is a tension between values that coexist in the same society, not a choice between right and wrong.
These objections are legitimate. They are also personal. We each make choices about who we vote for, what we buy, where we work, and which companies we are willing to do business with. Those choices reflect our values and nobody should be told their values are wrong. But this series is about whether the Frontline-First approach works, whether the architecture delivers it, and whether the NHS should build on it. The ethics of the supplier are a question for individuals, for lawmakers, and for the democratic process. They are not a question this series can answer, and they should not be used to avoid engaging with the substance of the argument, nor to judge those who work within an imperfect framework to try to do good for patients and the public.
I find it hard to watch decent colleagues be heckled as "genocide supporters" for expressing the opinion that the software is helpful in improving the NHS. This sort of behaviour diverges from NHS values and it materially dampens collaboration and delivery.
"The programme has not worked with us"
The objections above are about the platform, the supplier, and the architecture. There is a separate set of concerns that are about how the programme itself has been run. These deserve their own acknowledgement because they come from people who are not opposed to FDP in principle but who have been frustrated by their experience of working with it.
The FDP programme is led by a national team at NHS England, but the platform is adopted and operated by individual NHS Trusts and Integrated Care Boards, each with its own data team, infrastructure, and priorities.
Trusts and ICBs have at times felt that the national programme worked around them rather than with them. Concerns raised locally were treated as the Trust's responsibility to resolve, resourcing requirements have at times been too optimistic, and opportunities for shared learning between organisations were constrained.
Combined with insufficient communication about what FDP is and what it requires, this has created frustration and disengagement. I have heard directly and with feeling from senior people who say they are valued in their own organisations but felt undervalued by the national programme.
Data teams in the NHS have historically operated at one step removed from the frontline. A Frontline-First approach changes that - it moves data capability closer to the point of care, into environments where the pace is relentless and the tolerance for friction is low.
Combine that with AI capabilities delivered via FDP, and that is a significant shift for teams who are used to working in the back office, and it is a change that requires strong and purposeful leadership across the technical professions. The need for this leadership is urgent, both nationally and in Trusts.
That is not to judge the national FDP programme whose task was herculean from the start. Problems with communication and engagement are not unique to FDP, and any national programme working in public, at technical depth, across 250 autonomous organisations will create friction. The context makes it harder for the FDP programme to get right - it was delivering through a period in which NHS England itself was being reorganised, workforce reductions were affecting every level of the system, and the political environment was hostile. It is not possible to please everyone when working at this scale under those conditions.
I have listened to the frustration local leaders feel and it is real. The programme was operating under continual, near-unmanageably high pressure for years. Both things are true, and both need to be acknowledged if the relationship between the national programme and the local teams is going to work.
What is actually happening on the ground
The debate about FDP has been conducted largely in the abstract - procurement politics, supplier ethics, theoretical capabilities. Meanwhile, Trusts that have committed to the platform are building.
One NHS group has re-platformed all its core FDP products into a shared cross-Trust space, with both Trusts running single instances of theatres, Optica and shared patient tracking lists backed by permissions-based access. The same group is decommissioning its local data warehouse and moving entirely to FDP. Its national submissions are being automated through the Health Decision Suite (HDS), the FDP product that provides cloud-based data warehouse functionality, with ECDS and CDS complete and 14 further priority reports in progress.
The same group is building local products for ward accreditation, programme management, and quality improvement, with working groups involving corporate nursing teams and ward leaders. The implementation cost has been significantly lower than the figures most often cited in the debate, because the Trust embedded FDP adoption into its existing transformation programmes rather than running it as a separate digital programme. I was told four products were built side of desk and the organisation is now recruiting a developer to frontline teams to quality-control AI-assisted product prototypes into production.
This is one example. There are others. Trusts are building DNA prediction tools, clinical quality products, cross-Trust shared patient lists, and nursing quality applications.
Third-party technology companies are also beginning to engage, working with Trusts and NHS England to bring their products onto the platform through the Solution Exchange. The teams doing this work are not waiting for the debate to conclude. They are building, and the gap between what is happening on the ground and what is being discussed in the media and in Parliament is growing wider by the month.
The platform's long-term sustainability depends on the NHS developing its own Foundry expertise. Trusts need to invest in building internal capability rather than remaining dependent on Palantir's engineering support. This should be a priority for every Trust that adopts FDP, and the example above shows it is already happening.
The cost of the distraction
There is a collective cost to the debate that none of the individual objections acknowledges - while the NHS argues about who won the contract, the Frontline-First approach is being delivered by the Trusts that have committed, but not at the pace or scale the NHS needs.
The CDM governance described in Part 4 needs investment and attention now, not after the debate concludes. The Solution Exchange needs a commercial framework and early adopter engagement now. The Trusts that are building local products need support, access to the governance process, and a community contribution model that scales. Trusts that have not yet engaged need to understand what FDP is for, which is the purpose of this series.
None of this is happening at the pace it should, because the bandwidth of senior leaders in the system is consumed by the political noise rather than the delivery challenge.
There is a quieter cost that receives less attention. Every patient who opts out of NHS data sharing on the basis of the campaigners' framing makes themselves less visible to the system trying to look after them.
The research datasets that power studies into cancer, dementia, and cardiovascular disease become not just smaller but biased, because the patients who opt out are not randomly distributed. The campaigners are sincere in their concern about data privacy, and patients must have the right to opt out. But the current dynamic, where the Palantir controversy is used to drive opt-outs that damage both care and research, is causing real harm.
The objections are not wrong to exist. But they are wrong to dominate. Realists know that there is no alternative, despite the prospect of contractual break clauses. The real question is not whether Palantir should be the supplier - that ship has sailed. The focus should be on how collectively we can support the Frontline-First approach, the CDM, and the consistent products that enforce it to be delivered, reducing the harms of a debate that has already gone on long enough.
Why this matters now
There are two ticking clocks that the debate has not acknowledged.
The first is the NHS App. It is a central feature of the 10-Year Health Plan and is connecting to more Trusts every month. As it expands, it will expose more of the patient record directly to the public. Patients will see records that do not match what they were told - missing information, stale data, inconsistencies between what their GP recorded and what the hospital has. The data quality problems described in Part 1 are about to become publicly visible in ways that will erode patient confidence in how the NHS manages their information.
The second is the pace of change in data and AI. The rest of the world is not waiting. Every major health system is investing in AI capabilities that depend on consistent, structured data, and the gap between what those systems can do and what the NHS can do is widening. The NHS data landscape described in Part 1 was already behind. With AI accelerating the pace of change, standing still means falling further behind, faster.
The public debate about FDP has been dominated by questions of ethics and trust - who supplies the platform, what the supplier's track record looks like, whether the procurement was right. Those questions matter and they deserve answers. But they have crowded out the question that matters most: does the Frontline-First approach work, and what will it take to deliver it?
The answer will not come from a single supplier. Palantir provides the platform software, but FDP is built by the NHS. It is built by Trust data teams configuring it for their clinical services, by ICB teams linking data across their systems, by the national engineering team designing the architecture, and by the third-party suppliers who will build products for the Solution Exchange.
The approach should not be in doubt - the evidence from early adopters, the architectural case, and the absence of any credible alternative all point the same way. What should be in doubt is whether the system can stop arguing long enough to deliver it.
The conversation needs to move from who supplies the software to how we make the approach work. If the government is serious about moving resources to the frontline, it should understand that investing in data solutions for clinicians is how data supports that ambition, and it should ensure the programme does not stall because the central team is consumed by organisational upheaval. Campaigners and MPs should focus on building what comes next, for example a sovereign competitor to Palantir.
Everyone who has a role in this should be careful not to tear down what has been built, or criticise the NHS staff who are building, as that helps no one - not the patient, the taxpayer, or the clinician.
Find ways to constructively engage and find solutions. The NHS has the platform, the data model, the early products, and a growing community of Trusts and technology companies who want to build on it.
What it needs is collective commitment to the Frontline-First approach and the willingness to adapt on all sides - the national team listening to local leaders, local leaders engaging with the architecture rather than dismissing it, and the supplier community building products that the frontline actually wants to use.
Together, we can make the NHS safer, easier and quicker to access. We can achieve higher quality patient outcomes and a better patient experience. We can make more efficient use of taxpayer funds. All of this starts with getting the data to work harder and giving the frontline what it needs. That is what Frontline-First means, and it is within our reach if we choose to build it together.
I left NHS England in March 2026 after three years inside the FDP programme. I wrote this series because I believed the public debate was missing the most important part of the story - what the platform is actually for.
I have tried to be honest about what works, what does not, and what needs to change. The Frontline-First approach is not perfect and neither is the programme delivering it. But it is the best answer I have seen to problems the NHS has failed to solve for 20 years, and I would rather help build it than watch the debate consume it. I intend to keep writing, and I intend to keep building.
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.
