Healthcare Data Integration: Choosing an Architecture Before You Need One

Every organisation we work with has a diagram somewhere showing how their systems connect. In the healthy version, there is a box in the middle and lines running to it.

In the other version, which is more common, every system connects directly to every other system it needs, and the diagram looks like a plate of noodles. Forty-odd lines. Three of them drawn in a different colour because nobody is sure whether they are still live.

Nobody chose that. They arrived at it, one urgent connection at a time, each one entirely reasonable on the day it was built.

This post is about the decision that prevents it, and about the parts of healthcare data integration that sit outside the clinical record, where most of the attention goes.

Must Read: Clinical Data Integration: Why the Single Patient View Is So Hard to Build

Healthcare data is more than clinical data

Teams say "healthcare data" and picture labs, medications and diagnoses. That is one domain of five, and the other four carry their own standards, owners and failure modes.

Clinical. Results, medications, problems, notes, imaging. HL7 v2, FHIR, C-CDA. Owned by IT and clinical informatics.

Financial. Claims, eligibility, remittance, prior authorisation. These move over X12 EDI transactions, which look nothing like HL7 and are usually handled by a completely separate team on a separate schedule.

Administrative. Scheduling, registration, bed management, referrals. Often HL7 v2 (SIU and ADT), sometimes vendor APIs.

Operational. Staffing, supply chain, asset tracking, throughput. Usually whatever the vendor offers, which may be a nightly CSV.

Device. Monitors, infusion pumps, wearables, remote patient monitoring. Proprietary protocols, sometimes HL7 v2, increasingly FHIR.

The integration failures that hurt most tend to sit at the seams between these, not inside one of them. A patient is discharged (administrative), which should stop a care management workflow (clinical) and trigger a claim (financial). Three systems, three teams, three standards, and nothing owns the sequence end to end.

Three architectures, and how you end up with each

Point-to-point. Each system connects directly to each system it needs.

Fine at three or four systems. The problem is arithmetic: connections grow roughly with the square of the systems. Ten systems that all need each other is forty-five possible connections. Nobody builds all of them, but you build enough that changing one system means touching five interfaces and testing twelve.

The honest case for it: for two or three stable connections, an interface engine is overhead you do not need yet. The trap is that nobody notices the moment it stops being two or three.

Hub and spoke. Everything connects to a central interface engine. Mirth Connect, Rhapsody, Corepoint, Iguana. The engine handles routing, transformation, monitoring and replay.

This is where most hospitals land, and for good reason. Adding a system means one connection, not six. Monitoring is in one place. When a feed fails at 2am, somebody can see which one and replay it.

The cost is a real dependency. The engine becomes infrastructure, needs someone who knows it, and is a single point of failure that has to be designed for.

iPaaS and API gateway. Cloud integration platforms, or healthcare-specific networks like Redox, Health Gorilla and Particle Health that maintain the connections to EHRs on your behalf.

Compelling for vendors selling into many health systems, because the alternative is building and maintaining an interface per customer. The trade-offs are per-transaction cost at volume, dependence on their roadmap for anything unusual, and the fact that you still own patient identity and terminology on your side.

Choosing, without pretending it is a clean decision

Count your systems honestly, including the ones nobody mentions in meetings. Under five, point-to-point is defensible. Beyond that, an engine is usually cheaper by the second year.

Count your directions. Reading from one EHR is a different problem from reading and writing across several.

Count your customers, if you are a vendor. One health system, build it yourself. Ten, and a network starts looking less like a cost and more like the only way to stay sane.

Ask who maintains it in year two. This question decides more architectures than any technical criterion, and it is the one most often left unasked. An elegant design nobody on staff can operate is worse than a plainer one they can.

The standards you will meet

| Domain | Standards | | --- | --- | | Clinical messaging | HL7 v2, FHIR | | Clinical documents | C-CDA | | Claims and eligibility | X12 (837, 835, 270/271, 278) | | Lab observations | LOINC | | Clinical concepts | SNOMED CT | | Diagnoses | ICD-10-CM | | Procedures | CPT, HCPCS | | Medications | RxNorm, NDC | | Imaging | DICOM |

The first four rows describe how data travels. The rest describe what it means, and that second group is where integration projects quietly overrun. Mapping a field is an afternoon. Working out that this hospital's lab sends local codes with a crosswalk maintained by someone who left in 2021 is a month.

National exchange adds another layer. TEFCA and its QHINs are building a framework for organisations to share records across networks, and interoperability requirements have pushed vendors to expose FHIR APIs. Worth understanding if you operate across organisations. Not a substitute for the integration work in front of you.

Build in this order

Start with the question, not the connection. "Integrate the lab system" is not a requirement. "A care manager needs to see abnormal results within fifteen minutes of posting" is, and it tells you the direction, latency and volume.

Inventory what you have. Every system, what data it holds, who owns it, how it already connects. This is dull and almost always surfaces two integrations nobody remembered and one that broke months ago without anyone noticing.

Decide identity before you move anything. How you know a record in system A is the same person as in system B. Get this wrong and every downstream integration inherits the error. It is covered in clinical data integration, and it is the decision that most deserves a clinician in the room.

Pick the architecture for where you will be in two years, not where you are. Migrating from point-to-point to an engine later is doable, and it costs more than starting there.

Build one interface properly before building six. The first one teaches you what the hospital's data actually looks like, which is never quite what the specification said. Our EHR integration services page walks through what each phase involves.

Instrument from day one. Message counts, failures, latency, last-successful-sync per feed. Integrations fail silently, and "it has been quiet" and "it has been broken since Thursday" look identical without monitoring.

Governance, briefly, because it decides more than architecture

Who approves a new integration. Who owns each feed when it breaks. Who maintains the terminology mappings as codes change. What the retention and access rules are for data you now hold but did not generate.

Organisations with good answers run plainer architectures successfully. Organisations without them build elegant ones that degrade into the noodle diagram within eighteen months, because every new connection is an exception somebody approved under deadline pressure.

The short version

Healthcare data integration spans five domains, not just the clinical one, and the painful failures live at the seams between them. Point-to-point is fine until it suddenly is not, hub-and-spoke is where most organisations should end up, and a network or iPaaS makes sense when you are selling into many health systems rather than running one.

Standards for moving data are the easy half. Standards for what data means, and the governance that keeps mappings current, are where the time goes. Decide patient identity first, build one interface properly, and instrument everything, because silent failure is the default.

Looking at a diagram with too many lines on it? Tell us what you are running and we will give you a straight read on what to consolidate first. No pitch.

Must Read: FHIR vs HL7: They're Both HL7, and That's Half the Confusion