Beyond Palantir’s FDP: Building NHS Data Systems Fit for the Future

Contents

Introduction

Section 1: The FDP and data capabilities

Section 2: Principles of an alternative data architecture

Section 3: Mitigating potential disruption

Conclusion & recommendations

Appendix 1: Benefit claims

Introduction

This briefing is intended to inform Members of Parliament, Ministers, and NHS Leadership about the potential to move away from the Palantir-run Federated Data Platform (FDP), and instead invest in NHS-led data infrastructure built on public trust, staff buy-in and data sovereignty. It is authored by Medact, and supported by The Good Law Project, Foxglove, Doctors’ Association UK, Corporate Watch and Just Treatment.

We believe that the FDP’s design and the choice of supplier represent a failure of public procurement in the public interest. Following a decision not to extend Palantir’s contract beyond the initial contract term, ending in February 2027, the government has an opportunity to make a different choice, and implement trusted, accountable and innovative improvements to NHS data systems. This requires moving away from single-software procurement and towards an ecosystem approach that supports quality data systems across the NHS. 

This briefing argues that any ‘alternative’ to the FDP must be specific to what is actually needed, where and why, rooted in an understanding of what already exists in NHS-led innovation. An ‘alternative’ to the FDP must also be underpinned by a set of values that protect patient trust, staff buy-in, public support, local autonomy and data sovereignty. 

The House of Commons Science, Technology and Innovation Select Committee report published in June 2026 stated that: “The government should commit to exercising the February 2027 break clause in the Federated Data Platform contract and either develop an in-house replacement or seek an alternative developed by UK-owned and UK-based providers that are more compatible with UK values, and do not pursue either technical or contractual dependencies. It should publish a fully costed exit plan for the Federated Data Platform by the end of 2026.” 

This briefing is intended to support this planning by assessing what kind of procurement is needed for NHS data systems, and what principles that procurement should adhere to. 

In Section 1, we highlight the importance of being specific about the required functionality of data systems. This section explains some of the main data capabilities that the FDP is supposed to offer, such as locally-used applications and Integrated Care Board (ICB) and national level analytics. Palantir’s FDP is often positioned as the only solution for connecting disparate datasets within the NHS. However, we outline examples of existing NHS-led and highly advanced data connectivity projects, including federation, which already exist outside of the FDP.

We argue that many of the capabilities within the FDP already exist across the NHS, and not all of the FDP’s capabilities need to be re-procured in order to safely move away from the platform. In a letter to NHS England the Chair of the Chief Data and Analytical Officers Network stated that many systems “already have similar tools in use that presently exceed the capability and application of what the FDP is currently trying to develop or roll out at a system level”. To deliver a national data project aiming to connect disparate datasets in the NHS at the local, regional and national levels, the government should learn from and scale up existing innovation within the NHS, especially localised data connectivity infrastructure that truly benefits patient care.

In Section 2, we argue that any re-procurement must be underpinned by a set of key principles that would support NHS-led innovation, avoid vendor lock-in, protect patient trust and the values of the NHS constitution, and ensure design and procurement based on evidence and need.

Any data capability is only as good as the level of patient trust, staff buy-in and public support behind a programme, and an ‘alternative’ to the FDP cannot make the mistake of ignoring these factors in the procurement. 

In Section 3, we outline our understanding of the potential risks of moving away from a Palantir-run FDP, and present some potential mitigation measures. Recent evidence suggests that the FDP is not as embedded, nor providing as many benefits, as official figures suggest, creating an important window of opportunity to move away from the platform safely, with some mitigation measures, and instead choose to invest in NHS-led innovation that retains public trust. Some organisations may need support to transition away from the FDP, and the government can undertake a ‘baseline uplift’ programme to support digitally immature trusts that use the FDP, and, long term, reinvest in data and digital professionals within the NHS. 

In summary, we argue that a genuinely trusted , transparent, accountable, secure and innovative approach to NHS data architecture must move away from single-software procurements from big tech companies, and move towards in-house and local innovation, design based on need, and protecting NHS values. 

This is a commitment that will take time to realise and build. However, the government can feasibly take important steps towards this in the next year. 

Within the next year, the government should: 

1. Announce the intention not to extend the Palantir FDP contract beyond February 2027, and begin full exit planning. This should include:
   • planning a ‘baseline upgrade’ programme, supporting the most digitally immature trusts to improve their systems and transition away from FDP apps if required. 
   • a risk assessment of job losses within data and digital professionals, and beginning to design a long-term workforce investment plan to retain skilled data and digital professionals across NHS institutions.
