How Many People Can Explain Your Hospital's System? Four Measures, Now and Where They Should Be.

On Monday the billing supervisor wants to know why the system added a charge to one patient’s bill and not another’s.

On Tuesday the stores manager asks how the reorder level for a medicine is worked out. On Wednesday a new engineer, three months in, asks which program prints the discharge summary. On Thursday an auditor asks how a discount is approved.

All four questions go to the same desk. The person at it answers each one, from memory and from the code, between the changes they are meant to be making.

What We Found

We looked at what the public record says about how much an old health system holds, how long such systems last, and how scarce the people who can read them are.

Old health systems hold more than one person can explain. One US healthcare organisation, described in a vendor’s case study, had an administration system built in COBOL on thousands of old terminal screens, many unchanged for decades. Using what the case study calls a traditional modernisation process, only a small share of its applications had been converted. IOanyT does not work in COBOL. We cite it to show how much an old health system can contain, and how slowly it is worked through.

They stay, and they cost. In a February 2025 report, the US government’s auditor describes the record system the US Department of Veterans Affairs relies on as one that “has been in operation for more than 30 years, is costly to maintain”. This is a national system, far larger than anything our readers run, but the pattern is familiar: the longer a system stays, the more of it only a few people understand.

The people who can read them are scarce. In a survey of several hundred senior leaders at enterprises that run mainframes, more than two in three said they had had difficulties finding the right skills. In another, about a third reported gaps in skills for older programming languages such as COBOL, RPG and CICS. Both are cross-sector, about a technology IOanyT does not work on.

What nobody measures. We found no figure, in healthcare or elsewhere, for how many people in an organisation can explain each part of an old system, how much of an expert’s week goes on questions, or how long a new engineer takes to become useful. In our reading, that is the heart of the problem: an organisation cannot reduce a dependence it has never counted.

What Counting Opens Up

A dependence on one person is usually felt and never counted. Our reading is that counting it changes what the organisation can do.

• The board can see progress. “We depend on one person” reports a position. “Two people can now explain every part of billing” reports a direction.
• The expert’s time is spent where it counts. Once the record answers the everyday questions, the expert’s time goes to the parts only they can explain, and to the changes only they can make, until those move too.
• New work stops joining the queue. Each module that moves to technology people can be hired for is one fewer place where a change waits for one person.

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

Three Ways to Choose What Moves First, Weighed

Once the system is written down, the order of work decides how quickly the dependence falls.

Option	When it fits	What it risks
Oldest parts first	The oldest parts are also the ones used most	Age is not risk. The oldest part may be stable and rarely changed, while the queue builds elsewhere
Whatever the next change request needs	One urgent change dominates everything else	The order follows whoever asks loudest. The parts that rest on one person may never be reached
The parts that rest on one person and that the waiting changes need, first	The system is used every day and its expert is still there	It needs agreement across departments, and the expert’s time early. Some parts cannot move first, because too much depends on them

Where You Are Now, and Where You Should Be

This is the benchmark we would set before the first module moves, and fill in as each module is accepted.

Measure	Typical starting point	Where it should be	How it is checked
People who can explain each part of the system	One, for most of it	More than one for every part in use, working from the written record	Who confirmed each part of the specification
Share of the system written down and confirmed	None, or old notes nobody trusts	Every part in use, each confirmed by your own experts	The specification
Modules on technology the organisation can hire for	None	Rising with each accepted module, until the old system has nothing left to do	Signed acceptance for each module
Changes waiting on one person	Most of them	Falling with each accepted module, towards none	The change log, reported at every review
What moved and how it was checked	Not recorded	Each old function linked to its replacement, with how it was checked	The traceability matrix

The starting points above are what we expect to find. In an engagement they are replaced by your own position, 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.

Part of the system	People who can explain it	Written down and confirmed	On technology you can hire for
Billing and discounts	Was one; now three	Yes, confirmed by the expert and the billing head	Yes: stage 1, accepted
Pharmacy stock	Was one; now two	Yes, confirmed by the expert and the pharmacy head	Stage 2, in progress
Discharge summaries	One	Drafted; waiting for the expert’s review	Stage 3

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

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

1. We listen: a free Reliability Review. A first conversation about the system, the questions that queue at one desk, and who answers them. 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 written specification of what the system does, a risk register, a cost comparison between keeping and replacing the system, 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 replace a system one module at a time while the old one keeps running, onto technology in wide use that your organisation can hire for. We never do a single cutover. A traceability matrix links every 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 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 a price. It asks for the expert’s time early, when they have least to spare. Until the last module has moved, you still depend on them for the parts that have not. The record has to be kept up to date by your own team, or it becomes one more old document. And it does not give you people: hiring, and teaching new joiners, stay with you. We do not offer training as a service.

At the end you hold the specification, the matrix, 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 experts’ time goes to decisions, not to answering the same question again.
CTO or CIO	New engineers start from a document, and those who never learned the old technology can work from it.
CFO	One piece of work replaces a cost that returned with every new hire and every question.
COO	Department heads and support staff can look up how the system decides something, without waiting.
CHRO	New joiners become useful sooner, and learning no longer depends on shadowing one person.

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

The case	What IOanyT does
The US Department of Veterans Affairs relies on a record system in operation for more than 30 years that its auditor called costly to maintain in February 2025.	Our part is far smaller than this case, and we do not work on health record systems of that kind. For the applications a health organisation built or had built for it, we write down what the system does, set the benchmark, and move it module by module.

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 the dependence first, so you can see it fall.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →