When Only One Person Can Read the System
A study of scarce skills for old health systems from the public record: a national record system in service for more than 30 years, cross-sector skills surveys, a retired development tool, what India's digital-health programme now asks, the options, what we would advise against, and the benchmark we would set.
1. At a Glance
Issue study · From the public record. Neither of the organisations named here was an IOanyT client, and IOanyT had no part in the events described. Everything about them comes from the public record.
| Organisation type | A national health department whose record system has been in service for more than 30 years, set beside cross-sector skills surveys, a development tool its maker retired, and India’s digital-health requirements |
| Size band | The department: very large. Our reader: a mid-size hospital group, laboratory chain or pharma company with a system it built or had built for it |
| Region | The department: United States. The digital-health requirements: India |
| The decision at stake | What to do when a system the organisation depends on can be read and changed by very few people, and those people cannot be hired |
| The public outcome | In February 2025 the US government’s auditor described the department’s record system as one that “has been in operation for more than 30 years, is costly to maintain”. The department is replacing it |
| Why it matters to a mid-size health organisation | Many run a system of their own, written years ago in tools few people now learn, that one or two people understand. The question is whether that knowledge is written down and the system moved on a plan, or whether a retirement forces the issue |
2. The Business Problem, in the Buyer’s Words
“Our hospital system was written in-house nearly twenty years ago, and one developer has made every change since. We have advertised for a second for months and nobody suitable applies. Now the digital team needs changes for connected records and faster insurer claims, and they all wait in that one developer’s queue. And last month that developer mentioned retiring. I do not know what we would do.”
These words are imagined. They describe the decision as the research shows it, not a real conversation.
The organisation is caught between a system only one person can read and a skill it cannot hire. Advertising again looks like the answer each time, and the changes wait.
3. What We Found
Method. We went through the public record on scarce skills for old systems: two industry surveys of large enterprises that run mainframes, the maker’s support statement for one of the most common development tools of its day, a US government audit of a health record system, a vendor’s description of an unnamed health organisation’s old system, India’s digital-health direction and incentive, and the insurance regulator’s time limits, most of it from 2024 to 2026.
A record system in service for more than 30 years.
| What | Public record |
|---|---|
| Age | The system “has been in operation for more than 30 years” |
| Cost | It “is costly to maintain” |
| What it cannot do well | It “does not optimally support VA’s need to electronically exchange health records with other organizations” |
| What the department decided | To replace it with a commercial record system |
Skills for old technology are scarce, even for large enterprises. 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, and both are about mainframes, a technology IOanyT does not work on.
The tools were retired long ago. 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.
Old health systems hold a great deal. One US healthcare organisation’s administration system, described in a vendor’s case study, was built on thousands of old terminal screens, many unchanged for decades.
What waits on the system in India. 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)” “immediately”, and published lists of colleges that had not complied. Under the Digital Health Incentive Scheme, hospitals “earn cash incentives for creating interoperable digital health records”, and the scheme had paid hospitals more than 107 crore rupees by 18 June 2026. The insurance regulator requires insurers to “decide on cashless authorisation requests within one hour”.
Our reading of why organisations come to depend on one person. These four are our reasoning from the record above. None is an auditor’s or a regulator’s finding.
- Nothing was written down, because the person who built the system was always there to ask.
- The scarce skill is reading the old code, not changing it, and only the author can read it fluently.
- The organisation tries to hire for the old technology, and competes for a pool that shrinks every year.
- The handover is left to the notice period, which is far too short to pass on years.
What this record does not show. The research found no healthcare evidence on scarce skills. The skills surveys are cross-sector, about large enterprises that run mainframes, and paid for by vendors; one gives no sample size. The auditor’s report does not say the department’s system rests on a few people; that link is our reasoning. The department is a national body, not a mid-size one. The Commission’s direction binds medical colleges; the incentive is a reward, not a penalty; the insurers’ time limits bind insurers. No source ties any of them to an organisation’s old in-house system. We found no figure for pay, contractor rates, time to fill a vacancy or onboarding time, and no named hospital or pharma company with this problem. Which technologies in-house hospital systems in India are written in was not researched.
4. The Options a Firm in This Position Had
| Option | When it fits | What it risks | Our view |
|---|---|---|---|
| Keep the expert, and contract outside help for the old technology | The system is due to be replaced soon, on a set date | The knowledge stays in one or two heads; outside help is scarce and leaves with what it learned | Right only as a bridge with an end date |
| Hire and train people for the old technology | People can still be hired for it, and the system has a long life ahead | A shrinking pool; juniors who learn it leave; each hire deepens the dependence | Rarely the answer for a technology people have stopped learning |
| Replace the whole system at once | The system is small and well understood, or a ready product fits | Every department changes on one date; nobody can say what the old system does without the expert | We would advise against this for an old, undocumented system used every day |
| Write the knowledge down, then move 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; several stages; two systems side by side for a time | Our recommendation |
What we would have advised against: for an organisation in this position, leaving the handover to the notice period, advertising again and again for a skill people no longer learn, and answering the problem with a single cutover of the whole system.
5. Our Recommendation, and the Decision It Asks of the Board
For the systems a health organisation built or had built for it (billing, registration, laboratory and pharmacy applications, portals and reporting, or a whole in-house hospital system): have the system read by others and written down, with the organisation’s own experts, including the one person who knows it best, confirming each part. Then move it module by module onto technology in wide use that the organisation can hire for, starting with the parts only one person can explain and the parts the waiting digital-health changes need. The old system keeps running, looked after by the organisation’s own expert and team, until each module is accepted.
The decision it asks of the board: approve a fixed-price assessment now, while the expert is still there, rather than another round of advertising. Then approve each stage on its own evidence, with the freedom to pause after any accepted module. The board stops asking who will take over and starts tracking how many people can explain each part of the system.
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 |
|---|---|---|---|
| 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 the organisation’s 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, including those the regulator, the digital-health programme or insurers ask for | Falling with each accepted module, towards none | The change log, reported at every review |
| Time left with the expert when the record is finished | None planned; the notice period | Months, not weeks | The staged plan beside the expert’s own plans |
7. How IOanyT Would Work
- We listen: a free Reliability Review. A first conversation about the system, the people who understand it, and the changes waiting on 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.
- 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 produces a map of the system as it stands, a written specification of what it 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.
- 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.
- 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 and the specification: what the system does, in writing, confirmed by the organisation’s own experts and portable to any supplier.
- The risk register: what the assessment found, listed before any price is set.
- The traceability matrix: every old function linked to its replacement, with how it was checked.
- The code: the new modules are the client’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 is not a staffing firm. It does not supply developers for the old technology, find or recruit staff, or take over the running and upkeep of the old system. The organisation’s own expert and team keep it running until each module has moved.
- IOanyT does not offer training as a service. Hiring and teaching new joiners stay with the organisation.
- Until the last module has moved, the organisation still depends on its present expert for the parts that have not.
- IOanyT does not claim COBOL, RPG, MUMPS or mainframe skills, and does not work on packaged health record products, medical devices or their software, or pharma plant control systems.
- IOanyT does not offer a compliance, audit or legal service. Meeting the National Medical Commission’s direction, or any other rule, is the organisation’s own work.
- Nothing here says IOanyT’s work protects patients or keeps care running. Clinical acceptance of any module is the organisation’s own decision, made by its clinicians.
- This study does not say IOanyT would have changed anything for the organisation named, 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.
10. Sources
| Source | Used for |
|---|---|
| GAO-25-108091, 24 February 2025 | US Department of Veterans Affairs: age, cost and replacement of its record system |
| News report of a vendor’s survey, 2025 | The difficulty of finding the right skills (cross-sector) |
| A vendor’s survey article, 2025 | Skills lacking in older programming languages (cross-sector) |
| Microsoft, VB6 support statement | The VB6 support date and recommendation |
| A vendor’s case study | The size of one unnamed organisation’s old system |
| Medical Dialogues, 18 July 2026 | The National Medical Commission’s direction |
| PIB backgrounder, 6 July 2026 | The Digital Health Incentive Scheme |
| The Tribune, 31 May 2024 | Insurers’ time limits for cashless claims |
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 by writing down what one person knows, while that person is still there to confirm it.
Read the research notes on this issue
Scarce skills for old in house systems
Research note 1
The Scarce Skill in an Old Hospital System Is Reading It. That Can Be Done Once.
Many in-house hospital systems rest on the one person who built them. What the public record shows, three ways to keep what they know, and our benchmark.
Research note 2
The Changes Your Hospital Is Asked For Are Queuing Behind One Person.
Connected records and faster insurer decisions need changes to old hospital systems, and each waits on one person. Four ways out, weighed, and our advice.
Research note 3
How Many People Can Explain Your Hospital's System? Four Measures, Now and Where They Should Be.
When only one person can explain an old hospital system, every question waits. Four measures, where they start and where they should be, and the path.