HL7 Integration Services

An HL7 ADT (Admit, Discharge, Transfer) message is the event-driven notification an EHR sends when a patient is admitted, discharged, transferred, registered, or has demographics updated. ADT is the most common HL7 v2 message type, moving millions of times per day across US hospitals over MLLP/TCP connections. Each ADT carries a trigger event code (A01 = admit, A03 = discharge, A04 = register outpatient, A08 = update patient info, A11 = cancel admit, A40 = merge patient IDs). Message structure includes MSH (header), EVN (event), PID (patient identifiers), PV1 (visit info), and optionally NK1, AL1, DG1, GT1, IN1 depending on use case. Downstream systems consume ADT to keep their patient lists in sync — labs, PACS, billing, registration kiosks, and quality measurement all depend on the ADT feed. See our HL7 ADT documentation for full segment-by-segment annotation.

An HL7 interface engine is healthcare middleware that receives HL7 v2 messages over MLLP, applies transformation rules, routes them to destination systems, and handles ACK/NACK delivery confirmation. The terms "interface engine" and "integration engine" are used interchangeably in healthcare IT — "interface engine" is the older HL7-era term; "integration engine" became dominant as engines expanded into FHIR R4, X12 EDI, and DICOM. Common HL7 interface engines: Mirth Connect (most widely deployed), Open Integration Engine (OIE) (community fork after NextGen's 2025 licensing change), Rhapsody (enterprise commercial), Iguana, Corepoint, and InterSystems IRIS / Ensemble. See our healthcare integration engines comparison for tradeoffs.

HL7 integration is the practice of connecting healthcare systems using the HL7 family of standards — primarily HL7 v2 (the pipe-delimited messaging standard used inside roughly 95% of US hospital interfaces) and HL7 FHIR (the modern RESTful API standard increasingly mandated by CMS and ONC). A working HL7 integration links an EHR, lab, pharmacy, radiology system, scheduling system, or HIE to whatever downstream system needs the data — typically through an integration engine that listens, transforms, routes, and monitors every message. See our HL7 reference documentation for the full message-type and segment breakdown.

A single point-to-point ADT interface typically takes 2–4 weeks including specification, development, testing, and go-live. Bidirectional order/result interfaces (ORM/ORU) with custom Z-segments generally require 4–8 weeks. Enterprise-wide projects spanning multiple message types across numerous systems can take 3–6 months. The largest variables are vendor responsiveness during testing and the completeness of interface specifications — factors we help manage through structured project planning.

HL7 v2 uses pipe-delimited messages transmitted over persistent MLLP/TCP connections — it is event-driven and handles approximately 95% of real-time clinical data exchange in US hospitals. FHIR uses RESTful APIs with JSON over HTTPS, designed for web applications, patient portals, and regulatory requirements like the CMS Interoperability rules. Most organizations use both — HL7 v2 for existing clinical messaging and FHIR for new API-based integrations. We help you bridge both standards with dual-protocol interfaces.

An HL7 integration engine is the listener, transformer, and router that runs every interface in your environment — Mirth Connect, Open Integration Engine (OIE), Rhapsody, Cloverleaf, Iguana, and InterSystems Health Connect are the most common choices. For new deployments we typically recommend Mirth Connect or OIE (its actively-maintained open-source successor) — both are free, have large communities, and handle the same channel/transformer model. For high-throughput enterprise environments with formal vendor support, Rhapsody or InterSystems are the established options. We work with all of them; see our integration engine comparison for a deep tradeoff analysis.

For Epic, HL7 integration usually uses Epic Bridges (their internal HL7 v2 platform) with v2.5.1 messages over MLLP, plus increasingly FHIR R4 APIs via the App Orchard / Open Epic program for patient-facing apps. For Oracle Health (formerly Cerner), it is typically Millennium HL7 v2 over MLLP, with FHIR R4 endpoints exposed for regulatory use cases. Both vendors require a project-specific spec exchange, test-environment provisioning, and vendor coordination during validation — we manage that process end-to-end. See our Epic integration and Oracle Health integration service pages for vendor-specific depth.

Practically none — the terms EHR (Electronic Health Record) and EMR (Electronic Medical Record) are used interchangeably in HL7 integration work. The technical pattern is the same: HL7 v2 messages (ADT for patient context, ORM/ORU for orders and results, SIU for scheduling, MDM for documents) flow between the EHR/EMR and whatever downstream system needs the data — typically through an integration engine. EHR is the slightly more current term and tends to imply a broader record (multi-encounter, multi-facility); EMR more often refers to a single-practice record. The integration engineering is identical.

Yes — HL7 v2 → FHIR migration is one of our most common engagements. The typical path is not "rip out v2" but "bridge v2 to FHIR" inside the integration engine: ADT^Axx → Patient + Encounter + Coverage, ORU^R01 → Observation + DiagnosticReport, ORM^O01 → ServiceRequest, SIU → Appointment + Slot. The v2 interfaces keep running for internal clinical messaging while FHIR endpoints get exposed for patient-facing apps, regulatory reporting, and external API consumers. Most organizations end up running both standards in parallel for years. See our FHIR API integration service for the FHIR side of the bridge.

Yes — Z-segments are a core part of most HL7 implementations. We develop Z-segment specifications, mapping documents, and implementation guides for site-specific data elements like custom patient identifiers (ZPD), insurance plan details (ZIN), clinical trial enrollment data, and facility-specific billing codes. Every Z-segment we build includes complete field definitions, data type documentation, and optionality rules for consistent implementation.

Yes — EHR-to-ancillary integration is one of our most common engagements. We build HL7 interfaces between EHR systems (Epic, Oracle Health, MEDITECH, athenahealth) and laboratory information systems, pharmacy systems, radiology platforms, and Health Information Exchanges. This typically involves ADT feeds for patient context, ORM/ORU for order/result workflows, and sometimes SIU for scheduling synchronization. See our HIE integration services for exchange connectivity.

Yes — alongside greenfield interface builds, we offer ongoing HL7 integration support and managed-services engagements: 24/7 interface monitoring, on-call response for failed acknowledgments and dropped connections, queue-depth alerting, channel-version upgrade work, and Z-segment / mapping changes as your upstream EHRs release new versions. Most of our managed-services customers come to us after a one-time build engagement and stay on for ongoing run-the-bank operations.

We build interfaces for all standard HL7 v2 message types: ADT (patient movement), ORU (clinical results), ORM (orders), SIU (scheduling), MDM (documents), DFT (financial transactions), RDE (pharmacy), VXU (immunizations), and ACK (acknowledgments). Each message type has specific trigger events and segment structures — for example, ADT^A01 for admissions and ORU^R01 for lab results. See our HL7 message reference for detailed breakdowns of every type.