Ask three people in a trust where a particular dataset "lives" and you can get three different answers. The clinician points to the EPR. The performance analyst points to the local warehouse. The transformation lead points to the Federated Data Platform. All three are partly right, and that is exactly the problem.

Most of the pain trusts experience when they bring an EPR, the FDP, and a local data platform into the same estate is not, at root, a platform problem. It's a boundary problem. Nobody has decided, explicitly and on paper, where each platform's job ends and the next one begins. So data gets copied three times, re-keyed, and quietly diverges; analysts rebuild reports that already exist elsewhere; and EPR–FDP integration projects stall in arguments about which system "owns" what. Draw three clean boundaries deliberately and the same three platforms stop competing and start reinforcing each other.

This post sets out where those boundaries should sit, the connective tissue that lets data move across them safely, and given the uncertainty around national platforms in 2026 - why getting this right is also your best insurance against change you don't control.

Three systems, one recurring source of chaos

The instinct, when a new platform arrives, is to ask "what can it do?" The more useful question is "what is it for, and what is it not for?" Without that discipline, every system expands to fill the space around it. The EPR grows reporting features. The FDP gets treated as a warehouse. The local platform hoards copies of data it doesn't own. Within a year you have three overlapping half-solutions and no single source of truth.

The fix is to assign each platform one primary job and hold the line on it. Here are the three boundaries that matter.

Boundary 1: The EPR is your system of record

Your Electronic Patient Record is where clinical data is created and lives authoritatively. When a clinician records an observation, prescribes, or documents an encounter, the EPR is the source of truth for that event. That is its job, and it does it well.

What the EPR is not is your analytics engine. Running heavy, trust-wide operational and performance analytics directly against a live clinical system is bad practice on every axis - performance, safety, and governance. The boundary here is clean: the EPR owns the clinical record; it does not own analytics. Data flows out of the EPR to the layers that do analysis; it is not where that analysis happens.

This boundary also forces a healthy question during EPR implementation: every "can the EPR report on X?" request is really a question about whether X belongs in the analytics layer instead. Answering it deliberately, rather than letting the EPR sprawl, keeps the record clean and the analytics properly resourced.

Boundary 2: The FDP is your national operational intelligence layer

The Federated Data Platform's strength is standardisation. It ingests defined data to support nationally developed operational products - waiting-list management, discharge planning, capacity and flow - and connects your trust to the wider NHS through a shared data model so that the same concept means the same thing everywhere. Used for what it's designed for, it's genuinely valuable.

The boundary is that the FDP is optimised for nationally defined, common use cases. It is not the home for your trust's bespoke analytics, your local operational quirks, or your research data. (We covered this division of labour in detail in our piece on whether the FDP replaces your data warehouse - short answer: it doesn't.) Treating the FDP as a general-purpose warehouse is the single most common way trusts end up disappointed with it: they push it to do work it was never scoped for, then conclude the platform has failed when really the boundary was drawn in the wrong place.

So: the FDP owns standardised, national operational intelligence and interoperability; it does not own your bespoke local analytics or research.

Boundary 3: Your Trust data layer is your local analytics and research home

The third boundary is the one trusts most often under-invest in, and it's the one that protects everything else. Your local, cloud-first data layer is where the work that is genuinely yours happens:

• Bespoke analytics - service-line profiling, custom 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 under the Five Safes, tied to your IG and your population.

• Operational flexibility - integrating niche systems and running ad-hoc analysis without waiting for a national product to exist.

• Data quality assurance - crucially, this is where you assure the quality and provenance of data before it ever flows up into the FDP.

The boundary: your Trust data layer owns local, bespoke, and research workloads, and is the quality gate for everything flowing upward. It is the most flexible of the three layers precisely because it's the one you fully control.

The connective tissue: FHIR and well-governed data flows

Three clean boundaries only work if data can move across them safely and consistently. That's a job for standards, not bespoke point-to-point plumbing. Modern NHS interoperability is built on HL7 FHIR (UK Core), which gives you a common, standards-based way to represent and exchange clinical data between the EPR, the FDP, and your local layer.

The practical implication is that integration should be designed as a small number of governed, standards-based flows rather than a tangle of one-off interfaces. (Migrating from older HL7 v2 messaging to FHIR is its own journey, and rarely a big bang - we've written separately about a realistic FHIR migration roadmap.) Two rules keep the flows clean:

1. Define direction of travel. Clinical data flows from the EPR. Quality-assured data flows up to the FDP. Nothing flows in a circle that lets the same dataset be edited in two places.

2. Document ownership at every hop. For each flow, record which system is the authoritative source, what transformation happens, and where the data is allowed to land. This is what stops the silent divergence that undermines trust in every downstream number.

Why boundaries are also your insurance against supplier change

Here's the part that has become unavoidably topical in 2026. National platforms - including the FDP - are subject to political decisions, contract reviews, and supplier changes that individual trusts do not control. Whatever happens at the national level, the trusts that will weather it comfortably are the ones whose architecture doesn't depend on any single national platform being permanent.

This is the quiet strategic case for the three-boundary model, and it aligns with the national direction of separating the data layer from any one application or supplier to avoid lock-in. If your bespoke analytics, research, and quality-assured data all live in a data layer you own, then the national operational layer becomes substitutable. The relationship with the national platform is an interface, not a dependency. Should the national picture change, you adapt a defined set of flows - you don't rebuild your analytical capability from scratch.

Put plainly: clean boundaries turn the national platform into a component you can swap, rather than a foundation you're stuck with. That's good architecture regardless of who supplies what - and in the current climate, it's also good risk management. The point isn't to bet for or against any platform; it's to design so that you don't have to bet at all.

A practical first step: five boundary questions

Before your next EPR–FDP integration decision, get explicit answers to these:

1. For each major dataset, which single system is the authoritative source - and does everyone agree?

2. Are we asking the EPR or the FDP to do work that belongs in the local layer (or vice versa)?

3. Are our cross-platform data flows standards-based (FHIR) and documented - or a growing tangle of point-to-point interfaces?

4. Where is data quality assured, and does that gate sit before data reaches the FDP?

5. If the national platform changed, what would we have to rebuild - and how do we shrink that list?

If those questions are hard to answer today, that's not a failure - it's the most valuable piece of work you can do before the next phase of your data programme.

At VE3, we help NHS acute trusts draw and document exactly these boundaries - defining platform roles, FHIR-based data flows, and ownership across the EPR, the Federated Data Platform, and a cloud-first local data layer - so the estate is coherent today and resilient to whatever changes tomorrow. If you'd like our one-page EPR–FDP–Trust boundary reference, get in touch.