2. Conduct a thorough review of existing NHS data infrastructure, especially regional level data federation and data connectivity programmes, that could be scaled up and learned from, to inform any new procurement that may be required. 
3. Redesign any future procurement based on the following three principles:
   • Support NHS-led innovation and avoid vendor lock-in
   • Protect patient trust and the values of the NHS constitution
   • Design and procure based on evidence and need. 

As written by over 100 NHS data and digital professionals in their open letter regarding the FDP: “We believe that alternatives to the FDP that can truly transform NHS data infrastructure already exist for a multitude of use cases, and we are ready to build and develop the rest.” Terminating Palantir’s contract with the NHS offers a unique opportunity to step towards data systems that truly work in the interests of staff, patients and public health. 

This briefing does not attempt to suggest a like-for-like replacement for any of Palantir’s services or products. For background on Palantir and the FDP, please see our previous briefing, ‘Concerns Regarding Palantir Technologies in NHS Data Systems’.

Section 1: The FDP and data capabilities

This section argues that any procurement of an ‘alternative’ must be specific about what is needed, where and why. We argue that many tools similar to the capabilities within the FDP already exist across the NHS, and that not all of the FDP’s capabilities need to be re-procured in order to safely move away from the platform. The government should learn from and scale up existing innovation within the NHS that meets specific needs, rather than imposing a single-software procurement. 

In summary, the FDP is a national software infrastructure provided by Palantir Technologies to NHS England, based on Palantir’s Foundry software. The FDP has two main elements: data warehousing and analytics, and operational apps for local use. It does not directly connect clinical records across hospitals and is not synonymous with a single patient record, which are common misconceptions. The system is also a “platform” because it allows NHS entities to access and build various functions to make use of the data within it, such as big-picture analytics and specific apps. The stated aim of the FDP is to improve data systems “for strategic and operational planning”.

The five stated use cases for the FDP are:

• Elective recovery (reducing waiting lists at the local hospital level)
• Care coordination (such as discharge planning)
• Vaccination and immunisation (with a focus on uptake and health inequalities)
• Population health management (planning NHS services at the ICB level)
• Supply chain management (at the local hospital level). 

These use cases are broad and vague, which allows for unaccountable evaluation and monitoring. This briefing therefore focuses on data capabilities.

The FDP combines multiple data capabilities under one software platform, which is used in different parts of the NHS. However, very few of these general data capabilities are unique to the FDP nor is using one software platform the best way to interconnect data. In response to this, Palantir made a claim that: “Providing multiple capabilities as part of one software platform is…essential to the success of the FDP” .

Centralising data capabilities under one platform has significant drawbacks, as outlined in our previous briefing, and by the House of Commons Science, Innovation and Technology Select Committee. Issues include the high risk of vendor lock-in, distorting competitive markets, creating a single point of failure of NHS data and limiting in-house innovation. There is also no guarantee that centralising data onto one platform increases the quality or usefulness of that data for patient care, analysis or service planning. 

Data capabilities similar to those in FDP apps already exist across multiple NHS-built platforms and external providers already working collaboratively with the NHS. In a letter to NHS England the Chief Data and Analytics Officer of the Chief Data and Analytical Officers Network has stated that many systems “already have similar tools in use that presently exceed the capability and application of what the FDP is currently trying to develop or roll out at a system level”. To deliver a national data project aiming to connect disparate datasets at the local, regional and national levels of the NHS, the government should learn from and scale up existing NHS innovation that achieves advanced data connectivity at a local and regional level.

Many data capabilities could also be built in open-source tools. Data experts generally consider open-source software to be the gold standard for transparency and accountability. Open-source software uses publicly available coding languages, such as Python and R, rather than proprietary code. This helps to prevent vendor lock-in, support in-house innovation and enable local customisability. 

The open-source software community, which includes many NHS staff, are a huge potential resource for building alternative data systems. For example, the NHS Open Analytics Community helped to build the award-winning open-source RTT (Referral to Treatment) planner tool for elective waitlist modelling. This is one of the many benefits of investing in in-house professional development and retention. Some private providers make their software open source, partially or fully, or take other measures to avoid vendor lock-in and maximise transparency.

This briefing does not attempt to suggest a like-for-like replacement for all of the FDP or Palantir’s services. Rather, it intends to provide examples of key data capabilities that could be utilised to improve NHS data and digital infrastructure systems after the government terminates the FDP contract with Palantir. 

