← Back to articles
article·

Electronic health records and the interoperability problem AI can't fix alone

Electronic health records and the interoperability problem AI can't fix alone

The pitch for a healthcare AI agent usually assumes a clean, unified patient record sitting somewhere waiting to be queried. In practice, that record doesn't exist. It's scattered across systems that don't talk to each other, and that's the problem an agent runs into before it ever gets to being clinically useful.

Every hospital has more than one "source of truth"

A single patient's history might live across a hospital's primary EHR, a separate lab information system, a radiology PACS, a specialist's own clinic software, and paper records that were scanned in at some point and never fully structured. Each system has its own way of representing the same clinical concept — a medication, a diagnosis code, an allergy — and reconciling those representations is most of the actual work in any serious health IT project.

This is not a new problem AI created. It's a decades-old problem that AI inherits the moment it tries to be useful across more than one system.

FHIR helped, but it didn't solve it

HL7's FHIR (Fast Healthcare Interoperability Resources) standard gives systems a common structured format to exchange clinical data — patient demographics, observations, medications, conditions — over a modern API instead of proprietary file formats. Adoption has genuinely improved data exchange between systems that implement it well.

What FHIR doesn't fix is semantic inconsistency: two systems can both be FHIR-compliant and still code the same diagnosis differently, structure a medication dosage differently, or simply not populate a field the other system expects. Standards solve the format problem. They don't solve the "does this data actually mean the same thing everywhere" problem.

What this means for an AI agent trying to answer a clinical question

An agent asked "has this patient had this medication before" needs to check every system that might contain that answer, reconcile inconsistent formats and terminologies, and — critically — know when it doesn't have full visibility rather than confidently answering based on partial data. An agent that only queries the primary EHR and presents its answer as complete is worse than one that says "I could only check system X; the patient may have records elsewhere I don't have access to."

The unglamorous fix

Most of the value in a health IT integration project isn't the AI layer — it's the unglamorous work of mapping terminologies, building reliable connectors to each source system, and being honest about coverage gaps. An agent built on top of that groundwork is genuinely useful. An agent built on top of "we connected to the main EHR and called it done" will produce confident, incomplete answers, which in a clinical context is worse than no answer at all.

Share this post

Instagram: Copy the link and share it in your Instagram story or post.

Comments (0)

No comments yet. Be the first to share your thoughts.