A Record System Built to Keep Records, Not to Share Them
A study of old healthcare systems that cannot exchange records, from the public record: a 30-year-old US government record system, what India's digital-health programme and insurers now expect, the options, what we would advise against, and the benchmark we would set.
1. At a Glance
Issue study · From the public record. None 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 very large government health department whose record system does not well support the exchange of records, set beside what India’s digital-health programme and insurers now expect |
| Size band | The department: very large. Our reader: a mid-size hospital group, diagnostic chain or health-tech firm |
| Region | The department: the US. The digital-health direction and incentive: India |
| The decision at stake | How to make records leave an old system and enter another, when the system was built to keep them and the only quote on the table is to replace it |
| The public outcome | The department chose full replacement. It paused the roll-out in April 2023 after five sites, and had committed about 12.71 billion dollars by mid-2024 |
| Why it matters to a mid-size health organisation | Most run older systems that were never built to share. The question is whether the records that must move are dealt with one part at a time, or wait for a replacement of everything |
2. The Business Problem, in the Buyer’s Words
“Our laboratory, wards and billing each have a system, and none of them passes anything to the others. My staff print and re-type all day. Now an insurer wants claims electronically, local doctors want discharge summaries, and the digital-health programme wants connected records. Every proposal I get says replace the record system. I cannot tell whether the real job is that big.”
These words are imagined. They describe the decision as the research shows it, not a real conversation.
The organisation is caught between staff who carry records by hand and a replacement it cannot size. Carrying on by hand looks cheaper each month, and every new partner waits.
3. What We Found
Method. We went through the public record on old healthcare systems and the exchange of records: a US government audit of one very large record system and later reporting on its replacement, an Indian medical journal, UK government figures, one staff survey, India’s digital-health direction and incentive, the insurance regulator’s time limits and one US federal rule, from 2024 to 2026.
A record system that was not built to share. A US Government Accountability Office report of February 2025 records how the US Department of Veterans Affairs set out to replace the record system it relies on.
| What | Public record |
|---|---|
| The old system | ”has been in operation for more than 30 years, is costly to maintain, and does not optimally support VA’s need to electronically exchange health records with other organizations” |
| Progress of the replacement | Paused in April 2023, after deploying to five medical centres |
| Safety review before the pause | ”14 critical patient safety issues requiring development or enhancement work” identified |
| Money committed | About 12.71 billion dollars, fiscal 2018 to mid-2024 |
The wider picture. A 2026 Indian medical journal article lists “heterogeneous hospital information systems” and “limited interoperability between hospital platforms and external digital services” among recurring weaknesses of Indian hospitals. Around 10% to 50% of NHS trusts’ technology is classed as legacy. In one vendor-paid survey of over a thousand frontline healthcare staff in the US, the UK and Ireland, fewer than two in three in the US and only about a third in the UK said they have modern systems. On Windows Server 2008 without its second service pack, today’s standard for encrypted connections is “Not supported”.
What now expects records to move. On 17 July 2026 the National Medical Commission directed medical colleges to “immediately implement the Ayushman Bharat Digital Mission (ABDM)-compliant Health Management Information System (HMIS)”, and listed colleges “still not using ABDM-enabled HMIS software”. A government backgrounder of 6 July 2026 says that under the Digital Health Incentive Scheme, hospitals “earn cash incentives for creating interoperable digital health records”; the scheme had paid hospitals more than 107 crore rupees by 18 June 2026. The insurance regulator’s circular of May 2024 requires insurers to “decide on cashless authorisation requests within one hour”. In the US, a federal rule (CMS fact sheet of 17 January 2024) requires Medicare Advantage, Medicaid and CHIP payers to decide prior authorisation requests within 72 hours for urgent requests and seven calendar days for standard ones from 1 January 2026.
Our reading of why old systems cannot exchange records. These four are our reasoning from the record above. None is an auditor’s or a regulator’s finding.
- The system was built to keep records, not to share them. It has no way in for another system, only its own screens and sometimes a report.
- Nobody has a written record of where each record is kept, so nobody can say what it would take to send one.
- Dates are given to partners before anyone has looked, and the obstacles are found afterwards.
- The only answer offered is to replace everything, so a need to share one record is tied to the largest change the organisation could make.
What this record does not show. The Veterans Affairs case is a very large government programme, not a mid-size hospital, and the record does not say why its costs grew or that exchanging records was the only reason to replace the system. The Commission’s direction is addressed to medical colleges, not to every hospital; the incentive is a reward, not a penalty; the insurers’ time limits are set for insurers, and the US rule names Medicare Advantage, Medicaid and CHIP payers only. No source ties any of them to a named organisation’s old system. The survey was paid for by a vendor and is about technology in general. We found no public case of a mid-size hospital, diagnostic chain or pharma company that cannot exchange records, and no figure for the hours spent re-typing or for charges missed.
4. The Options a Firm in This Position Had
| Option | When it fits | What it risks | Our view |
|---|---|---|---|
| Keep re-typing, with staff as the connection | Hand-offs are few, and no partner or programme is asking | The cost stays invisible and grows with every partner | Acceptable only as a stopgap with an end date |
| Build a connection around the old system | The old system can already produce the record as a file or report, and is sound otherwise | Depends on a system nobody can change; needs looking after; may not be possible where the old server cannot connect securely | Worth checking; fits only where the old system is sound |
| Replace the whole record system | The system is failing in many places and a long programme is affordable | Every department changes; the need to share waits for the whole programme; no record of what the old system does | We would advise against this as the answer to a need to share one or two records |
| Write down the old system, then rebuild first the module that must exchange, while the old one keeps running | The system is old, undocumented and used every day, and particular records must move first | Several stages; two systems side by side for a time | Our recommendation |
What we would have advised against: for an organisation in this position, promising a partner a date before anyone has read the old system, and answering a need to share one kind of record with a replacement of everything.
5. Our Recommendation, and the Decision It Asks of the Board
For the applications a health organisation built or had built for it (registration, laboratory, pharmacy and billing applications, portals and in-house record systems): write down what the old system does and where each record a partner or programme needs is kept, then rebuild first the module that holds those records, onto technology that can pass them on, while the rest keeps running. Further modules follow in an order the organisation agrees, by what each record is needed for, who is waiting and how often it is carried by hand. Where the evidence says the whole system should go, the assessment says so.
The decision it asks of the board: approve a fixed-price assessment now, before the next partner is promised a date. Then approve each stage on its own evidence, with the freedom to pause after any accepted module. The board stops choosing between carrying on by hand and replacing everything, and starts approving the parts that must share, one at a time.
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 |
|---|---|---|---|
| Hand-offs done by people | Not counted | Each listed, with what is carried, from which system to which, by whom and how often | The list, confirmed by the desks that do the work |
| Connections partners have asked for, and their status | ”We will come back to you” | Each with what blocks it, a stage against it and a status | The staged plan, reported at every review |
| Where each requested record is kept | Unknown until work starts | Written down | The specification |
| Records re-keyed between systems | The same details typed at several desks | Fewer after every accepted module | Reported at every review |
| Modules able to exchange their records | None | Each module that must exchange rebuilt and accepted, in order | Signed acceptance and the traceability matrix |
7. How IOanyT Would Work
- We listen: a free Reliability Review. A first conversation about the systems, the hand-offs between them and the partners who are asking. 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, starting with the module whose records must move first. 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 old system does and where each record is kept, in writing 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 rebuilt 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 has no ready-made connection or integration product, and this study does not say it builds connections around an old system.
- IOanyT does not work on packaged health record products, medical devices or their software, and does not change a product that belongs to another supplier.
- IOanyT names no health data exchange standard here. What the other side expects comes from the other side.
- IOanyT gives no legal or regulatory advice on sharing patient records or on consent, and 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.
- IOanyT does not run or maintain the old system while its modules wait to be rebuilt. The client’s own team or vendor does that, and staff go on carrying the records whose modules have not yet moved.
- 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.
- This study does not say IOanyT would have prevented the events 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.
10. Sources
| Source | Used for |
|---|---|
| GAO-25-108091, 24 February 2025 | US Department of Veterans Affairs: the old system, the pause, the safety review, money committed |
| A medical journal article, 2026 | Indian hospital information systems |
| UK State of Digital Government Review, 21 January 2025 | NHS trusts: legacy technology |
| News report of a vendor’s survey, 2025 | Frontline staff survey |
| Microsoft, TLS protocol support | Encrypted connections on Windows Server 2008 |
| 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 |
| CMS fact sheet, 17 January 2024 | The US prior authorisation rule |
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 records that must move, because that is where the old system and the partner meet.
Read the research notes on this issue
Cannot exchange records with other systems
Research note 1
Hospital Systems Rarely Pass Records to Each Other. The Connection Is Usually a Person.
We reviewed the public record on old hospital systems that cannot exchange records: what we found, what waits while staff carry records, and four ways forward.
Research note 2
Digital Health Now Asks for Records That Move. Many Hospital Systems Were Built to Keep Them.
Connected records and faster insurer claims need data to move between systems. What waits on an old hospital system, four ways forward and a benchmark.
Research note 3
Sharing One Record Should Not Mean Replacing Every System. Here Is the Benchmark We Would Set.
Hospitals are told sharing records means replacing the old system. The benchmark we would set first, and the order the parts that must exchange are rebuilt.