Locally-used applications

Within the FDP platform, the apps (sometimes referred to as products or modules) available to trusts include Cancer 360, Crisis Response, Inpatient CCS, OPTICA, Outpatient CCS, Patient Led Validation, RTT Validation and Shared PTL. These apps are not an example of federating data, but are operational apps. 

Clinical and non-clinical apps and software for hospital data management – such as planning discharges, managing waiting lists, and coordinating theatre scheduling – are provided by a huge number of providers, and also developed in-house in some NHS trusts. Many of these application capabilities were present in large parts of the NHS before the FDP. 

For some trusts or staff, the FDP app offerings are equivalent or even offer less functionality than their existing infrastructure, with one hospital noting they would “lose functionality rather than gain it”. 

For others, the offerings from the FDP’s apps may be an improvement on their existing data architecture, especially if they are, at baseline, digitally immature trusts. Since similar apps are often available as part of a patient administration system or electronic patient record, the FDP may in these cases be plugging a baseline digital capability gap rather than providing a unique benefit. 

Some of the key claims made by NHS England to defend the FDP, such as improved theatre efficiency and reduced waiting lists for local trusts, have been widely criticised and are currently under investigation by the Office of National Statistics (for more information see Appendix 1). However, the NHS may still wish to attempt to retain some of these apps after terminating the contract with Palantir. 

Given that the NHS England Palantir contract states that Palantir owns the “Specially Written Software” within the FDP, and that FDP products are built on Foundry, these apps are likely to require rebuilding to work without using Foundry. This is possible, as illustrated by the Homes for Ukraine scheme, which saved millions of pounds by building an in-house version of software that was previously provided by Palantir and had been built on Foundry. 

When we asked Palantir about this, a spokesperson stated that, should NHS England wish to transition away from the FDP: “NHS England will have app configuration files, underlying code written in open source languages as well as supporting documentation. Depending on the replacement supplier, these apps can be reused either in a plug-and-play manner or easily adapted to operate on the new platform.” Experts have raised concerns about this possibility and have argued it would be challenging to move off Palantir software for multiple reasons, including the fact that the API contains a trademarked name. Overall, this requires further investigation in order to inform a phased transition away from Palantir’s FDP. 

Alternative options for delivering data capabilities

NHS body	Desired data capability (This is not an exhaustive list, but examples of some of the FDP’s capabilities)	Explanation	Alternative examples with similar capabilities, many of which are already in use across the NHS (This is not an endorsement of any particular product or an exhaustive list – any external providers listed are for example purposes only)
NHS England	Data analytics and visualisation	Allows national NHS data teams to ingest and analyse data such as vaccine uptake and diabetes national screening	Open source coding solutions such as Python, Visual Studio, R and R Studio Specific software solutions provided by small UK companies such as Health Data Insight CIC General software solutions such as Faculty AI, Power BI, Tableau
Integrated Care Boards	Population health data analytics	Allows regional level population health analytics that support service planning	Open source coding solutions such as Python, Visual Studio, R and R Studio Providers such as Graphnet, Optum, and Voror
Acute trusts	Locally used applications for operations and data management	Allows trusts to use data and analytics for decision making and planning, such as planning discharges, scheduling theatre times, and reviewing waiting lists	These functions are commonly available as specific apps or added onto electric patient records Options include EPIC, MBI Health, Acumentice, EMIS, Civica, VitalHub and in-house tools built in open source
Connecting data systems	Data ingestion and pipelines	These features describe common data engineering capabilities that are required for data warehousing and connectivity, for example sharing waiting lists, regional data analysis, and connecting clinical records	Providers such as Matillion and Voror
	Data integration and shared record* (*not an FDP capability)		Providers such as Graphnet and Voror
	Data storage and warehousing		Providers such as Snowflake, Azure, Voror, GCP, or Private Cloud
	Identity resolution / linking		Providers such as Quantexa

ICB and national level analytics

The FDP includes analytical tools for carrying out analysis on datasets available within the FDP. Some data for analysis exists only in the FDP, but many data flows and analytics projects are continuing outside of data FDP infrastructure. FDP AI tools call on large language models (LLMs) that are also available outside of the FDP. 

Medact has engaged with many data and digital professionals who use the FDP and other tools at an ICB or national level, multiple of whom have stated that the analytical tools within the FDP do not provide benefits over existing tools. You can read more about this in our previous briefing. Further concerns from data analysts and engineers are discussed in the London Review of Books and Democracy for Sale. 

