HL7 Integration Services
We build HL7 v2 interfaces that connect Epic, Oracle Health, MEDITECH, and clinical systems — ADT feeds, order routing, result delivery, and HL7 to FHIR bridging.
Reliable HL7 Interfaces for Healthcare Providers & Vendors
Saga IT builds and supports HL7 v2 interfaces for healthcare providers and third-party vendors connecting to Epic, Oracle Health, MEDITECH, and other EHR platforms. Whether you're a health system consolidating ADT feeds across departments or a software vendor building HL7 interfaces into your product — we handle specification, development, testing, and go-live support.
Who We Build HL7 Interfaces For
Four distinct integration shapes — each with its own message-type mix, latency profile, and certification path. Pick the one that matches your project.
Multi-EHR consolidation, ADT feeds, and HIE submissions
For hospitals running Epic, Oracle Health, MEDITECH, or a mix — we consolidate ADT feeds across departments, route orders and results to ancillary systems, and submit to HIEs, state immunization registries, and syndromic surveillance. Most engagements involve 5–25 simultaneous interfaces with dedicated MLLP listeners, custom Z-segments, and 24/7 monitoring on Mirth Connect or Rhapsody.
- Typical message mix: ADT^A01–A40 · ORU^R01 · ORM^O01 · SIU^S12 · MDM^T02
- Latency target: under 5 sec end-to-end · 99.9% uptime SLA
- Compliance: HIPAA · 42 CFR Part 2 · state HIE conformance
Customer-facing HL7 connectors, App Orchard certification, and FHIR bridges
For software vendors selling INTO health systems — we build the HL7 v2 + FHIR R4 layer that connects your product to every EHR your customers run. App Orchard / Connect Hub publishing for Epic, Cerner Code submissions, MEDITECH Greenfield development, plus the integration SDKs your customers can self-serve. We also handle the certification paperwork (ONC HTI-1, USCDI v3) and the security review checklist health systems demand before turning on a feed.
- Deliverable: customer-deployable HL7 connector + admin UI + monitoring
- Certification surfaces: Epic App Orchard · Cerner Code · MEDITECH Greenfield
- Standards: HL7 v2.5.1+ · FHIR R4 · SMART on FHIR · USCDI v3
Order-to-result loops, charge capture, and LOINC mapping
Ancillary systems live and die on the order/result loop. We build the bidirectional HL7 layer — ORM/ORR for orders, ORU for results — between EHR CPOE and your lab/pharmacy/imaging system, plus LOINC/SNOMED/RxNorm code mapping, abnormal-result routing, embedded PDF report delivery, and DFT^P03 charge posting back to the revenue cycle. We also wire the device middleware (instrument-to-LIS) where needed.
- Order/result depth: ORM^O01 · ORR^O02 · ORU^R01 · ORL^O22
- Code systems: LOINC · SNOMED CT · RxNorm · NDC · CPT/ICD-10
- Charge capture: DFT^P03 to revenue cycle · institutional + professional billing
Real-time device-to-EHR streams with sub-second latency
Medical devices push observations at clinical-decision-support latency — sometimes thousands per second across a critical-care unit. We build the device middleware (Capsule, BioMedical Systems, custom MLLP listeners) that aggregates raw telemetry, transforms it to HL7 v2 ORU^R01 or FHIR R4 Observation resources, and lands it in the EHR or downstream analytics platform. Includes IEC 62304 software lifecycle for SaMD-class deliverables and FDA 21 CFR Part 820 traceability.
- Throughput: 1000+ messages/sec · sub-100ms p99 latency
- Standards: HL7 v2 ORU · FHIR Observation · IEEE 11073 · IHE PCD
- Quality system: IEC 62304 · ISO 13485 · 21 CFR Part 820
HL7 v2 Interface Development
From single-point ADT feeds to enterprise-wide message routing — we build reliable HL7 v2 interfaces for every major message type. For technical deep-dives, see our HL7 reference documentation.
Real-time patient movement tracking that keeps demographics synchronized across your clinical ecosystem. We build A01 through A44 trigger event handlers including merge handling (A40) and pre-admit workflows. ADT message reference →
- Registration, admission, discharge, and transfer event handling
- Patient merge and link/unlink event processing (A40, A24)
- Census updates and bed management integration
- Pre-admit and pending transfer workflows
Lab, radiology, pathology, and microbiology results delivered directly into the ordering provider's workflow. We handle structured OBX values, embedded PDFs, and result status tracking. ORU message reference →
- Structured and unstructured result delivery (OBX segments)
- Preliminary, final, corrected, and amended result statuses
- LOINC-coded observation mapping
- Abnormal flag routing and critical result alerting
Bidirectional order messaging between CPOE systems and ancillary departments — lab, radiology, and pharmacy. Full order lifecycle from placement to completion. ORM message reference →
- New order, modification, and cancellation workflows
- Order acknowledgment (ORR) and status tracking
- Order-routing rules engine integration
- Placer/filler number management
Appointment synchronization between scheduling systems, EHRs, and departmental applications. We build handlers for the full S12–S26 event lifecycle. SIU message reference →
- New, rescheduled, modified, and cancelled appointment events
- Resource conflict detection
- Bi-directional sync with patient portals
- Multi-location scheduling coordination
Charge posting interfaces bridging clinical systems and revenue cycle management. We capture procedure codes, diagnosis codes, and charge details from ancillary systems for billing.
- DFT^P03 charge posting from ancillary systems
- Charge reconciliation and duplicate detection
- CPT/ICD code mapping and validation
- Institutional (UB-04) and professional (CMS-1500) billing integration
Clinical document routing for transcriptions, operative reports, clinical notes, and scanned documents. Embedded PDF/RTF content with provider-based routing rules. MDM message reference →
- Original and replacement document notification (T02, T11)
- Embedded document content (PDF, RTF, base64)
- Provider-based routing and document classification
- Document management system and EHR media manager integration
Same Clinical Data, Two Standards
Most clinical HL7 v2 segments have a corresponding FHIR resource. We build interfaces in both — and bridge them when you're ready to modernize.
HL7 v2 vs FHIR — When to Use Which
Both standards are alive and well in 2026 — and most production environments use them together. The right choice depends on what you're moving (real-time clinical event vs. on-demand resource), where it's going (hospital interface engine vs. patient-facing app), and which mandate is driving the work.
| Feature | HL7 v2.x | FHIR R4 |
|---|---|---|
| Transport | MLLP over persistent TCP | HTTPS REST |
| Payload format | Pipe-delimited segments (ER7) | JSON or XML |
| Interaction model | Push — event-driven | Pull — REST + subscriptions |
| Data unit | Message (with trigger event) | Resource (versioned, RESTful) |
| Real-time clinical events | Native (ADT, ORU, ORM) | Subscriptions / polling |
| Patient-facing apps | Not designed for this | Native (SMART on FHIR) |
| Hospital interface engines | Universal (Mirth, Rhapsody, etc.) | Increasing — most engines speak both |
| EHR coverage today | ~95% of US hospitals | Required by ONC HTI-1 / USCDI v3 |
| Regulatory drivers | Internal hospital workflows | CMS-9115 · TEFCA · USCDI · ONC HTI-1 |
| Versioning | v2.3 → v2.5.1 → v2.8 | DSTU2 → STU3 → R4 → R5 → R6 |
| Idempotency | No — duplicate ACKs / re-sends | Yes — version IDs + If-Match |
| Best for | Hospital-internal real-time messaging | API integrations · patient apps · regulatory |
The short answer: if you're moving real-time clinical events between systems already inside a hospital, HL7 v2 wins on coverage — almost every EHR speaks it natively, and integration engines are built around it. If you're building a patient-facing app, integrating with non-EHR systems, or satisfying CMS-9115 / TEFCA / USCDI regulatory mandates, FHIR R4 is the right answer — modern, REST-based, and required by 2027 deadlines. Most production environments end up running both, with an HL7 v2 ↔ FHIR bridge in the integration engine for the hand-off.
EHR Systems We Integrate
Epic
Acute care · academic
02 OrOracle Health
Acute care · federal
03 MtMEDITECH
Community hospitals
04 eCeClinicalWorks
Ambulatory · primary care
05 NxNextGen
Specialty · ambulatory
06 Atathenahealth
Ambulatory · cloud-native
Don't see your EHR? We build HL7 interfaces for any system. Get in touch to discuss your integration.
The Engine Layer Sits Underneath All of This
An HL7 integration engine is the listener, transformer, and router that runs your interfaces — Mirth Connect, Rhapsody, Cloverleaf, Iguana, OIE, and InterSystems are the dominant choices. We support all of them, and help you pick when starting fresh.
For a deep comparison of the major integration engines — performance characteristics, licensing model, support footprint, and migration paths between them — see our dedicated engines service page. We also publish on-prem and cloud reference architectures, plus migration playbooks for teams moving from Mirth Connect to Open Integration Engine (OIE) or commercial alternatives.
Compare integration enginesHL7 to FHIR Conversion & Mapping Services
HL7 v2 isn't going away — but most modern systems read FHIR R4. We bridge the two, segment by segment, with mapping services that survive production traffic and handle the implementation-specific quirks of every major EHR.
HL7 to FHIR conversion
HL7 v2 to FHIR R4 conversion services for healthcare technology vendors and health systems modernizing their integration stack. We build production HL7-to-FHIR bridges in Mirth Connect, OIE, or your existing interface engine — converting ADT to Patient/Encounter, ORU to Observation/DiagnosticReport, ORM to ServiceRequest, and SIU to Appointment with bidirectional sync where the workflow demands it. Per-EHR conformance handled separately so Epic, Oracle Health, Meditech, and Athena all map cleanly.
- Mirth Connect
- OIE
- US Core
- Bidirectional
- ADT^Axx → Patient + Encounter + Coverage with version-aware field mapping
- ORU^R01 → Observation + DiagnosticReport + Specimen with LOINC mapping
- ORM^O01 → ServiceRequest with priority + reason-for-study handling
- SIU^Sxx → Appointment + Slot with provider + resource scheduling
- Bidirectional sync with conflict resolution and outbound FHIR → HL7 v2 reverse mapping
HL7 mapping services
HL7 v2 message mapping services across vendor variants — the same ADT^A04 message looks different from Epic vs Oracle Health vs Meditech, and your downstream consumer needs a normalized view. We build mapping libraries (Mirth transformers, OIE channels, JavaScript scripts) that abstract the vendor differences, so your downstream EHR / data warehouse / analytics platform sees consistent data regardless of source. Includes Z-segment handling, custom OBX value-typing, and the documentation your QA team needs to certify the mapping.
- Vendor normalization
- Z-segments
- OBX typing
- QA-certified
- Vendor-normalization mapping libraries — single canonical model from N source EHRs
- Z-segment handling for vendor-specific extensions (ZPI, ZAL, ZDS, ZIN, ZBE)
- OBX value-typing across NM / ST / CWE / CE / FT for accurate downstream parsing
- Mapping documentation packages aligned to your QA / validation requirements
- Source-truth registry tracking version drift across upstream EHR releases
HL7 EHR & EMR integration
HL7 EHR integration and HL7 EMR integration projects across Epic, Oracle Health (Cerner), Meditech, eClinicalWorks, NextGen, and Athena. Each EHR has its own HL7 v2 implementation guide — message types accepted, segment requirements, ack expectations, and the operational quirks that aren't in any spec doc. Saga IT's interface engineers have shipped HL7 v2 interfaces against all six major US EHRs, so we bring vendor-specific working knowledge to your integration build.
- Epic Bridges interface specifications and Vendor Services release-cycle alignment
- Oracle Health Open Engine + OPI configuration with Cerner Millennium
- Meditech NPR / MOX message routing across Magic, Client/Server, and Expanse
- eClinicalWorks, NextGen, and athenahealth HL7 v2 implementation specifics
- Conformance testing harness reused across vendors for consistent QA evidence
HL7 Integration in Action
How we build, integrate, and deploy clinical software that transforms patient care.
Point-of-Care Device to EHR Integration
A healthcare system deployed a new point-of-care diagnostic device that generates multiple vital signs and lab values. Raw data points from the device are transformed into standardized FHIR Observation resources and stored directly in the EHR system, enabling real-time clinical decision support without manual data entry.
"hr": 94,
"bp_sys": 128,
"spo2": 97
"code": { "coding": [{
"code": "8310-5"
}] }
Need an HL7 interface built? Let's talk.
Book a ConsultationHL7 Integration Questions
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.
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.
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 reference documentation for detailed breakdowns.
Related Services
Explore More Services
Resources
Talk to an HL7 Integration Expert
From ADT feeds to complex message routing — let's build your HL7 interfaces.
- 15 min conversation
- Healthcare IT engineers, not sales
- Reply within one business day
Book a 30-min call · or email us and we'll reply within one business day.