Why healthcare data still doesn't talk to itself

01.The data exists, the connections do not

It helps to be precise about what "does not talk" means. In most hospitals, the systems do exchange some data. Admission messages flow to the lab. Results flow back. Orders reach pharmacy. The trouble is that these links were built one at a time to solve a specific need, and the sum of them is not a coherent picture.

Each link has its own format, its own quirks, and often its own owner. Nobody can easily answer simple questions. Which systems feed this one? What happens if this server restarts? If a result does not appear, where do we look first?

02.Why it is still hard

• Different standards, different versions. HL7 v2 messages, FHIR resources, CDA documents and custom formats all coexist. Even within HL7 v2, two systems may differ in which version they speak and which fields they populate.
• Patient matching. The same person can appear with different IDs, spellings and addresses across systems. Matching them is a balance. Be too loose and you merge two people. Be too strict and you miss records.
• Codes that do not line up. One system's lab code is not another's. Mapping terminology is slow, careful work, and it needs clinical review, not only engineering.
• Fear of breaking things. Interfaces that carry clinical data cannot simply be switched off and rebuilt. Teams are right to be cautious, and caution slows change.

None of these is a mystery. They are ordinary engineering problems with high stakes, and they respond to patient, methodical work.

03.A small example

Consider a hospital with a main EHR, a separate laboratory system and a radiology archive. A doctor wants to see recent results for a patient admitted overnight. The lab system labels a test with a local code. The EHR expects a standard one. The patient was registered twice, once in the emergency department and once on the ward, with a spelling difference in the surname.

Three small mismatches, and the result does not show. Nobody did anything wrong. The system was simply never designed to resolve these differences. Fixing it takes a mapping table, a matching rule and a monitored interface, and each of those needs an owner.

04.What is changing

Regulation is forcing the issue. Under CMS-0057-F, impacted payers must stand up FHIR-based Patient Access, Provider Access, Payer-to-Payer and Prior Authorization APIs by January 1, 2027. That deadline is pulling providers and vendors toward FHIR too, because data has to move between payers, providers and patients' own apps in a consistent way.

Other pressures point the same way. Patients expect to see their own records. Clinicians expect fewer logins. Auditors expect logs. Taken together, these make point-to-point wiring harder to defend.

05.Where to start

Inventory every interface you run today, what it carries and who owns it. Then pick one high-value flow, such as a combined patient history or prior authorization, and build it on FHIR first.

A practical sequence looks like this:

• List interfaces, owners, volumes and known failure points.
• Rank flows by clinical or financial value and by risk.
• Choose one flow with a clear owner and a clear measure of success.
• Build the exchange layer with monitoring and audit logging from the start.
• Run it beside the old feed, compare, then cut over.
• Repeat for the next flow.

06.What a good first project looks like

The best first projects share a few traits. They have a clear owner who cares about the result. They touch a small number of systems, ideally two or three. They produce something a clinician or a patient will notice. And they can run beside the existing process, so nobody is forced to trust them on day one.

A combined patient timeline fits well. So does a prior authorization flow, where delays are visible and costly. A poor first project is the one that requires every department to agree on a single definition before anything is built.

Plan the first project as a rehearsal for the rest. You will learn how long mapping really takes, who can approve a terminology decision, how test data is obtained and what the vendors need to do on their side. Write those lessons down. They shorten the second project more than any tool does.

07.The role of monitoring

Interfaces fail quietly. A message is dropped, a queue grows, a certificate expires and a feed stops. Nobody notices until someone asks where a result went. Monitoring turns silent failures into alerts.

At a minimum, track four things for each interface: messages received, messages delivered, messages failed and the age of the oldest message waiting. Alert a named person when any of them moves outside a normal range. Keep a dead-letter queue for messages that cannot be delivered, and review it daily. This is basic practice, and it is rare in older point-to-point setups.

Audit logging belongs in the same conversation. Record who accessed which patient's data, when and through which channel. Keep personal data in logs to what you need. When an auditor asks for evidence, you want to answer from records, not from memory.

08.A note on people

Technology is rarely the slowest part. Clinical review of mappings, vendor release cycles and change approvals take time. Involve a clinician early and give them a short, specific job, such as confirming that two lab codes mean the same thing. Involve the vendor early too, because their test environment is often the bottleneck. A project plan that ignores these dependencies will slip.

09.Common mistakes

• Starting with a big-bang replacement of every interface.
• Treating terminology mapping as a purely technical task, without clinical review.
• Merging patient records aggressively to show a quick win.
• Building new interfaces without monitoring, which recreates the old fragility.
• Leaving ownership unclear, so no one is paged when a feed stops.

10.A short checklist for the inventory

• Interface name and purpose.
• Sending and receiving systems, with versions.
• Message types and approximate daily volume.
• Owner on each side and an escalation contact.
• Known failure modes and last major incident.
• Whether it is monitored, and by whom.

11.Why ownership matters more than tooling

Almost every stuck interoperability effort has the same root problem: no single person is accountable for how data moves. One team owns the EHR, another owns the lab system, and the interface between them belongs to whoever built it years ago. When it fails, each side assumes the other will fix it. Name an owner for every interface, and give that owner the authority to schedule changes.

12.What to do next

Start with the inventory. It costs little, and almost every organisation learns something from it. Then choose a first flow and define what success looks like in plain terms: a time saved, a failure rate reduced, a deadline met.

If it helps to have senior integration engineers alongside your team while you do this, Brandsmashers works with hospital and payer teams on HL7 and FHIR projects. Clients remain responsible for their own regulatory compliance, and we build to the published standards.