Advanced data analytical capability existed within NHS England and ICBs before the FDP, in terms of both software and professional expertise, and remains in place outside of the FDP. This capability may not need to be exactly replaced in order to terminate the Palantir contract.

In fact, many ICBs have established mature systems for local population health data analysis with the buy-in of GP practices. Experts argue these established data practices have been threatened by the controversy surrounding the FDP. 

Existing NHS federation of data with similar capabilities

Federation of data is one important way to improve how data is used across the NHS and connect disparate datasets, locally, regionally and nationally. Federation is a widely utilised concept in data architecture, and is not something which can only be done using big tech companies or a single-software. NHS Greater Manchester’s Analytics and Data Science Platform (ADSP) is an example of a highly-effective, NHS-led and multi-vendor, regional federated data platform – see the case study below.

Palantir claims that: “There are over a hundred federated instances of the platform across the NHS, each with its own data controller and nuanced configuration to be suitable for its organisation.” However, it is essential to define what we mean by federation, since experts have argued that the FDP programme, as it stands, does not truly enable a federated query architecture,  since it relies on organisations using a centralised software, and migrating their data onto that system. 

A common definition of a federated query architecture is that it lets multiple independent systems, including different software and data sources, collaborate without physically moving or duplicating data. Under this definition, when data is truly federated, each organisation that data originates from retains independence over storage, location, access and software they use for their data. There should not be a need to centralise everything in one software, as federated query architecture connects data sources virtually so that queries can run across them as if they were a single database, but the data sources exist separately to the analytics software. This is further explained in the figure below.

Any future procurement must clearly define what is meant by federation, and avoid restricting local innovation or software options as part of delivering it. There are NHS-run examples of large-scale, highly-functional and trusted regional federation and/or interconnectivity of data. 

As well as enabling data analysis and service planning regionally, some of these projects also include a shared care record, which is not an FDP capability. For example, OneLondon has created a London Patient Record connecting patient records from different sources (including GP, hospital and community data). The data warehousing provider, a UK-based SME, also enables analysis of regional trends such as admissions, ambulance calls and vaccination uptake. A similar initiative also exists in the North East and North Cumbria – the Great North Care Record – and OpenSafely enables a wide range of data sharing for research purposes. These examples can be scaled-up and learned from.

Consistency and connectivity across data 

In order to achieve meaningful connectivity between disparate data sources, interoperable data is essential. In the FDP, the approach taken to connecting data sources is to migrate significant amounts of data to one platform and its associated data warehousing. However, this is not the only approach, nor the most flexible or modern. 

The alternative approach is to concentrate on enforcing standards that make data interoperable across the NHS, allowing different bodies to use different systems and software at a local level, while the data itself can easily be federated to integrate it where required.

Using a common data model, common ontology, and data standards (such as FHIR, Health Level 7 and open EHR) are all methods of ensuring a common unit of currency is used across data warehouses and datasets. For example, data standards ensure that each trust reporting an ‘appointment cancellation’ is reporting something that means the same thing, regardless of the reason that might sit behind the cancellation such as ‘doctor unwell’ or ‘patient did not attend’. 

An example of common data models in the context of FDP is the Canonical Data Model (CDM). This is essentially a shared blueprint for how data should be structured and described so that different systems can understand and exchange information consistently. The NHS has a Data Dictionary for this purpose, as well as a CDM, that is published and designed to be supplier agnostic. 

The FDP has its own CDM that follows this same principle but appears to be tied to the technology of its supplier, Palantir. It provides a logical model that ensures all data inside the FDP is organised in a uniform way, but experts consulted for this briefing raised concerns that the consistency depends on Palantir’s proprietary software (Foundry). In other words, while the NHS already has a CDM that aims to be open and vendor‑neutral, the FDP CDM achieves standardisation by enforcing one supplier’s interpretation of the model – making it useful within FDP, but not necessarily across other platforms. 

In response, Palantir stated that: “[the CDM] can be expressed in many formats completely independent of Palantir software. There is already an OpenAPI (An open-source standard for expressing APIs) specification for the CDM on NHS England’s Github account (here). This standard API specification communicates over an open protocol called HTTPS. The intent of a standard API is to allow consistency in communication between different software solutions. Any software product that can communicate with an HTTPS API (i.e. all software developed in the last two decades) will be able to integrate with the CDM API, regardless of whether it is built with Palantir’s software or on another platform. This is true today regardless of whether the NHS seeks to exit the contract.”

