It is the question landing in NHS data and digital leaders' inboxes more than any other right now: if we're onboarding to the Federated Data Platform, do we still need our own data warehouse? Finance hopes the answer is no, because decommissioning a warehouse looks like a saving. Analysts fear the answer is no, because the warehouse is where their work actually happens. Both are looking at the same platform and drawing opposite conclusions.

The short answer is that the FDP does not replace your local data warehouse. The more useful answer is why - and what the right relationship between the two actually looks like. Getting this wrong is expensive in both directions: rip out a warehouse you still need and you lose analytical capability you'll scramble to rebuild; treat the FDP as just another reporting tool and you miss most of its value. This post sets out a clear, vendor-neutral way to think about it.

Why the question keeps coming up in 2026

The pressure is real and it is new. The FDP has moved from an optional innovation to a foundational expectation. By the end of January 2026, around 110 trusts were live or in delivery, and roughly 81% of providers had signed up - and national planning guidance now frames FDP onboarding as a baseline, not a choice.

When something becomes mandatory, two reasonable instincts follow. Leaders look for what they can stop doing to offset the new commitment, and they look for overlap to avoid paying twice for the same capability. A national data platform that "brings your data together" sounds, on the surface, exactly like what a data warehouse does. Hence the question.

The confusion is understandable. It is also resolvable once you look at what each thing is actually for.

What the FDP actually is - and what it isn't

A common misconception is that the FDP is an EPR, or a replacement for one, or a giant central database that swallows your data. It is none of those. The FDP is best understood as an operational intelligence layer that sits on top of your existing systems - EPRs, clinical systems, and yes, your data warehouse - and connects their data to support decision-making, resource planning, and a set of nationally developed products such as waiting-list management and discharge planning.

Two design choices matter for our question:

• It's federated, not centralised. Each trust runs its own instance and remains the data controller for its data. Information is largely accessed in situ through a shared data model rather than copied wholesale into one national repository. This is a deliberate response to the trust-mistrust problems of earlier centralisation attempts.

• It's standardised around national use cases. The platform's strength is consistency - a shared ontology so that "a patient on a waiting list" means the same thing everywhere, enabling comparable, near-real-time operational insight across the NHS.

That standardisation is exactly why it cannot be your only data platform. The FDP is optimised for nationally defined, common operational use cases. Your trust's analytical life is full of things that are neither national nor common.

The "modern data warehouse" nuance - addressed honestly

There is a wrinkle worth being straight about, because it's the source of much of the confusion. NHS England has introduced an operational management information use case that lets organisations use their FDP instance as a modern, cloud-based data-warehouse-style solution for certain statutory functions - and this genuinely advances the cloud-first ambition.

So the honest position is not "the FDP can never do warehouse-like things." It's that the FDP covers a defined slice of warehouse functionality aimed at standardised operational and statutory reporting. It does not, and is not designed to, absorb the full breadth of bespoke local analytics, research data management, and departmental reporting that a mature trust depends on. Treating a partial overlap as a total replacement is the mistake.

What your local data platform still has to do

Strip away the hype in both directions and a clear division of labour emerges. Your local data platform remains essential for:

• Bespoke and advanced analytics. The local, trust-specific questions - service-line profiling, custom operational dashboards, predictive modelling on your own cohorts - that no national product is built to answer.

• Research and secondary use. Standing up a Trusted Research Environment and governing secondary use of clinical data under the Five Safes is local work, tied to your IG, your researchers, and your population.

• Operational flexibility. The freedom to integrate niche systems, run ad-hoc analysis, and respond to local pressures without waiting for a national product to exist.

• Data quality and provenance. Critically, your local platform is where you assure the quality of data before it ever reaches the FDP - which brings us to the most important architectural point of all.

The answer is hybrid: three platforms, three jobs

The sustainable model that sector consensus keeps arriving at is hybrid - using the FDP for nationally defined capabilities and interoperability while keeping a local platform for everything bespoke. The cleanest way to make that concrete is to define three tiers and give each a single, unambiguous job:

1. The EPR is your system of record. It's where clinical data is created and lives authoritatively. It is not your analytics engine.

2. The FDP is your national operational intelligence layer. It ingests defined data for national use cases and standardised operational products, and connects you to the wider NHS through a shared model. It is not the home for your bespoke analytics or research.

3. Your Trust data repository is your local analytics and research platform. Cloud-first, it serves the advanced, bespoke, and research workloads the national layer isn't designed for - and it's where data quality is assured before it flows upward.

The discipline that makes this work is explicit boundaries: documenting which platform owns which data, where each data flow starts and ends, and the rules that prevent the same dataset being duplicated, re-keyed, and quietly diverging across three systems. Most of the pain trusts experience with the FDP is not a platform problem - it's an undefined-boundary problem. Draw the boundaries deliberately and the three tiers reinforce each other instead of competing.

It's worth naming why hybrid beats both extremes. A "national platform only" model strands your bespoke analytics and research and leaves you waiting on products that may never be built for your specific needs. A "keep everything local, treat the FDP as a tick-box" model forfeits interoperability, comparability, and most of the national investment that's already been made on your behalf. Hybrid is not a compromise between the two - it's the only design that lets each layer play to its strength: national consistency where consistency matters, local flexibility where it doesn't. The trusts getting this right aren't choosing between the FDP and their warehouse; they're being deliberate about which questions each one answers.

Get data quality right before the FDP, not after

One principle deserves to be stated on its own because it's where well-intentioned programmes most often come unstuck: data quality must be assured before data flows into the FDP, not afterwards. A federated intelligence layer surfaces and amplifies the quality of what you feed it - it does not silently clean it. Poor source data simply becomes poor data presented more confidently and shared more widely.

This is where the unglamorous foundational work pays off - rationalising legacy systems, retiring the ungoverned shadow databases where data is manually duplicated, and establishing clear ownership. The trusts that will get value from the FDP from day one are the ones whose local data foundations are sound first.

A practical first step: questions to ask before you decide anything

Before committing to keep, cut, or rebuild any part of your data estate, get clear answers to these:

1. What can only our local platform do - which bespoke analytics, research, and operational workloads have no national equivalent?

2. Where exactly is the overlap between the FDP's operational use cases and our current warehouse reporting - and is it total or partial?

3. Have we drawn the EPR / FDP / Trust-repository boundaries explicitly, with documented data ownership and flows?

4. Is our data quality good enough to flow into the FDP today - and if not, what has to be fixed first?

5. What would we lose if we decommissioned the warehouse, and have we genuinely priced the cost of rebuilding it?

If you can answer those five with evidence, you'll already be ahead of most of the conversations happening across the NHS this year.

At VE3, we help NHS acute trusts design the boundary between the EPR, the Federated Data Platform, and a cloud-first local data repository - so each platform does the job it's best at and the data flowing between them stays clean, owned, and trusted. If you'd like our one-page EPR–FDP–Trust boundary reference, get in touch.