Comparable estate data across an ICB is a reasonable ambition. Getting there by putting every Trust on the same software is the most expensive route to it, and the least likely to arrive.
There is a version of the digital estates argument that sounds compelling right up until somebody costs it. If every Trust ran the same estates system, the data would be consistent by construction. Regional comparison would be straightforward. National reporting would stop being an annual reconciliation exercise. An ICB could see its whole estate in one place.
The logic holds. It is the implementation that comes apart.
What convergence would actually involve
Moving a Trust from one estates system to another is not a licence decision. It is a migration, and the visible cost is the smallest part of it.
- Years of asset history, condition survey data, maintenance records and compliance evidence have to be mapped into a different structure, and anything that does not map cleanly has to be decided on individually.
- Teams who know their current system well have to learn a new one while continuing to run a live estate with statutory obligations attached.
- Existing contracts expire at different points, so a regional estate programme either pays twice for several years or waits several years to begin.
- During the transition the regional picture gets worse rather than better, because some organisations have moved and others have not.
There is also a structural point that tends to get skipped. Trusts are not branches of a single organisation. They are sovereign bodies with their own boards, their own risk appetite, their own capital position and their own accountability. An acute Trust operating a large tower block has genuinely different requirements from a community Trust running eighty small sites. A system that suits one may be a poor fit for the other, and neither Board is obliged to accept a compromise chosen somewhere else.
Connect a federated data layer above existing systems
There is a less disruptive route, and it is already how integrated organisations in other sectors solve the same problem.
Leave each Trust’s operational systems in place, and connect the data layer above them. A common data environment pulls the relevant data from each system, normalises it into a comparable shape, and presents the regional or national view in one place. The principle is straightforward: it is not about connecting systems to systems, it is about connecting data to data.
Regional estate visibility does not depend on every Trust running the same software. It depends on every Trust’s data being readable from a common point. Those are different problems, and they have very different cost profiles. The federated route also leaves the investments each organisation has already made intact, which matters when those investments were made for good reasons and are working perfectly well inside their own boundaries.
The ambition is reasonable. It is the mechanism that needs rethinking.
What it does require, and where the work really sits
This is not a free option, and it is worth being honest about where the effort goes.
A federated layer only works if the data underneath it can be normalised, and normalisation is a definitional problem before it is a technical one. Two Trusts can both report gross internal area and mean different things by it. Condition grades applied by different surveyors against different scales do not compare, even when the letters match. Asset identifiers rarely follow a shared convention. None of that is solved by the extraction layer.
So the thing an ICB should be commissioning is not a procurement. It is an agreement:
- common definitions for the handful of datasets that regional decisions genuinely depend on
- a shared view of how they are measured
- clarity about who arbitrates when two organisations disagree.
That is a considerably smaller undertaking than replacing systems across a region, and what it produces outlasts any particular piece of software.
Where we fit
This is the work we do, and it is unglamorous by nature. Agreeing what a dataset means across organisations that have each had good reasons for defining it their own way takes sector knowledge and a degree of diplomacy, and it is rarely a technology exercise.
It is also why we built OPAL rather than buying a platform. OPAL already aggregates estate data across multiple organisations, holding one agreed baseline rather than one version per source, which is precisely the pattern a regional estate view needs: the data normalised once, into a shape everyone can work from, with each organisation’s operational systems left where they are. So this is not a theoretical model as far as we are concerned.
Most consultancies either advise or deliver but we do both. This means we are not handing over a data standard and leaving somebody else to make it work across a dozen organisations.
The question worth putting to any regional estate proposal
When a regional or national estates programme is being considered, there is a reasonably simple test. Does this require organisations to change the systems they run, or does it require them to agree what their data means?
The first is expensive, slow, and dependent on a level of alignment the NHS rarely has available. The second can be done inside a single financial year, and it delivers most of what the first one promises.
If you are shaping an estates data programme across an ICB or a group of Trusts, we are happy to talk through what a federated approach would involve and where the effort would genuinely need to go.
