When the Laboratory's Supplier Stops

1. At a Glance

Issue study · From the public record.

Organisation type	Three suppliers to health organisations that were attacked: a pathology services supplier to hospitals, a large processor of health insurance claims, and a large supplier of health record systems
Size band	The suppliers: large. Our reader: a mid-size hospital group, laboratory chain or pharma company that depends on outside suppliers’ systems
Region	The pathology supplier: one European capital. The other two: United States. None in India
The decision at stake	What a health organisation can do, on its own side, about a supplier’s system it depends on but cannot control
The public outcome	When ransomware hit the pathology supplier, the hospitals it served, which were not themselves attacked, had to cancel surgery and clinic appointments on a large scale
Why it matters to a mid-size health organisation	Every hospital sends some of its work through outside systems. Nothing it does will stop a supplier failing. What it can hold is a map of what depends on each supplier, an own side that can work another way, and its own description of any system a supplier built for it

2. The Business Problem, in the Buyer’s Words

“Our tests go to one outside laboratory, our claims go through one processor, and our billing system was built and is hosted by a vendor. When the laboratory’s systems went down last year, we found out what depended on them by trying to work. We looked at a second laboratory, and our own system could not take its results. And when the auditor asks how billing works, we still have to ask the vendor.”

These words are imagined. They describe the decision as the research shows it, not a real conversation.

The organisation is caught between suppliers it cannot control and an own side it has never mapped. It cannot stop a supplier failing. It can decide what it knows, what its own system can do, and what it holds in writing.

3. What We Found

Method. We went through the public record on healthcare organisations that depend on an outside supplier’s systems: a trade journal’s report of an attack on a pathology supplier, a US congressional committee’s account of an attack on a claims processor, and a trade-press article written by a technology vendor’s executive, from 2024 to 2026.

A pathology supplier stopped, and the hospitals it served stopped too.

What	Public record
Who was attacked	The supplier, not the hospitals
What happened	Ransomware, recently
The effect on the hospitals it served	Surgery and clinic appointments had to be cancelled on a large scale
How the attackers got in	The report says it was not possible to determine
Old technology	The report does not tie the attack to it

A supplier at the centre of how claims are paid was hit. 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.

A supplier’s own old systems were reached. 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. No year and no impact figure are given.

What is and is not in a hospital’s hands. This division is our reasoning, not a finding of any inquiry.

Not in the hospital’s hands	In the hospital’s hands
Whether the supplier’s system fails	Knowing which of its own applications depend on that system, and what stops
How long the supplier takes to recover	Having decided beforehand what each department will do
The state of the supplier’s own technology	Whether its own system could use a second supplier or another route
What the supplier chooses to disclose	Holding its own written description of any system a supplier built for it

Our reading of why hospitals are more exposed than they need to be. These three are our reasoning from the record above. None is a regulator’s or an inquiry’s finding.

1. Nobody has listed what depends on each supplier. Connections were added to old applications one at a time, and the dependence runs wider than the contract suggests.
2. The hospital’s own system is wired to one supplier. That supplier’s codes and formats run through an old application, so a second supplier or a manual route cannot be used without rewriting it.
3. The supplier holds the only knowledge of a system it built. Nothing was written down on the hospital’s side, so every question, quote and change goes through the supplier.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
Rely on the contract and the supplier’s service terms	The supplier is large and steady, and its service could pause without stopping care	In our reading, a supply contract covers the supplier’s service, not whether the hospital’s own side can work another way; what any given contract provides is a question for the hospital’s own legal adviser	Right for the dependences the board chooses to carry, once it has the map
Arrange a second supplier or a manual route without changing the hospital’s 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	The hospital’s own system may not accept anything from the second route. Whether a manual route is acceptable for laboratory results is for its clinicians and laboratory head	The hospital’s business decision; it works only where the hospital’s own system can take what arrives
An assessment only: the map of what depends on each supplier, and a specification that is the hospital’s of any system a supplier built	The hospital needs to know what it depends on before it decides anything	Costs money before anything changes, and changes nothing on the day by itself	Our recommendation, first
Rebuild the part of the hospital’s own application that connects to a supplier, as one module	The board has decided it will not carry a particular dependence	Costs money to change something that works; the present supplier is no more reliable; the second route must still be arranged and paid for by the hospital	Our recommendation, only for the dependences the board decides not to carry

5. Our Recommendation, and the Decision It Asks of the Board

For a health organisation that depends on outside suppliers’ systems (a laboratory, a claims processor, a vendor that built and hosts an application): start with an assessment of its own side. Map which of its own applications depend on each supplier’s system and what stops if that system stops, and get a specification that is its own of any system a supplier built for it, on read-only access to the code that it arranges with that supplier, as its contract allows; that step is the organisation’s, and we do not obtain code from a supplier. Then rebuild the part of its own application that connects to a supplier, one module at a time, only for the dependences the board decides not to carry, so that each can be pointed to a second supplier or a manual route if the organisation arranges one.

6. Benchmark: Where You Are Now, and Where You Should Be

These are targets, not results. In an engagement the starting points are replaced by the organisation’s own figures, taken in the first review.

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 that supplier stops	None; one line for “third parties”	Every connection from the organisation’s 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 the organisation’s, confirmed by its 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 the organisation’s own contract with its present supplier	A change described from the specification alone, without asking the present supplier

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about your suppliers, the applications that connect to them, and what you can only answer by asking a supplier. 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 study 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. Where a supplier built an 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. 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. 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.
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.

8. What the Client Would Own

• The map: which of its own applications depend on each supplier’s system, and what stops if that system stops.
• The specification: what its systems do, in writing, confirmed by its own experts. The specification is the organisation’s, and it can show it to other suppliers, subject to its own contract with its present supplier.
• The risk register: each dependence, ranked, ready for the board’s decision.
• The cost comparison and the staged plan: keeping set beside replacing the connecting part, and each stage with a fixed quote.
• The traceability matrix: for every connecting part IOanyT rebuilds, each old function linked to its replacement, with how it was checked.
• The code: the rebuilt modules are the organisation’s. No runtime or platform fee.
• The filled-in benchmark: each measure, where it started and where it stands.

9. What This Approach Does Not Cover

• IOanyT cannot stop a supplier’s system failing, shorten its recovery, or see into it.
• IOanyT does not provide a fallback service, a second laboratory or a second claims route, and makes no arrangement with suppliers. Choosing, contracting and paying for a fallback are the organisation’s business decisions.
• The organisation arranges read-only access to the code with its supplier, as its contract allows; that step is the organisation’s, and IOanyT does not obtain code or data from a supplier.
• IOanyT does not assess a supplier’s security, write continuity plans or supplier contracts, or give legal advice on who owns code or data or on what a contract allows a client to show a third party.
• IOanyT does not work on packaged health record products, medical devices or their software, pharma plant control systems, or a supplier’s own systems.
• Whether a manual route is acceptable for laboratory results is for the organisation’s clinicians and laboratory head. Clinical acceptance of any module is the organisation’s own decision, made by its clinicians. Nothing here says IOanyT’s work protects patients or keeps care running.
• This study does not say IOanyT would have changed anything for the organisations described, or that IOanyT has done this work for a healthcare organisation.

About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.

About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.

10. Sources

Source	Used for
HIPAA Journal, 12 November 2025 (cited without link)	The pathology supplier: the attack, the effect on the hospitals it served, and that the way in could not be determined
House Energy and Commerce Committee, 3 May 2024 (cited without link)	The claims processor: the cyberattack and the ransom
Vendor-written article in trade press, 26 May 2026	The health record supplier’s old servers

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 on your side of the contract, because that is the part in your hands.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →