The Belief Gap vs. the Readiness Gap in Healthcare AI

The gap nobody wants to name

Ask a room full of healthcare leaders if AI is essential to their future and almost all of them will say yes. Ask that same room how many feel equipped to actually deploy AI today, and most hands go down.

That is not a belief gap. Nobody needs convincing anymore. It is a readiness gap, and it lives in the data. The budget conversations are happening. The appetite is there. And the projects stall anyway, in the same place, for the same reason: the data underneath was never actually connected.

What fragmentation looks like inside a real practice

Walk into a typical small or mid-size healthcare practice and you will not find one system. You will find four or five, stitched together over a decade of separate purchasing decisions, each one solving a problem that existed at the time it was bought.

There is the EHR, holding the clinical record: notes, diagnoses, orders, results. There is a separate practice-management system handling scheduling, registration, and eligibility, which may or may not be the same vendor as the EHR. There is a billing platform reconciling claims and payments against encounters that live in the other two systems under slightly different identifiers. And there are the point solutions: a patient-engagement tool, a fax-to-EHR bridge, a lab portal, a telehealth add-on, each one bolted on to solve one problem, each one holding its own slice of patient and encounter data.

None of these systems were designed around each other. Each one has its own idea of what a “patient” record looks like, its own encounter numbering, its own timestamp conventions. Nothing forces them to agree. Four systems, four different definitions of a patient, and no connecting architecture holding them together.

FHIR, HL7v2, and the standard that’s supposed to fix this

Two generations of interoperability standard sit inside most practices right now, and they are not the same thing, even though they get talked about interchangeably.

HL7v2 is the old workhorse. It moves real-time clinical events between systems today, an ADT feed announcing that a patient was admitted or discharged, a lab-result message carrying a new value out of the lab system and into the chart. It is unglamorous and it is everywhere.

FHIR is the newer standard, built to be easier to build against and to expose data through a modern API, resource by resource: a Patient resource, an Encounter resource, an Observation resource. It is the standard the ONC Cures Act Final Rule and the CMS Interoperability and Patient Access Rule point to for patient-access APIs.

These two standards are not in a handoff. HL7v2 keeps moving the real-time operational traffic, the ADT feeds and lab results, while FHIR handles the newer API-based patient-access layer, in the same buildings, often in the same practice, at the same time.

The part vendor marketing leaves out

A FHIR endpoint is a compliance checkbox. It says nothing about whether the lab system, the scheduler, and the billing platform underneath it agree on what a patient record is.

A practice can expose clean FHIR resources at the API layer while those internal systems still don’t share a common patient ID, encounter structure, or coding scheme. “We have FHIR” becomes a line on a compliance sheet, not a description of the practice’s actual data architecture. The endpoint gets built at the edge. The integration underneath does not happen on its own.

The fix that actually works at small scale

The instinct, once a practice sees this clearly, is to reach for a full platform rebuild: replace the EHR, unify everything, start clean. That is usually the wrong move for a small or mid-size practice. It is slow, expensive, and it puts the AI project behind a multi-year migration.

The better path is narrower. Build a small, scoped data-consolidation layer, a lightweight warehouse pulling from the three or four systems the practice already has, purpose-built to feed one specific, well-defined AI use case. Not a general-purpose data platform. One use case, one clean pipeline, done properly.

We wrote about what one of these systems looks like once the data problem underneath it has actually been solved, in Building a Privacy-First Healthcare RAG Assistant That Runs Entirely on Local Hardware. That system works because the consolidation layer was built first, scoped narrowly, and matched to one real question the practice needed answered. It is not a general AI platform. It didn’t need to be.

What changes once the layer is built

Once that scoped layer exists, the AI project stops being a data project in disguise. The team building the model or the assistant is working against one clean, consistent view of the patient, not reconciling four disagreeing systems as a side task. New use cases get cheaper to add, because the consolidation work is already done and only the pipeline to the new use case has to be built. And the practice can finally tell the difference between “we have FHIR” and “our data actually agrees with itself,” which is the distinction that was collapsing every deployment before.

The endpoint was never the problem. The data underneath it was.

What this looks like from the inside

I’ve done this work directly, not just written about it. At Jackson Health, a 2,200-bed system based in Miami, I built and maintained data workflows on InterSystems IRIS, learning ObjectScript to do it, every time the hospital acquired or onboarded a new system. Each new acquisition brought its own patient identifiers, its own file formats, its own idea of what a clean record looked like: the same fragmentation this piece is describing, just from the inside instead of the outside.

The fix was not a platform rebuild. It was building workflows that caught data errors before they ever reached a database, and consolidating every external FTP exchange, the files going out to vendors and reporting agencies and the files coming back in, under one team responsible for the quality and accuracy of that traffic. One team, one set of validated pipelines, instead of every new acquisition inventing its own ad hoc export process and hoping nothing broke downstream.

Jackson Health’s own published work with InterSystems gives a public sense of the scale that kind of unified data layer operates at once it exists: an emergency-department “frequent flyer” identification app built in four weeks that cut the health system’s net cost subsidy by $2 million in its first six months, and an appointment-reminder system that dropped no-show rates 16 to 24 percent for about $3.10 a day to run (InterSystems case study). Neither of those apps was possible until the underlying data was actually unified. That is the order of operations this whole piece is arguing for.

That is the scoped-layer argument from this piece, tested in production, not in theory. It does not require a new EHR. It requires deciding that data quality is somebody’s actual job before the data moves, not something an audit finds after it already has.