Data Integration for Hospitals: EHR, HL7, FHIR, and the Operational System Mesh

A typical hospital runs hundreds of integration points. The EHR exchanges HL7 v2 messages with the laboratory, radiology, pharmacy, dietary, and dozens of bedside devices. The integration engine (Rhapsody, Mirth/NextGen Connect, Cloverleaf) handles message routing and transformation. FHIR APIs are emerging for newer integrations. The supply chain system integrates with the EHR for charge capture. Scheduling integrates with billing. Each interface has been built over years by different vendors and teams. Each follows HL7 v2 conventions but with the field-level customizations that always exist. When something breaks at 2am, the on-call team has to trace the message path through systems that nobody fully documents. Generic enterprise integration doesn't address any of this.

Hospital integration that works follows hospital-specific patterns. The integration engine as the message routing backbone with proper monitoring and dead-letter handling. HL7 v2 conformance profiles documented per interface. FHIR APIs for new integrations where the trading partners support them. Real-time replication where clinical workflows depend on timely data, batch where they don't. Audit logging on every PHI exchange. And the runbooks that let the on-call team trace a missing lab result back to its source within minutes, not hours. Done with this discipline, hospital integration is reliable enough to support clinical operations. Done as ad hoc point-to-point connections, it produces architecture that breaks during the next system upgrade and frustrates clinicians during downtime.