How Much of What Care Rests On Have You Mapped? Four Measures, Now and Where They Should Be.

The audit committee has one question for the risk head. Of the applications care depends on, how many run on software that nobody fixes any more?

The risk head turns to the technology head, who gives an estimate. The chair asks which of those the clinicians would say matter most. Nobody knows; the clinicians were never asked. The chair asks whether anyone could rebuild the oldest one from what is written down. There is a pause.

The minutes record: “Management to report back.”

What We Found

We looked at what the public record says about how old the software under health organisations is, and about what is measured.

Before the findings, the limit that runs through this whole issue. Counting what care rests on does not keep anything running. Nothing we do will stop a system failing or being attacked, we do not restore systems, and we do not write the procedures your staff fall back on. A benchmark changes what you know, and what you can choose to do first.

Legacy in health systems is common, and it is 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. The review says the scale of legacy “is not consistently measured”. If a national review finds it hard to count, a hospital that has never tried is unlikely to know its own figure.

The dates are published years ahead. 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. Extended support for SQL Server 2016 ended on 14 July 2026. Windows Server 2016 follows on 12 January 2027. Each of these can be checked against every application a hospital runs, long before the date.

When the systems go, what is written down is what is left. 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. After the 2021 attack on one European national health service, according to a trade journal, it took months to decrypt all of its servers and restore almost all of its applications. Both are older cases. Neither record says that old applications were what took longest, and we do not say so; the national health service’s reporting gives several causes for the attack itself, among them a phishing email, patching that was not effective and machines on an operating system out of support.

What nobody measures. We found no figure, in healthcare or elsewhere, for how many hospitals hold a map of what care rests on, a ranking of their applications by their own clinicians, or a written specification of their oldest applications. In our reading, that is itself the problem: a hospital cannot reduce a fragility it has never counted.

What Counting Opens Up

A hospital that has counted can do three things one that has not cannot.

• Choose where to act first. The applications that are both relied on and fragile can be named, and dealt with before the easy ones.
• Show progress. A count that falls at each review is a report a board can read; a line that says “IT failure: high” is not.
• Plan its own way through a failure. The hospital’s own teams, with the clinicians’ ranking and a written record in hand, can plan what to bring back first. That plan is theirs to write.

This is our reading. It is not a measured market figure.

Three Ways to Count What Care Rests On, Weighed

Option	When it fits	What it risks
A one-off inventory by the technology team, for a report	The estate is small, and the report is needed quickly	It lists what is installed, not what care depends on. Nobody asks the clinicians, and it is out of date by the next review
Ask each department which applications it relies on	The hospital is small, and its applications are separate	Departments list what they see. The links underneath and the overnight feeds are missed, and nothing is written about what each application does
Read the applications themselves, map their links and what each stands on, have the clinicians rank them, write down what each care-critical application does, and refresh the count at each review	The hospital runs older applications of its own that care leans on	It costs money before anything changes. The count may be uncomfortable reading. And it goes stale unless someone on the hospital’s side keeps it

Where You Are Now, and Where You Should Be

This is the benchmark we would set before the assessment starts, and fill in as it goes.

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, and signed acceptance for each replaced module

The starting points above are 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.

A small part of a filled-in benchmark might look like this.

Application	Mapped, with owner	Clinicians’ rank	Specification you hold	Software under it
Medicines and allergies	Yes, owned by the pharmacy head	1	Yes, confirmed by the pharmacy and nursing heads	Out of support; stage 1 of the replacement, accepted
Laboratory orders and results	Yes, owned by the laboratory head	2	Drafted; waiting for review	Supported until a published date next year
Theatre scheduling	Yes, owned by the theatres manager	3	Not yet started	Out of support; in the staged plan

The rows above are an illustration, not taken from a real hospital.

How We Work With You, and What You Are Left With

1. We listen: a free Reliability Review. A first conversation about the applications care depends on, and the questions your board asks that nobody can yet answer. 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.
3. We read the system and propose: the Legacy System Specification Assessment. 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. 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. The specification is yours: a record of what each application does, from which it could be rebuilt by whoever you choose.
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; 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.
5. We review against the benchmark. Before work starts we set the benchmark above. As each module is delivered and accepted 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 has limits, and we state them plainly. A written specification does not restore anything by itself: rebuilding a system is work done by people, and if that day comes they are your own team or the firm you choose, not us. We do not restore systems, respond to incidents, run or test backups, or write, test or judge the procedures your staff fall back on. We make no claim about patient safety or about how long any recovery would take. We do not work on packaged health record products, medical devices or pharma plant control systems.

At the end you hold the map, the clinicians’ ranking, the specification, the risk register, the traceability matrix for any module we replaced, and a benchmark in which every measure shows where it started and where it stands.

What changes for the business:

Role	What they gain
CEO	The hospital’s most relied-on applications are described in writing it holds, not only in the memories of a few people.
CTO or CIO	A written specification of what each care-critical application does, from which it could be rebuilt without its author.
COO	Questions about what an old application does are answered from a document, not by finding the one person who knows.
Medical head	Clinicians can check, in writing, what each application they rely on is meant to do.
Risk and compliance	Evidence in writing of what each care-critical application does, and who confirmed it, to show when asked.

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

The case	What IOanyT does
An attack left a large public hospital in India without its hospital information system, and its staff went back to paper records.	Our part is much narrower than this case. We do not restore systems or respond to incidents, and the record does not say what the system ran on. Beforehand, we write down what a hospital’s own applications do, and the hospital holds that record.
After the 2021 attack on one European national health service, it took months to restore almost all of its applications.	Our part is much narrower. We cannot stop an attack or shorten a recovery. We set and fill in the benchmark of what an organisation has mapped, ranked and written down.
The UK government’s review reported that around 10% to 50% of NHS trusts’ technology estates are classified as legacy, and that the scale of legacy is not consistently measured.	We do not work on packaged health record products. For the applications a health organisation built or had built for it, we count which run on software out of support, and show the count falling as modules are replaced.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We count what your care rests on first, so you can see the fragile part shrink.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →