When a Supplier's System Stops, a Hospital Learns What Depended on It. That Can Be Known Beforehand.

At seven in the morning the laboratory supervisor sees that no results have come in overnight.

The samples went as usual to the outside laboratory the hospital has used for years. A call to the supplier brings a short answer. Their systems are down. They do not know for how long.

By nine the hospital is finding out, one department at a time, what that means. Theatre lists cannot be confirmed. The pharmacy is holding orders. The discharge desk is waiting. Nobody had ever written down everything that waits on those results.

What We Found

Before we suggest anything to a hospital group, a laboratory chain or a pharma company, we study its sector. For this article we went through the public record on healthcare organisations that depend on an outside supplier’s systems: a US congressional committee’s account of an attack on a claims processor, a trade journal’s report of an attack on a pathology supplier, and a trade-press article written by a technology vendor’s executive, from 2024 to 2026.

We should be plain before the findings. Nothing we do on your side will stop a supplier’s system failing. We provide no fallback, and we make no arrangement with your suppliers. This article is about the part that sits in your own hands, which is smaller and usually neglected.

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. The hospitals it served were not the ones attacked. Even so, according to a trade journal’s report, they had to cancel surgery and clinic appointments on a large scale.

Suppliers at the centre of how care is paid for are attacked too. 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. We cite it for one point only: a supplier that many providers route their work through can itself be stopped.

A supplier’s own old systems are part of what you depend on. According to a trade-press article written by a technology vendor’s executive, a large US supplier of health record systems said that an attacker had used compromised login details to reach old servers that had not yet been migrated, and had taken data from them. The article gives no year and no figure for the effect. A hospital that depends on a supplier also depends on that supplier’s old systems, and cannot see them.

Inside the hospital, the connections sit in old code. This finding is our reading, not the record’s. In an old application, the link to a supplier’s system was written once, for that supplier. The parts that use what arrives on it were added over the years by different people: a results screen, a theatre schedule, a pharmacy check, a discharge summary, an overnight report. Nobody can list everything that waits on a supplier without reading the application.

Our reading of these four findings: a supplier’s failure becomes a hospital’s failure through connections the hospital built itself, and those connections are rarely listed anywhere. The supplier’s system is out of the hospital’s hands. The list of what leans on it is not.

What a Hospital Cannot Decide While the Map Is Missing

A supplier usually appears on the risk register as one line. Our reading is that the larger cost is the decisions that cannot be made while that line is all there is.

Which supplier matters most cannot be decided. Without knowing what waits on each connection, every supplier looks the same size.

Where to spend on a fallback cannot be decided. A second laboratory or a second route costs money, and without a map that money tends to go to whichever supplier failed last.

Who acts on the day cannot be decided. A dependence nobody has listed has no owner.

And what to tell the board cannot be decided. “Third-party risk: medium” reports a feeling, not a position.

This is our reading of the evidence. It is not a measured market figure.

Three Ways to Find Out What Leans on a Supplier, Weighed

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

Option	When it fits	What it risks
Keep the supplier as one line on the risk register, and rely on the contract	The supplier’s service could stop for days without stopping anything important	The line says nothing about what stops. On the day, departments find out by trying to work
Ask each department to list what it receives from each supplier	The hospital is small, and its applications are few and well known	Departments list what they see. The links buried in old applications, and the overnight jobs nobody thinks about, are missed
Read the hospital’s own applications, list every connection to an outside system and what waits on it, and have each department confirm its part	The hospital runs older applications of its own, connected to several suppliers, and nobody has drawn the picture	It costs money before anything changes. It changes nothing on the day by itself: what to do about each dependence is still the hospital’s decision. And the map goes stale unless someone on the hospital’s side keeps it

Where You Are Now, and Where You Should Be

A recommendation is only useful if you can tell later whether it worked. So before any work begins we set a benchmark: a few measures taken from your own organisation, each with a target.

For this issue, the benchmark would look like this.

Measure	Typical starting point	Where it should be	How it is checked
Share of outside connections listed, each with an owner and what stops if it stops	None; one line for “third parties”	Every connection from your own applications, each with an owner and what stops	The map and the risk register
Dependences with a decision recorded	None	Each one either carried knowingly or marked for change, by the board	The risk register
Connections that could be pointed to a second route without rewriting the rest	None	Those the board decides not to carry	Signed acceptance for each rebuilt module
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

The starting points above are what the public record suggests and what we expect to find. In an engagement they are replaced by your own figures, 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 that connect to them, and what you already know of what waits on each. 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. Here it reads your own applications, not the supplier’s. It produces a map of each application as it stands, showing which of its 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. 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 another route if you arrange one. We never do a single cutover. 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.

This approach has limits, and we state them plainly. A map prevents nothing: the supplier’s system can still fail, and your services can still stop. We do not assess a supplier’s security, write continuity plans or supplier contracts, or give legal advice on what a contract covers. We do not work on packaged health record products or on a supplier’s own systems.

What changes for the business:

Role	What they gain
CEO	The board knows in advance which services depend on which supplier, and chooses which dependences it will carry.
CTO or CIO	A map of every connection from the organisation’s own applications to outside systems.
CFO	Money for fallback arrangements goes to the dependences that would cost most.
COO	Operations knows which desks stop when a supplier does, and has decided beforehand what each will do.
Risk and compliance	Supplier risk is recorded as named dependences with owners, not as one line that says “third parties”.

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’s system failing, and we provide no fallback. We map which of an organisation’s own applications depend on each outside system, so it knows beforehand what would stop.
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. For an organisation that relies on one, our assessment shows where its own applications connect to it.
A large US supplier of health record systems said an attacker had reached old servers that were waiting to be moved.	We do not work on packaged health record products or on a supplier’s systems. We read the organisation’s own applications, and the map we draw stays with the organisation.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We start with the map of what your own applications lean on, because that part is in your hands.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →