Digital Health Now Asks for Records That Move. Many Hospital Systems Were Built to Keep Them.
Connected records, incentives for them and insurers working to the hour all need records that leave one system and enter another. Here is what waits on an old system that cannot share, the four ways to answer a partner, and the benchmark for the decision.
The insurer’s proposal is a good one. It will send its members to your hospital, on one condition. Claims and discharge summaries must reach it electronically, in its format, from the first day.
The chief executive asks the technology head how long that would take. The technology head says it depends on the old record system. Asked for a rough figure, the answer is perhaps six months, perhaps eighteen.
The insurer wants a date within a fortnight. The meeting ends with a promise to come back to them.
The paradox: The hospital holds every record the partner wants, and cannot say when it could hand over a single one.
What We Found
We looked at two things: what the public record says about old record systems and the exchange of records, and what India’s digital-health programme, its insurance regulator and one US rule now expect records to do.
India’s medical colleges have been told to run connected record systems. On 17 July 2026 the National Medical Commission directed medical colleges and institutions to “immediately implement the Ayushman Bharat Digital Mission (ABDM)-compliant Health Management Information System (HMIS)” in their hospitals. It published lists of colleges in three groups, one of them colleges “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 records that can move. 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”. By 18 June 2026 the scheme had paid hospitals more than 107 crore rupees.
Insurers 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 from hospital within three hours of request from the hospital”.
In the US, some payers face the same pressure. A federal rule, CMS-0057-F (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. Most of its requirements for data-exchange interfaces apply from 1 January 2027.
Old record systems were not built for this. In a report of February 2025, the US Department of Veterans Affairs’ auditor describes the record system VA relies on as one that “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”. In India, a 2026 medical journal article describes hospitals as having “heterogeneous hospital information systems”. And on Windows Server 2008 without its second service pack, today’s standard for encrypted connections, TLS 1.2, is listed as “Not supported”.
What our review does not show: 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, not hospitals, 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. We found no named hospital that lost or delayed a partnership because its system could not share records, and we do not claim one.
What Waits on Records That Cannot Move
The partner’s request is usually treated as a technology question with a date attached. Our reading is that it is a business question: what can the hospital not do while its records cannot leave the old system?
Connected records. A record system that must exchange records with the national network, or with a partner, has to give records up in a form the other side can take. A system built only to keep records is a hard place to start.
The incentive. A hospital whose system cannot create interoperable records cannot earn the incentive for creating them. That is our reading of the scheme’s own wording.
Faster claims. The insurer’s one-hour and three-hour clocks start with the hospital’s request. The billing and discharge records behind every request sit in the hospital’s own systems. Where they are carried by hand, part of each clock is spent on the hospital’s side.
The partner itself. A date given before anyone has read the old system is a guess. When it slips, the partner is sent spreadsheets by email “for now”, and the next partner starts the same cycle.
The gap we see: judged as an integration project, the request looks large and uncertain, so it waits. Set beside the work, the incentive and the partners waiting on the same records, it is a different decision. The opportunity is to find out once what blocks a record from leaving, and to rebuild that part first, so each later request has an answer.
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 Partner, Weighed
| Option | When it fits | What it risks |
|---|---|---|
| Keep re-typing and send records by hand or by email | The partner accepts it, volumes are low, and no rule or incentive is in play | The partner agreed to electronic exchange and receives spreadsheets. Staff time grows with every partner |
| Build a connection around the old system | The old system can already produce the record as a file or a report, and is sound otherwise | The connection depends on a system nobody can change, and needs looking after. It may not work at all where the old server cannot make a secure connection |
| Replace the whole hospital information system | The old system is failing in many places, and the organisation is ready for a long programme | Every department changes on one date. The partner waits for the whole programme, and the record of what the old system does is still missing |
| Write down what the old system does, then rebuild first the module that must exchange, while the old one keeps running | The system is old, undocumented and used every day, and a partner or a programme needs particular records first | Several stages. For a time two systems run side by side and you pay for both. The first reading may find the record scattered across the system |
Our recommendation: read the old system before you give a partner a date. Write down where each record the partner wants is kept and what blocks it from leaving, then rebuild first the module that holds it, while everything else keeps running. Give the partner the stages, not a guess. We do not sell a connection product, we do not change a product that belongs to another supplier, and we name no exchange format here: what the other side expects comes from the other side.
Where You Are Now, and Where You Should Be
Before a date is promised to the next partner, we would set a benchmark for the decision itself.
| Measure | Typical starting point | Where it should be | How it is checked |
|---|---|---|---|
| Connections partners have asked for | Answered with “we will come back to you” | Each request listed, with what blocks it and the stage that answers it | The staged plan |
| Where each requested record is kept | Unknown until work starts | Written down, table by table and note by note | The specification |
| What blocks each record from leaving | Found after the date is promised | Listed before any date is given | The risk register |
| The cost of a connection | A range where the top is several times the bottom | A price for each stage, set after the system is read | The staged plan and quote |
| The cost of staying as you are | Never counted: staff time, re-keyed records, partners waiting | Set beside the cost of each stage | The cost comparison |
| The size of one commitment | Everything 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
- We listen: a free Reliability Review. A first conversation about the old system, the partner’s request and what is waiting on the answer. You leave with a short written note of what we found.
- 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.
- 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. You get the options and our recommendation.
- 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. 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.
What you need to bring: the partner’s written description of what it wants to receive, and in what form; read-only access to the code once the assessment begins; a few hours from the people who carry the records today; and your own team or vendor keeping the old system running throughout.
What may be shared, with whom and with whose consent is for your legal advisers; we give no advice on it. Meeting the Commission’s direction, or any other rule that applies to your organisation, is your organisation’s own work; we do not offer a compliance service.
What changes for the business:
| Role | What they gain |
|---|---|
| CEO | A partner’s request gets a date with a basis behind it, not “next year”. |
| CTO or CIO | The team knows what stands between the old system and a new connection before anyone commits. |
| CFO | The cost of a connection is priced after the system is read, stage by stage. |
| COO | Operations knows what will change at each desk when a partner is connected, and when. |
| Medical head | Referring doctors and partner hospitals can be told plainly what can be shared, and from when. |
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 runs a record system, more than 30 years old, that does not optimally support the electronic exchange of health records. | Our part is far smaller than this case, and we do not work on record systems of that kind. For an organisation’s own applications, our assessment shows where a record is kept and what blocks it from leaving, before any date is promised. |
| On 17 July 2026 the National Medical Commission published lists that include medical colleges “still not using ABDM-enabled HMIS software”. | Our assessment shows which part of a college’s own application stands in the way and what rebuilding it would take. Meeting the direction is the college’s own work, and we do not change another supplier’s product. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. The partner sets what it wants to receive; when you can send it should rest on a reading of your own system.
Sources
In 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 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.
Issue study
A Record System Built to Keep Records, Not to Share Them
Why old healthcare systems cannot exchange records, what digital-health programmes and insurers now expect, the options, and the benchmark we would set.
More from Healthcare
Harm to patients when systems go down
How Much of What Care Rests On Have You Mapped? Four Measures, Now and Where They Should Be.
Dependence on an outside suppliers systems
How Much of Your Own System Do You Hold? Four Measures, Now and Where They Should Be.
Replacement is costly and risky