When Hospital Systems Stop, Care Stops. Which Ones It Rests On Can Be Known Beforehand.

Once a year the hospital’s leadership runs an exercise. This year’s scenario: the main systems are unavailable for three days.

The facilitator asks the first question. Which applications, exactly, would the wards be unable to work without? The technology head lists six. The medical director says the list is missing the one that shows allergies. The operations head had assumed the pharmacy ran on its own. It does not.

An hour in, the room agrees on one thing. Nobody had this written down.

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 what happens to care when health organisations’ systems stop: reporting of the review after an attack on a national health service, an Indian medical journal, trade journals, a UK government review and published support dates, from 2018 to 2026.

We should be plain before the findings. Nothing we do will stop a system failing or being attacked. We do not keep systems running, respond to incidents or restore systems, and we do not write the procedures your staff fall back on. This article is about a smaller part, which sits in your own hands.

When a health service’s systems stop, care stops with them. In 2021 ransomware hit one European national health service. According to reporting of the review that followed, more than half of its acute hospitals had to cancel services. According to a trade journal, it took months to decrypt all of its servers and restore almost all of its applications. The reporting gives several causes: a phishing email, warnings that were not acted on, patching that was not effective, protection software not kept up to date, nobody with overall responsibility for cybersecurity, and tens of thousands of machines on an operating system that was out of support. An older case, far larger than most of our readers.

A hospital can lose its information system and go back to paper. An Indian medical journal describes a ransomware attack on a large public hospital in India that left its hospital information system out of reach, and sent its wards, clinics and laboratory back to paper records. The article adds that systematic data on what happened to patients during that period are not available. It does not say what the servers ran. An older case.

A hospital can be stopped by a supplier’s systems. 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. The report says the way in could not be determined, and does not tie the attack to old technology.

In pharma, the same failures stop production. Trade press records two large drug makers whose production was halted or disrupted by cyberattacks, both older cases. For one, the sources give the way the attack came in and, in an outside security engineer’s view, systems that had not been kept patched; for the other, the record names no technology.

Much of a health system’s technology is old. In January 2025 the UK government’s State of Digital Government Review reported, from survey responses, that around 10% to 50% of NHS trusts’ technology estates are classified as legacy, a definition that covers systems out of support from the supplier.

And the software underneath runs out of support on published dates. Windows 7 has been out of support since January 2020. Support for Windows Server 2012 and 2012 R2 ended on 10 October 2023, and the paid security updates sold after that ran to 13 October 2026. Windows Server 2016 follows on 12 January 2027.

Our reading: when the systems care rests on stop, the record shows cancelled services, paper records and halted production. What a hospital can settle beforehand is narrow: which of its own applications each part of care rests on, and which are most fragile.

What a Hospital Cannot Decide While the List Is Missing

Most risk registers carry one line for this: “IT failure: high impact”. Our reading is that the larger cost is the decisions that cannot be made while that line is all there is.

Which application matters most cannot be decided. Every department calls its own critical, and forty names look the same size.

Where to spend first cannot be decided, so renewal goes to whatever is easiest to start.

Which fallback plan to write cannot be decided. A department prepares for losing the application it can see, and is stopped by one that quietly fed it overnight.

And the clinicians are not asked, though how much care leans on each application is a clinical judgement.

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

Three Ways to Find Out What Care Rests On, Weighed

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

Option	When it fits	What it risks
Keep one line for IT failure on the risk register, with one general plan	The hospital’s applications are few, new and well understood	The line says nothing about which application or which part of care. On the day, departments find out by trying to work
Ask each department to list the applications it uses and rank them	The hospital is small, and its applications are separate and well known	Departments list what they see on screen. The overnight feeds and the old programs underneath are missed, and every list says “critical”
Read the hospital’s own applications, map their links and what each stands on, then have its clinicians rank them by how much care depends on each	The hospital runs older applications of its own, linked to one another	It costs money before anything changes, and prevents nothing by itself: a mapped application can still fail. It 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 applications mapped, with their links (overnight feeds included) and an owner	None; one line for “IT failure”	Every application in use	The map and the risk register
Share of care-critical applications ranked by your own clinicians	None; ranked, if at all, by size or cost	Every care-critical application	The ranking, with the names of the clinicians who made it
Share of care-critical applications with a written specification you hold	None, or old notes nobody trusts	Every care-critical application	The specification, and who confirmed each part
Care-critical applications running on software out of support	Not counted	Falling at each review	The map, checked against the makers’ published support dates

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 the applications your care depends on and the ones that worry you most. 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. It produces a map of your applications as they stand, showing the links between them, overnight feeds included, and the software each stands on; a written specification of what each does; a risk register; a cost comparison between keeping and replacing each fragile application; 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. Here, your own experts include your clinicians, who rank the applications by how much care depends on each. 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 replace a system one module at a time while the old one keeps running, starting with the applications your clinicians rank highest and the map shows to be most fragile. We never do a single cutover. Your own team or vendor keeps the old system running throughout, as it does today; we do not. Each module has a traceability matrix. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module. Where a 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: a system can still fail or be attacked, and care can still be interrupted. We do not keep systems running, respond to incidents, restore systems or run backups. We do not write, test or judge the procedures your staff fall back on, and we make no claim about patient safety. We do not work on packaged health record products, medical devices or pharma plant control systems.

What changes for the business:

Role	What they gain
CEO	The board sees where the hospital is most fragile, application by application, before an outage shows it.
CTO or CIO	A map of the applications and what each depends on, with the weakest points ranked.
COO	Each department knows which application it cannot work without, so its own fallback plan is written for the right one.
Medical head	Clinicians have a say, in advance, in which applications matter most to care.
Risk and compliance	The risk of interruption to care can be recorded on the risk register application by application, with who looks after each.

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

The case	What IOanyT does
In 2021 ransomware hit one European national health service, and more than half of its acute hospitals had to cancel services.	Our part is much narrower than this case. We cannot stop an attack, keep systems running or restore them. We map which of an organisation’s own applications care depends on, and which run on software out of support.
An attack left a large public hospital in India without its hospital information system, and its staff went back to paper records.	The record does not say what the system ran on. Our part is narrower: a written map of a hospital’s own applications and a ranked list of risks.
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.	We do not work on a supplier’s systems, and we provide no fallback. For the hospital, our map shows which of its own applications depend on each outside system.
Cyberattacks halted or disrupted production at two large drug makers.	Our part is much narrower. We do not work on plant control systems or secure machines. We map a company’s own business applications.
The UK government’s review reported that around 10% to 50% of NHS trusts’ technology estates are classified as legacy.	We do not work on packaged health record products. For applications an organisation built or had built, we show which run on software out of support.

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 care rests on, because that part is in your hands.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →