Why doesn't integration debt show up in the business case?
Every business case for replacing a core clinical system compares two numbers: the cost of the new system, and zero.
Zero is what the current system appears to cost, because its costs are already absorbed. The licences are in a renewed contract. The people who maintain the interfaces are on the establishment. The workarounds are in someone's daily routine. Nothing on that list arrives as an invoice labelled "cost of not modernising", so nothing on that list gets compared against the price of change.
This is not a finance failure. It's a visibility problem. The costs are genuinely distributed: a few days of an integration analyst here, a delayed departmental project there, a manual reconciliation someone has been doing every Monday for six years. Individually none of them justify a programme. Collectively they are the programme's entire business case, and nobody has added them up.
The software industry has a name for this. Technical debt describes exactly this dynamic: a deferred cost that accrues interest quietly and is only paid when you try to change something.
Where the cost actually accumulates
Integration debt accumulates in four places. Three are visible if you look; the fourth is the expensive one.
Interface count. A legacy PAS in a mature estate typically has dozens of point-to-point interfaces, each built at a different time, by different people, to different conventions. The cost isn't building them, it's that the number of things that can break grows faster than the number of systems. Every new departmental system added to an estate wired point-to-point makes the next one harder, not easier. We set out the arithmetic in point-to-point integrations vs an orchestration layer.
Tribal knowledge. Undocumented interfaces are maintained by memory. When the person holding that memory leaves, the interface doesn't stop working, which is what makes this so easy to ignore. It stops being changeable. The organisation keeps the capability and loses the option.
Change latency. This is the one that has operational consequences. When a clinical service wants a new data flow, how long does it take? In an estate with a modern integration layer, that's a configuration change measured in days. In a point-to-point estate against a legacy PAS, it's a specification, a vendor quote, a change window and a regression test, measured in months or quarters. The pattern behind that gap is described in why legacy integration engines cannot handle modern healthcare workflows.
Opportunity cost. The fourth one, and the one nobody measures. It's not the projects that took too long. It's the projects that were never proposed, because everyone involved already knew what the answer would be. A service that has been told "not without a PAS change" three times stops asking. That silence looks like stability on a project register.
The measure worth taking to a board
Most attempts to quantify technical debt fail with a board because they're expressed in technical terms. A board has no basis for judging whether forty interfaces is a lot.
Change latency works better, because it converts the problem into something a board already governs: how fast the organisation can do things. It is close to what delivery research calls lead time for changes, one of the few measures that reliably separates organisations that can change their systems from those that cannot.
The question to answer is narrow and answerable. *When a clinical service requests a new data flow, what is the median elapsed time from request to it running in production?* Then compare it against services that don't depend on the legacy system.
Two numbers, same organisation, same governance, same year. If one is two weeks and the other is two quarters, the gap is the debt, expressed in the unit a board cares about. It also reframes the conversation away from replacement, which is expensive and frightening, and toward capability, which is a decision people can actually take.
Why "we'll fix it when we replace the PAS" doesn't hold
The most common position is to defer integration modernisation until the core system replacement happens. It's a reasonable-sounding position and it has a structural flaw.
Integration debt is precisely what makes the replacement hard. Every undocumented interface, every piece of tribal knowledge, every downstream system that depends on a legacy quirk is an obstacle in the migration you're deferring to. Waiting doesn't reduce the work. It moves the work into the highest-risk phase of the most expensive programme the organisation will run this decade, and concentrates it there.
The phased approach in legacy EHR migration without a big-bang cutover depends on an integration layer already existing. Building that layer before the replacement programme means the migration starts with the hard part already solved. Deferring it means the programme has to solve it under time pressure, with clinical services waiting.
The decision that actually matters
The framing of "replace the PAS or keep it" is the wrong question, and it's the question that stalls.
The real question is where the integration layer lives. If the logic that moves data between systems sits inside the systems themselves, in each interface, each mapping, each point-to-point connection, then every system change is an integration change, and the estate is as rigid as its oldest component.
If that logic sits in a layer between the systems, the systems underneath become replaceable. Not easily, not cheaply, but possible. That's the property worth buying, and it doesn't require deciding the PAS question first. It's what makes the PAS question answerable later. What a healthcare integration platform actually is sets out what that layer has to do to earn the description.
Most Trusts that have got this right didn't start with a replacement programme. They started by moving one high-friction data flow off a point-to-point interface and onto a layer, then the next one. The replacement decision arrived later, and arrived easier.
