When the Systems Care Depends On Stop
A study, from the public record, of what happens to care when health organisations' systems stop: what is and is not in a hospital's hands, the options, what we would advise against, and the benchmark we would set.
1. At a Glance
Issue study · From the public record.
| Organisation type | Health organisations whose systems stopped after attacks: a national health service, a large public hospital, the hospitals served by a pathology supplier, and two drug makers |
| Size band | All large. Our reader: a mid-size hospital group, laboratory chain or pharma company running older applications of its own |
| Region | The national health service and the pathology supplier: Europe. The hospital: India. The drug makers: not stated here. No mid-size case anywhere |
| The decision at stake | What a health organisation can do beforehand, on its own applications, about the systems care depends on |
| The public outcome | Services cancelled at more than half of a national health service’s acute hospitals; a hospital information system out of reach and staff back on paper records; surgery and clinic appointments cancelled on a large scale at hospitals that were not themselves attacked; production halted or disrupted at two drug makers |
| Why it matters to a mid-size health organisation | No organisation can be promised that its systems will not stop, and nothing in this study changes that. What it can hold is a map of which applications care rests on, a ranking of them by its own clinicians, a staged plan that replaces the most fragile first, and a written record of what each does |
2. The Business Problem, in the Buyer’s Words
“Every year we run the exercise, and every year we discover a system we did not know the wards depended on. The application the pharmacy uses is the oldest thing we run, and nobody dares touch it. Our risk register says ‘IT failure: high impact’ and nothing else. If the board asked me tomorrow which application care rests on most, I could not answer, and I could not say what it would take to rebuild it.”
These words are imagined. They describe the decision as the research shows it, not a real conversation.
The organisation knows that care depends on its systems and that some of them are old. It does not know which applications hold up which part of care, how fragile each is, or what is written down about them. It cannot stop a system failing. It can decide what it knows, what it replaces first, and what it holds in writing.
3. What We Found
Method. 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, trade-press accounts of attacks on two drug makers, a UK government review and the makers’ published support dates, from 2018 to 2026.
A national health service’s systems stopped, and its hospitals cancelled services.
| What | Public record |
|---|---|
| What happened | Ransomware, in 2021. An older case |
| The effect on care | More than half of its acute hospitals had to cancel services |
| Recovery | According to a trade journal, months to decrypt all of its servers and restore almost all of its applications |
| Causes given in the reporting | 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; tens of thousands of machines on an operating system that was out of support |
A hospital lost its information system. 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 notes 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.
Hospitals were stopped by a supplier. 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. According to a trade journal’s report, they had to cancel surgery and clinic appointments on a large scale. The report says it was not possible to determine how the attackers got in, and does not tie the attack to old technology.
Drug makers’ production stopped. 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.
Legacy is common, and not consistently measured. 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, and that the scale of legacy “is not consistently measured”. Support for Windows Server 2012 and 2012 R2 ended on 10 October 2023, with paid security updates running to 13 October 2026; extended support for SQL Server 2016 ended on 14 July 2026; Windows Server 2016 follows on 12 January 2027.
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 it is attacked, or a machine fails on a given day | Knowing which of its own applications each part of care rests on |
| How bad a given incident is | Knowing which of those are oldest, least understood and on software out of support |
| How long a recovery takes once a failure has happened | Replacing the most relied-on, most fragile applications first, in stages |
| Holding a written record of what each care-critical application does | |
| Agreeing with its clinicians, beforehand, which applications matter most to care |
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.
- Nobody has a map of what care rests on. Applications were added one at a time, all are called critical, and the links between them are found when they break.
- The application care leans on most is often the oldest. The easy systems are renewed first, and the one nobody dares touch is left on software nobody fixes.
- Nothing is written down about the old applications. What they do lives in a few people’s memories, so replacing or explaining them waits on those people.
What this record does not show. Every case is an attack, and all are large; most are older. Only the national health service’s case puts old technology on the page, beside several other causes, and we do not say old technology caused it. The Indian hospital’s record does not say what its servers ran; the pathology supplier’s report does not tie its attack to old technology; one drug maker’s record names no technology. No record we read gives an account of harm to any individual patient, and this study gives none. We found no figure for failures other than attacks, none comparing how long old and newer systems take to come back, and no case of a mid-size hospital, diagnostic chain or pharma company. The UK figures are from survey responses about NHS trusts, not about India.
4. The Options a Firm in This Position Had
| Option | When it fits | What it risks | Our view |
|---|---|---|---|
| Keep one line for IT failure on the risk register, and patch and extend support in place, done by its own team or the application’s vendor | The applications are sound, and their software can still be upgraded or paid support bought | Paid support ends on the maker’s date; the applications stay as hard to understand; nobody knows which matters most | Right for applications that must wait their turn, while their software can still be patched or paid support bought, run by the organisation’s own team or vendor alongside the staged work |
| Replace the whole system in one switch-over | The system is small and separate, and the organisation’s clinicians have judged that care can manage without it for a day | Everything care depends on in that system changes on one day; anything missed is met by every department at once | Not advised for an application care leans on |
| Write the systems down only: a map and a specification, no replacement | The organisation wants to know what it has before deciding | The applications stay on the same software, and as fragile | A sound first step, and part of our recommendation; not the whole of it |
| Map the applications, have its clinicians rank them by how much care depends on each, then replace the most relied-on, most fragile first, one module at a time while the old one keeps running | Older applications of its own that care leans on, and nobody has drawn the picture | Starts with the hardest system, so the first stage is slow and careful; until a part has moved it is as fragile as before; needs clinicians’ time | Our recommendation |
What we would have advised against: treating “our systems” as one risk on one line; renewing the easy systems first while the application care leans on most waits; and replacing an application care depends on in one switch-over.
5. Our Recommendation, and the Decision It Asks of the Board
For a health organisation running older applications of its own that care depends on: start with an assessment of those applications. Map what each part of care rests on, including the links between applications and the overnight feeds, and the software each stands on. Put the map in front of its clinicians to rank the applications by how much care depends on each. Get a written specification of what each care-critical application does, which the organisation holds. Then replace the most relied-on, most fragile applications first, one module at a time while the old ones keep running, with the organisation’s own team or vendor keeping the old ones running and supported meanwhile.
The decision it asks of the board: approve a fixed-price assessment of the organisation’s own applications now, rather than waiting for the next failure to draw the map. Then decide, application by application, which to replace first, with the freedom to pause after any accepted module. What its staff fall back on when systems stop, and the order in which it brings systems back, stay with the organisation and its clinicians. IOanyT does not keep systems running, respond to incidents, restore systems or write fallback procedures.
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 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 the organisation’s 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 the organisation holds | 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, and signed acceptance for each replaced module |
7. How IOanyT Would Work
- We listen: a free Reliability Review. A first conversation about the applications care depends on, what is known of the links between them, 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.
- 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.
- We read the system and propose: the Legacy System Specification Assessment. It reads your own applications. It produces a map of your applications as they stand, with their links, 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. For each application on software that gets no more fixes, it sets out what an upgrade, paid support or a rebuild would involve, and gives our recommendation; you decide. 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.
- 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; we do not. A traceability matrix links each old function 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 a module touches clinical work, accepting it is your clinicians’ decision.
- 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 each part of care rests on, the links between them, and the software each stands on.
- The clinicians’ ranking: each care-critical application ranked by its own clinicians by how much care depends on it.
- The specification: what each application does, in writing, confirmed by its own experts, from which it could be rebuilt by whoever the organisation chooses.
- The risk register: each fragile application, ranked, ready for the board’s decision.
- The cost comparison and the staged plan: keeping set beside replacing each fragile application, and each stage with a fixed quote.
- The traceability matrix: for every module IOanyT replaces, each old function linked to its replacement, with how it was checked.
- The code: the replaced 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 system failing or being attacked, and does not promise that any system will stay up.
- IOanyT does not keep the old systems running, patch, upgrade or protect them, or sell paid support. The organisation’s own team or vendor does that throughout.
- IOanyT does not respond to incidents, restore systems, or run or test backups, and makes no claim about how long any recovery would take.
- IOanyT does not write, test or judge the procedures staff fall back on when systems stop, and does not set the order in which the organisation brings systems back. Those belong to the organisation and its clinicians.
- IOanyT makes no claim about patient safety and is not a clinical safety assessor. 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.
- IOanyT does not work on packaged health record products, medical devices or their software, or pharma plant control systems.
- 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 |
|---|---|
| News report of the post-incident review, 7 February 2022 (cited without link) | The national health service: services cancelled at its acute hospitals, and the causes |
| HIPAA Journal, 13 December 2021 | The national health service: the recovery, and the phishing email |
| Indian Journal of Critical Care Medicine, 25 May 2026, doi:10.5005/jp-journals-10071-25203 | The hospital in India |
| HIPAA Journal, 12 November 2025 (cited without link) | The pathology supplier and the hospitals it served |
| Pharma Technology Focus, September 2021 | The two drug makers |
| Pharmaceutical Executive, 15 November 2018 (cited without link) | The outside security engineer’s remark on the first drug maker |
| UK State of Digital Government Review, 21 January 2025 | Legacy in NHS trusts, and that it is not consistently measured |
| endoflife.date/windows-server, Microsoft, SQL Server 2016 | Support dates |
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.
Read the research notes on this issue
Harm to patients when systems go down
Research note 1
When Hospital Systems Stop, Care Stops. Which Ones It Rests On Can Be Known Beforehand.
No one can promise a hospital its systems will stay up. It can know which applications care rests on. What the record shows, three options, our benchmark.
Research note 2
The Application Your Wards Rely On Most Is Often the Oldest. Four Ways to Answer That, Weighed.
The application a hospital's wards rely on most is often its oldest. Four ways to answer it, from patching in place to staged replacement, and our advice.
Research note 3
How Much of What Care Rests On Have You Mapped? Four Measures, Now and Where They Should Be.
How many of the applications your care rests on are mapped, ranked by clinicians, written down or out of support? Four measures, where they start, the path.