The Changes Your Hospital Is Asked For Are Queuing Behind One Person.

The advertisement has been live for five months. Software developer, hospital information system. It names the technology the system is written in.

There have been four applications. Two were from people who had never used it. One came for an interview, saw the code, and took a job elsewhere the following week.

Meanwhile the digital team’s list grows: a change for connected health records, a change to the billing screens for faster insurer approvals. Every item on it has the same name beside it.

What We Found

We looked at two things: what the public record says about skills for old technology, and what India’s digital-health programme and insurance regulator now ask of the systems on both sides of a hospital’s records and bills.

The skills are scarce, even where the money is. 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 surveys of large enterprises, about a technology IOanyT does not work on. They are the nearest evidence there is.

The tools have been retired by their makers. The VB6 development tool has been unsupported since 8 April 2008, and its maker “strongly recommends that you replace your applications with modern technology”. Programs built with it still run on current Windows; building and changing them is what lost its support. Colleges stopped teaching such tools long ago, and engineers know a year on one counts for little at their next job.

India’s digital-health programme now asks for connected records. On 17 July 2026 the National Medical Commission directed medical colleges to implement an “Ayushman Bharat Digital Mission (ABDM)-compliant Health Management Information System (HMIS)” in their hospitals “immediately”. It published lists of non-compliant colleges, among them some “still not using ABDM-enabled HMIS software”, and warned that its rating board “may initiate further action as per norms”.

There is a reward for connected records too. Under the Digital Health Incentive Scheme, hospitals “earn cash incentives for creating interoperable digital health records”. By 18 June 2026 the scheme had paid hospitals more than 107 crore rupees.

Insurers now work to the hour. The insurance regulator’s circular of May 2024 requires insurers to “decide on cashless authorisation requests within one hour”, and to give final authorisation on discharge “within three hours of request from the hospital”.

The Changes That Wait on One Person

A vacancy on an old system is usually treated as a recruitment problem. Our reading is that the bigger cost is the work that cannot start while only one person can change the system.

Connected records. A record system that meets the Commission’s direction has to exchange records with the national network. On an in-house system only one person can change, that work joins the queue behind everything else they are doing.

The incentive. A hospital whose system cannot create interoperable records cannot earn the incentive for creating them, however long the queue.

Faster claims. The insurer’s one-hour and three-hour clocks start with the hospital’s request. The billing screens that send it are part of the same old system, and any change to them waits for the same person.

This is our reading of the evidence. It is not a measured market figure, and we do not put a rupee value on it here. That figure has to come from your own organisation.

Four Ways to Answer a Skill Nobody Can Hire, Weighed

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

Option	When it fits	What it risks
Keep the expert, and contract outside help for the old technology	The system is due to be replaced soon, and the date is set	The knowledge stays in one or two heads. Outside help is scarce, and when the contract ends what they learned leaves with them. It buys time only
Hire and train people for the old technology	The technology still has people to hire where you are, and the system has a long life ahead	The pool shrinks every year. A junior who learns it will want out as soon as they can, and every hire made onto it deepens the dependence
Replace the whole system at once	The system is small and well understood, or a ready product fits the hospital’s ways of working	Every department changes on one date. Nobody can say what the old system does without the expert, and the project uses up the expert’s time
Write down what the system does, then move it module by module to technology people can be hired for	The system is old, built in-house, used every day, and its expert is still there	It asks for the expert’s time now. Two systems run side by side for a time. Until the last module moves, you still need the expert

Where You Are Now, and Where You Should Be

Before the next advertisement goes out, we would set a benchmark for the decision itself.

Measure	Typical starting point	Where it should be	How it is checked
Changes waiting on one person	Most of them, including those the regulator, the digital-health programme or insurers ask for	Falling with each accepted module	The change log, reported at every review
The waiting changes, set against the system	A list of requests, not linked to any part of the system	Each request listed against the module it needs	The staged plan
Share of the system written down and confirmed	None	Every part in use, each confirmed by your own experts	The specification
Modules on technology you can hire for	None	Rising with each accepted module	Signed acceptance for each module
The size of one commitment	The whole system at once, or nothing	One stage, with the freedom to pause after any accepted module	The staged plan

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.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the system, the vacancy, and the changes that are waiting on it. 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. 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. 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, onto technology in wide use that your organisation can hire for. We never do a single cutover. 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.

What you need to bring: a start made while the expert is still there; read-only access to the code once the assessment begins; protected time from the expert to confirm what the system does; and, as modules arrive, engineers of your own or newly hired to look after them.

Meeting the Commission’s direction, or any other rule, is your organisation’s own work; we do not offer a compliance service.

What changes for the business:

Role	What they gain
CEO	Plans for new services no longer wait on a skill that cannot be hired.
CTO or CIO	A team that can be grown and replaced from the ordinary job market, moved over one module at a time.
CFO	Less dependence on the few outside people who still sell the old skill, whatever they charge.
COO	Requests for changes are not queued behind the one person able to make them.
CHRO	Vacancies that people apply for, and work that builds a young engineer’s career.

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

The case	What IOanyT does
The National Medical Commission published lists of medical colleges not compliant with its direction on connected records.	Our assessment shows what the in-house system does and which module the change needs, and the staged plan can put that module early. Meeting the direction is the college’s own work.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We do not fill the vacancy; we do the piece of work that makes the next one fillable.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →