Your Hospital Can Choose Another Supplier. Its Own System Often Cannot.

After a bad week without results, the hospital’s management asks a sensible question. Could we send our tests to a second laboratory when the first one is down?

A second laboratory is found, and it is willing. Then the technology head explains the difficulty. The hospital’s own system was built around the first laboratory’s connection. Orders go out in that laboratory’s format, with that laboratory’s test codes. Results come back the same way and are read by a program written twelve years ago.

To use another laboratory, even for a day, that program would have to be rewritten. Nobody is sure how.

What We Found

We went through the public record on healthcare organisations that depend on an outside supplier’s systems, looking for two things: what happens when such a supplier stops, and what stops a hospital from switching, falling back or getting a second quote.

We say one thing first, because it shapes everything below. Nothing we do will stop a supplier’s system failing. We provide no fallback, and we make no arrangement with any supplier on your behalf. What follows is about your own side.

When the supplier stops, the hospitals it serves stop too. In a recent case, ransomware hit a supplier of pathology services to hospitals in one European capital. According to a trade journal’s report, the hospitals it served, which were not themselves attacked, had to cancel surgery and clinic appointments on a large scale.

Suppliers that many providers route their work through can be stopped. A large US processor of health insurance claims was hit by a cyberattack, and a ransom was paid, according to a US congressional committee’s account of a hearing about it.

No public case measures the lock on the hospital’s own side. We found no public case of a hospital that could not switch supplier, fall back or get a second quote because of its own software, and none in healthcare of a supplier holding back code or knowledge. The record shows what a supplier’s outage does. It does not show whether the hospitals affected could have turned to another route.

Our reading, as engineers, is that two things tie a hospital to one supplier, and both sit on the hospital’s side of the contract. The first is wiring: the old application was written around one supplier’s connection, and that supplier’s codes and formats spread through it, so there is only one way in. The second is knowledge: where the supplier built the system, the only description of what it does sits with the supplier. We label this as our reasoning, not a finding.

What a Hospital Cannot Do While Its Own Side Is Wired to One Supplier

A dependence on one supplier is usually treated as a contract question. Our reading is that the larger cost is three things the hospital cannot do, whatever its contract says.

It cannot switch. The contract may allow it to leave. If its own system speaks only one supplier’s language, leaving means rewriting part of that system first, at a cost nobody can state.

It cannot fall back. A second laboratory or a second route arranged on paper is useful only if the hospital’s own system can take in what it sends. Where the connection is the only way in, even results that arrive on paper cannot be entered into the screens that use them.

It cannot get a second quote. Where the supplier built the system and holds the only description of it, no other firm can price a change. Every quote is the only quote.

This is our reading of the evidence. It is not a measured market figure, and no public case measures it.

Four Ways to Answer a Dependence on One Supplier, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
Rely on the contract and the supplier’s service terms	The supplier is large and steady, the service could pause for days without stopping care, and the hospital has no wish to change	In our reading, a supply contract covers the supplier’s service, not whether your own side can work another way; what yours provides is a question for your own legal adviser. On the day, it does not bring the results in
Arrange a second supplier or a manual route, without changing your own system	The connection is simple, or the hospital’s clinicians and laboratory head have decided that a paper route may be used for a short time	Your own system may not accept anything from the second route. Staff carry paper, and nothing reaches the screens that need it. Whether a manual route is acceptable for laboratory results is for your clinicians and laboratory head to decide
An assessment only: the map of what depends on each supplier, and a specification that is yours of any system a supplier built	You need to know what you depend on, and what you would be leaving, before you decide anything	It costs money before anything changes, and it changes nothing on the day by itself. The map goes stale unless someone keeps it
Rebuild the part of your own application that connects to the supplier, as one module, so it can be pointed to a second supplier or a manual route	The board has looked at the map and decided it will not carry a particular dependence	It costs money to change something that works today. It does not make the present supplier more reliable, and the second route must still be found, contracted and paid for by you

Where You Are Now, and Where You Should Be

Before the next renewal or the next request for a fallback, we would set a benchmark for the decision itself.

Measure	Typical starting point	Where it should be	How it is checked
Share of outside connections listed, each with an owner and what stops	None	Every connection from your own applications	The map and the risk register
Connections that can be pointed to a second route without rewriting the rest of the application	None	Every one the board decides not to carry	Signed acceptance for each rebuilt module, and its traceability matrix
Share of a supplier-built system’s behaviour in a specification that is yours, confirmed by your own experts	None; the supplier holds it	Every part in use	The specification
Whether a second supplier could quote a change from that specification	No; only the present supplier can	Yes, subject to your own contract with your present supplier	A change described from the specification alone, without asking the present supplier

The starting points above are what we expect to find. In an engagement they are replaced by your own position, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a healthcare organisation.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about your suppliers, the applications wired to them, and what you would want to be able to do if one of them stopped. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. It reads your own applications, not the supplier’s systems. It produces a map of each application as it stands, showing which parts depend on each supplier’s system and what stops if that system stops, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the part that connects to a supplier, and a staged plan with a fixed quote. Where a supplier built the application, you arrange read-only access to its code with that supplier, as your contract allows; that step is yours, and we do not obtain code from a supplier. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
4. If you approve, we build. We rebuild only the part of your own application that connects to a supplier, as one module, while the old application keeps running, so that it can be pointed to a second supplier or a manual route if you arrange one. We never do a single cutover. A traceability matrix links each old function of that part to its replacement. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module. Where the module touches clinical work, accepting it is your clinicians’ decision.
5. We review against the benchmark. Before work starts we set the benchmark. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

What you need to bring: read-only access to your own applications once the assessment begins, arranged by you with any supplier that built them, as your contract allows (that step is yours, and we do not obtain code from a supplier); laboratory, billing and operations staff to confirm what must arrive and in what form; and your current team or supplier keeping the old application running throughout. What a contract lets you show another supplier is a question for your own legal adviser; we give no legal advice on contracts or on who owns code or data.

What changes for the business:

Role	What they gain
CEO	Changing or adding a supplier becomes a business decision, not something the old system forbids.
CTO or CIO	The part that talks to the supplier is rebuilt so the supplier can change without the rest being rewritten.
CFO	A stronger position at renewal, because the cost of leaving is known and smaller.
COO	When a supplier is down, the organisation’s own system can still take in what it needs by another route.
Risk and compliance	Any exit plan in the supplier’s contract is one the organisation’s own system could actually carry out.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
Ransomware hit a supplier of pathology services to hospitals in one European capital, and the hospitals it served had to cancel surgery and clinic appointments.	Our part is much narrower than this case. We cannot stop a supplier failing, and we do not supply a fallback. We map what depends on the supplier, and can rebuild the connecting part of an organisation’s own application so that it could use another supplier or a manual route, if the organisation arranges one.
A large US processor of health insurance claims was hit by a cyberattack, and a ransom was paid.	Our part is narrower than this case. We do not assess or secure a supplier, or arrange a second one. For an organisation that relies on one, we show where its own applications connect to it.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We do not choose your suppliers; we make sure your own system can follow the choice your board makes.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →