Every healthcare AI pitch you have sat through this year opened with the model. Accuracy on a benchmark, a demo on clean sample data, a roadmap slide. Almost none of them opened with the question that decides whether any of it runs inside your hospital: how does this thing read your data, and how does it write back?
That is the question your project will die on. The model is the part that already works. The layer between the model and your HMIS, your LIS, your PACS, your ADT feed, your billing system, that is where the timeline slips, the budget doubles, and the pilot that looked finished in March is still not live in October.
The number nobody puts on the first slide
MuleSoft's 2025 Connectivity Benchmark Report found that 95 percent of IT leaders name integration as a primary barrier to deploying AI, and that 71 percent of the applications inside the average enterprise remain unintegrated (MuleSoft, 2025). Read that second number again. Seven in ten systems your organisation already paid for do not talk to each other. Now add an AI layer that needs to read from most of them and write to several. You have not added a feature. You have added a dependency on every integration you never finished.
This is why healthcare AI projects stall at integration and not at the model. The intelligence is commodity. The plumbing is bespoke, and it is bespoke to your building.
What the demo shows, and what your hospital actually runs
The demo shows a clean FHIR API returning a patient record as tidy JSON. Your hospital does not run that.
Walk the actual estate of a large Indian hospital group and here is what the AI has to read from. A HMIS that is ten or fifteen years old and speaks HL7 v2, pipe-delimited text segments, if it speaks any standard at all. A laboratory system that exports a flat file on a schedule. A PACS that only understands DICOM. A billing module with no external API, where the only way in is a read replica of the database and a nervous DBA. Radiology reports and discharge summaries sitting as free text or scanned PDFs. Four sites in the group running three different HMIS builds because two of them were acquisitions.
HL7 v2 is the installed reality of Indian hospital IT. It was designed in the era of the point-to-point interface, before the web, and it moves messages between systems as delimited strings that each vendor has extended in its own quietly incompatible way. It works. It has moved admissions and lab orders reliably for decades. What it does not do is hand an AI system a clean, semantically consistent record on request.
FHIR is the aspiration. It is REST, it is JSON, it is queryable, and it is the correct target to build toward. It is also, in most Indian hospitals in 2026, a layer that exists at the edge for external exchange and almost nowhere on the inside where your clinical data actually lives.
FHIR is the mandate. Your building is still HL7 v2.
Here is the trap that catches CIOs who have done their homework. The Ayushman Bharat Digital Mission mandates HL7 FHIR R4, with India-specific profiles defined in the NRCES FHIR Implementation Guide for ABDM (National Resource Centre for EHR Standards, 2026). The National Health Authority has required ABDM integration across government-empanelled providers, and more than 45 crore ABHA identities have been issued. So the reasonable conclusion is this: we are becoming FHIR-compliant for ABDM, therefore our AI project will find FHIR waiting for it.
It will not. ABDM is an external exchange standard. It governs how your hospital shares a linked record with the national health stack and with other providers. It says nothing about how your OPD module talks to your lab system inside your own four walls. A hospital can be fully ABDM-compliant at its exchange boundary and still have an internal estate where the AI cannot read a consultation note without a bespoke connector to a HMIS that has never exposed one.
Becoming FHIR-compliant for the government is an external-facing project. Making your data legible to an AI system is an internal-facing project. They meet at almost no point, and confusing the two is how six months disappear.
Where integration actually breaks
Four failure modes, roughly in the order they will hit you.
Identity. There is no single patient identifier that is consistent across the HMIS, the LIS, the PACS, and the billing system. The same patient is three different IDs. Before your AI can reason about a patient it has to resolve who the patient is, and identity resolution across mismatched systems is unglamorous, error-prone, and almost never scoped in the original plan.
State and timing. HL7 v2 ADT feeds are event streams that lag, drop, and arrive out of order. If your AI acts on a bed status or an order that the feed has not caught up to, it acts on a fiction. Handling stale and out-of-sequence data is not an edge case in a hospital. It is Tuesday.
Semantics. A lab result that arrives as free text, a diagnosis written as an abbreviation one consultant uses and another avoids, a discharge summary as a scanned image. The data is present and unreadable to a machine without a normalisation layer. Structured, coded data is the exception in the Indian record. Free text and scanned paper are the norm.
Access. The DBA does not want you reading the production database. The security team has questions about PHI leaving the box. Under DPDP 2023 those questions carry legal weight, and the answers change your architecture. Every read path is also a compliance decision about who touched what and whether you can prove it later.
The interface engine is the real project
Here is what the winning vendor actually spends its time on, and what the losing vendor never budgeted for. An interface engine, Mirth or Rhapsody or an equivalent, sitting between the AI and your estate. HL7 v2 to FHIR mapping written by hand, segment by segment, per source system, because no two v2 implementations agree. A normalisation layer for the free text. An identity-resolution service. Monitoring for when the ADT feed goes quiet at 2am and someone has to know before the ward does.
On a real hospital deployment this integration work is the majority of the timeline and the cost, commonly well over half, before a single model-specific line is written. It is the part no demo shows, because it is specific to your building and cannot be pre-built. It is also the part that determines whether the model you were sold ever sees a clean input.
This is why the choice of model is close to irrelevant to whether your project succeeds. Swap one frontier model for another and your integration problem is unchanged. The model is not your risk. Your risk is a fifteen-year-old HMIS with no API, an ADT feed that drops messages, and a lab system whose vendor wants a change-request fee to expose a single field.
What to ask before you sign
Stop opening the vendor conversation with model accuracy. Ask these instead.
Which of my systems have you read from before, by name and version, and how did you do it. If the answer is only FHIR, they have not worked inside a hospital like yours. Show me your HL7 v2 to FHIR mapping approach for a HMIS with no native FHIR support. Who owns the interface engine after go-live, and who fixes it at 2am when a feed dies. What is your plan for identity resolution across my four sites. How does a read path survive my security review under DPDP.
A team that has built and run this before will answer in specifics and timelines. A team that has only demoed will answer in slideware. The distance between those two answers is the distance between a system that goes live and a pilot that is still a pilot next year.
At Nextdot the AI Engineering practice is built around that order of operations: the integration layer first, the model last, and engineers who stay to run what they build rather than hand over an architecture diagram and an invoice. The intelligence has been solved by people other than us. Reading your hospital has not. That is where the real work sits, and it is the work that decides whether the rest of it was ever worth buying.