This requires further investigation to inform a phased transition away from a Palantir-run following a decision not to renew the contract in February 2027. Either way, the NHS can build, and already has built, canonical data models independent of Palantir’s FDP.

Section 2: Principles of an alternative data architecture

This briefing argues that implementing an ‘alternative’ to the FDP cannot make the mistake of looking for a big tech company or single-software, and must instead avoid vendor lock-in and prioritise NHS-led innovation. An ‘alternative’ to the FDP should take an ecosystem approach and be created bottom-up to retain public trust, as well as prioritise staff buy-in, local autonomy and data sovereignty. In order to realise the benefits of data capabilities within NHS systems, software and services must be procured, delivered and evaluated in line with the three key principles outlined below.

1) Support NHS-led innovation and avoid vendor lock-in

Support locally-led innovation and infrastructure. NHS-led, collaborative data initiatives in local areas have already led to connectivity that saves lives and improves care in London, Manchester, and North East and North Cumbria. The government should support localised data initiatives, which can meaningfully engage communities and clinicians, design for locally-specific needs, and build bottom-up data infrastructure. Any national data projects must have clear parameters and defined purpose, and not be imposed top-down.

Prioritise in-house innovation and collaborative external providers. The government must reduce reliance on large software suppliers, invest in in-house innovation and minimise vendor lock-in. Funding should prioritise developing platforms that are NHS-led and ‘supplier agnostic’ – i.e. able to substitute external suppliers in and out as required. Where external suppliers are used, the government should prioritise those which adhere to open standards, interoperability and ethical procurement requirements, and do not pursue technical or contractual dependency. 

Invest in data and digital workforce capacity. Rather than outsourcing analytical skills to a software provider or consultancy services, the government must invest in the recruitment, development, and retention of NHS data and digital professionals who carry institutional knowledge, clinical context, and professional accountability that no software can replicate. 

Set national standards and procurement rules. These are needed to drive interoperability across the NHS. This includes committing to setting and enforcing national health data standards and encouraging the use of open-source software where possible. The use of AI within healthcare contexts needs clear governance infrastructure before any roll-out. 

2) Protect patient trust and the values of the NHS constitution

Define an ethical procurement policy. The NHS should develop and enforce a human-rights and ethical procurement assessment, informed by technology and human rights experts, and centering NHS values such as patient centricity and public interest. 

Protect patient trust. Any platform that connects data at the regional or national level must have privacy at the core, including protecting patient-identifiable data from external actors and other government departments. Strict access controls on patient-identifiable data must be enforced and documented. A strict firewall between any nationally accessible patient-identifiable data and other government departments, such as the Home Office, should be implemented.

Ensure transparent governance. An independent oversight body with representation from data professionals, clinicians, patients, ethicists, and legal experts, with published decision making and genuine accountability over data use cases, should be created for any national or regional data connectivity platforms or programmes. 

3) Design and procure based on evidence and need

Evidence-based design and evaluation. Any platform must be defined by the people who use data in their NHS work, not designed by a commercial supplier’s product roadmap or a desire to simply collect more data. Procurement must be rooted in a clearly defined problem and specific requirements. Evaluation of products must be rooted in genuine evidence and specific outcomes, not a desire to prove success, and avoid the ‘magical thinking’ that software adoption automatically causes an improvement in patient care. 

Avoid techno-solutionism. Whilst good data infrastructure is important for clinical care, data procurement must avoid thinking of technology as a default or fix-all solution for complex systemic problems, such as secondary care waiting lists or availability of GP appointments. Rather, technology should follow clinical and social needs, as part of an overall programme of change.

Section 3: Mitigating potential disruption

Recent information published in the The BMJ indicates that ending the FDP contract would not significantly disrupt as many organisations as official figures suggest, due to seemingly low and shallow uptake of the software. This presents an important window of opportunity to discontinue Palantir’s contract before its software is deeply embedded in the NHS.

However, any exit plan needs to account for those organisations which rely on the FDP for some operational activities, and thus would experience a level of disruption. This is particularly true for digitally immature trusts, where the FDP may represent an improvement compared to their digital baseline.

The government could use the money immediately saved by not extending the contract to support organisations to understand why the FDP is adding value in their situation. The government can then support these organisations to transition away from Palantir-provisioned FDP apps by implementing a ‘baseline upgrade’ programme, supporting the most digitally immature trusts to improve their systems, in line with the above outlined principles, with mentorship and support from more digitally mature trusts. 

We are also alarmed by the staffing cuts to NHSE, ICBs and commissioning support units (CSUs), which are drastically reducing the number of data and digital professionals working for the NHS. These job losses risk harm to critical NHS data architecture. Quality data systems need skilled staff with subject-matter expertise, regardless of the software. A risk assessment of all job losses so far should be carried out, followed by the creation of a long-term workforce investment plan to retain skilled data and digital professionals across NHS institutions.

Conclusion & recommendations

This briefing argues that an ‘alternative’ procurement for the FDP presents a critical opportunity for the government to move away from dependency on large software suppliers, and instead take an ecosystem approach to procurement with a focus on improving data systems across the NHS with NHS-led innovation and appropriate external collaboration. 

Any ‘alternative’ to the FDP must be specific to what is actually needed, where and why. Many of the data capabilities the FDP is supposed to offer already exist in similar form within NHS infrastructure, including innovative NHS-led data connectivity projects such as regional federation, which can be supported, learned from and scaled up. 

Any ‘alternative’ to the FDP must also be underpinned by a strong set of principles, so that any future procurement supports NHS-led innovation, avoids vendor lock-in, protects patient trust and the values of the NHS constitution, and is designed and procured based on evidence and need.

Recent evidence has shown that the FDP is not as embedded as official figures suggest, and the benefits claims are under intense scrutiny. This creates an important window of opportunity to move away from the platform safely, with support for the organisations that really need it. 

The government can choose to invest in NHS-led innovation which retains public trust, and build data systems which are fit for the future, if it commits to avoiding the same mistakes that were made in the procurement of the FDP. 

This is a commitment that will take time to realise and build. However, the government can feasibly take bold steps towards this in the next year. 

Within the next year, the government should: 

1. Announce the intention not to extend the Palantir FDP contract beyond February 2027, and begin full exit planning. This should include:
   • a ‘baseline upgrade’ programme, supporting the most digitally immature trusts to improve their systems and transition away from FDP apps if required
   • a risk assessment of job losses within data and digital professionals, and beginning to design a long-term workforce investment plan to retain skilled data and digital professionals across NHS institutions.
2. Conduct a thorough review of existing NHS data infrastructure, especially regional level data federation and data connectivity programmes, that could be scaled up and learned from, to inform any new procurement that may be required. 
3. Redesign any future procurement based on the following three principles:
   • Support NHS-led innovation and avoid vendor lock-in
   • Protect patient trust and the values of the NHS constitution
   • Design and procure based on evidence and need.

Appendix 1: Benefit claims

NHS England and Palantir have both made significant claims about the benefits provided by the FDP and the scale of the adoption of the FDP. These claims have come under significant scrutiny, and NHS England is currently under investigation by the Office for National Statistics. 

Benefit claims have been challenged on a number of grounds, including:

• Benefit claims at specific hospitals may have conflated correlation with causation by attributing all positive change to the FDP, when it may, for example, have been post-pandemic recovery. This was first revealed in the British Medical Journal. 
• The Financial Times reported that some national claims rely heavily on a very small number of hospitals.
• Also reported in the Financial Times, some local hospital data used to make national claims was based on potentially faulty data. 
• The number of trusts meaningfully using the FDP appears to be lower than national rollout figures suggest. This was revealed in articles in Democracy for Sale and the British Medical Journal. 

Palantir was provided with the opportunity to respond to this briefing. Where relevant, their responses have been recorded in the text. They also sent the following relevant comment regarding the benefits claims discussed in this Appendix:

• “Initial rollout of FDP has been successful, particularly when compared with legacy NHS IT projects. 170 NHS organisations have signed up to the platform, 139 are live and 137 are already delivering benefits.”
• “The platform has supported over 111,589 additional operations, with 348,084 patients discharged using the app leading to a 13-15% reduction in unnecessary hospital stays. A million outdated waiting list entries have also been safely removed. It is rated ‘green’ by the Major Projects Authority – one of 30 out of 213 major government projects to receive that rating, and has an estimated benefit-cost ratio of £4.92 for every £1 spent.”
• “Trust adoption of FDP apps is a choice made by the trusts themselves, based on the gaps they identify in their existing infrastructure – not something imposed on them. Numerous clinicians and NHS leaders across trusts have spoken publicly about the efficiency and patient-care improvements the FDP has delivered compared to what they had before.”
• “As set out by NHS England officials (example here), trusts are adopting the FDP tools at different times and from different starting points. It is normal that trusts like Chelsea and Westminster that have had access to the tools the longest and engaging most deeply are seeing the most benefits, and usage and benefits data should be interpreted in this context.”