HL7 v2 — The Real-Time Backbone
The dominant real-time messaging standard across North American hospitals. Pipe-delimited and fast, it is supported by virtually every hospital system, interface engine, and clinical application.
HL7 v2: The Language of Hospital Data.
HL7 v2 carries real-time clinical messages across hospital systems — admissions, lab results, radiology, pharmacy. HL7 integration is the gateway for any digital health product.
Book a Technical Consultation
Talk to our integration team about your HL7 v2 or v3 implementation. We reply within 24 hours.
Trusted by startups and global leaders
Understanding HL7 Messaging Standards
HL7 (Health Level Seven) defines how clinical data moves between hospital systems. Two versions remain active — v2 for real-time messaging, v3 in Canadian provincial programs.
HL7 v3 — XML-Based & RIM-Grounded
An XML-based standard grounded in a Reference Information Model (RIM). Adopted in Canadian provincial drug and public health programs, but never displaced v2 in U.S. clinical settings.
In Plain Language
HL7 v2 and v3 are older but still widely used standards for exchanging clinical and administrative messages — patient admissions, lab orders, test results, and pharmacy records — between hospital systems.
What HL7 Integration Covers — Inbound and Outbound, v2 and v3
We integrate HL7 for digital health products, care management platforms, payers, and anyone who needs their systems to exchange real-time clinical data with hospital infrastructure.
Parse inbound HL7 v2 messages from any hospital information system into structured data your application can work with — and generate conformant outbound messages that hospital systems accept without error, correctly formatted and properly sequenced.
Build and consume HL7 v3 Clinical Document Architecture (CDA) and messaging payloads used in Canadian provincial programs — including drug information network (DIN) queries, laboratory result submissions, and public health reporting workflows.
Support two-way data exchange between your application and hospital systems — receiving real-time clinical events (ADT, lab results, orders) and sending acknowledgements, results, or updates back into the clinical workflow.
Connect to the interface engines that manage HL7 message routing in hospital environments — Rhapsody, Mirth Connect, Ensemble (InterSystems), and Cloverleaf — working within existing infrastructure rather than forcing hospitals to change their architecture.
Translate between HL7 v2 versions (2.3, 2.4, 2.5, 2.6, 2.7), between v2 and v3, and between HL7 and FHIR — enabling data to flow between legacy systems and modern platforms without loss of clinical meaning.
Map clinical codes between vocabularies — local hospital codes to LOINC for labs, medication codes to RxNorm, diagnosis codes between ICD-9 and ICD-10 — ensuring translated data retains its clinical accuracy.
Why HL7 Is Still Essential in North American Healthcare
Hospitals have decades of investment in HL7-based workflows, interface engines, and vendor contracts. HL7 v2 is not going away — and integrating with it cleanly is where the real engineering decisions live.
HL7 v2 Is the Practical Gateway to Clinical Data
For any digital health product that operates within hospital settings, HL7 integration is the practical gateway to real-time clinical data. The infrastructure, interface engines, and vendor contracts are already built around it.
ADT Feeds Drive Real-Time Patient Tracking
In the U.S., HL7 v2 ADT feeds from hospital EHRs are the standard mechanism for notifying care management platforms, health information exchanges (HIEs), and payer systems about admissions, discharges, and transfers.
Every Site Has Local Variations
The specification is one thing; real messages are another. Hospitals use optional fields differently and add non-standard segments. Integration that works against one site rarely works against another without reviewing actual sample messages.
Canada Runs on v2 — and v3 Where It Matters
In Canada, HL7 v2 remains the backbone of hospital clinical messaging, while HL7 v3 is present in provincial drug information and public health systems — with provincial patient identifiers (PHNs) that U.S. implementations do not use.
HL7 Integration — Step by Step
HL7 integration is a disciplined sequence, from understanding the messages to a validated go-live. Hover or tap a stage to see what it involves.
-
Message Inventory
Message Inventory
Identify which HL7 message types your integration needs to handle — ADT events, lab results, orders, scheduling, documents. Review sample messages from the source systems to understand local variations and non-standard field usage.
-
Connectivity Setup
Connectivity Setup
Establish the transport layer. Most HL7 v2 integrations use MLLP over TCP/IP — a persistent socket connection with specific framing characters. Define connection parameters, port assignments, and network routing with the hospital IT team.
-
Message Mapping
Message Mapping
Map each incoming HL7 segment and field to the corresponding data structure in your application. Document expected values, handle optional fields gracefully, and define how to process acknowledgement (ACK) messages.
-
Error Handling & Alerting
Error Handling & Alerting
Build rejection handling for malformed messages, missing required fields, and unknown event types. Set up alerting for failed deliveries, connection drops, and message queue backups.
-
Validation & Go-Live
Validation & Go-Live
Test with real message samples in a staging environment. Validate that ADT events trigger the correct actions, lab results map to the right patients, and outbound messages are accepted without errors.
Who This Is For
We build HL7 integrations for the products and organisations that depend on real-time hospital data. Hover a card to see how we work with each.
Digital Health Products
Care Management Platforms & HIEs
Payers & Health Plans
Hospitals & Health Systems
Message Types, Transport & Standards — The Building Blocks of HL7 Integration
HL7 integration spans the message types that carry clinical events, the transport that moves them, the engines that route them, and the terminologies that keep their meaning intact. We work across all of it.
Message Types
Clinical & Administrative Events
The HL7 v2 message types that drive real-time hospital workflows — admissions, results, orders, documents, and billing.
Transport
MLLP & Acknowledgements
The persistent socket transport HL7 v2 runs on, with correct framing and acknowledgement handling.
Interface Engines
Hospital Routing Infrastructure
The engines that manage HL7 message routing in hospital environments — we work within them, not around them.
Versions
HL7 Versions We Implement
Every HL7 v2 version still in production, plus v3 and CDA for the programs that require them.
Terminology
Code Systems & Mapping
Terminology mapping so codes translated between systems retain their clinical accuracy.
Canada
Canadian Provincial Programs
The HL7 v3 and identifier conventions specific to Canadian provincial drug information and public health systems.
The HL7 Stack We Build On
The interface engines, standards, transport, and terminology services an HL7 integration depends on — selected for the hospital systems you need to connect to, not a fixed toolset.
R
Rhapsody
M
Mirth Connect
E
Ensemble (InterSystems)
C
Cloverleaf
H
HL7 v2.3 – 2.7
H
HL7 v3
C
CDA / C-CDA
H
HL7 FHIR
D
DICOM
M
MLLP over TCP/IP
A
ACK / NACK
M
Message Queues
S
SFTP / File Drop
A
ADT
O
ORU (Results)
O
ORM / OMG (Orders)
M
MDM (Documents)
S
SIU (Scheduling)
L
LOINC
R
RxNorm
I
ICD-9 / ICD-10
S
SNOMED-CT
A
AWS GovCloud
A
Azure Health Data Services
D
Docker / Kubernetes
M
Monitoring & Alerting
Hospital Data Speaks HL7. Your Integration Should Too.
v2 and v3, inbound and outbound, across the interface engines hospitals already run. Book a consultation with our integration team and we will tell you what a correct, production-ready HL7 implementation looks like for the systems you need to connect to.
Book an HL7 Integration Consultation
Award-Winning AI Development & Consulting
100 Fastest Growth Companies
Global Spring Winner
Top App Development Company
AWS Partner Network
Google Cloud Partner
Highly Rated on Trustpilot
Verified Agency
Top App Development Company
ASSOCHAM Member
Frequently Asked Questions
[ 1 ]
What is MLLP and why is it used for HL7 v2?
MLLP (Minimal Lower Layer Protocol) is the standard transport for HL7 v2. It is a simple TCP/IP-based protocol that wraps each HL7 message with specific start and end characters, enabling persistent socket connections between systems. Most hospital interface engines communicate over MLLP by default.
[ 2 ]
What is an ADT message and why does it matter?
ADT (Admit, Discharge, Transfer) messages notify connected systems when a patient's status changes in a hospital. An A01 event means a patient was admitted, A03 means discharged, and A08 means demographic information was updated. ADT feeds are the foundation of real-time patient tracking across North America.
[ 3 ]
How is HL7 v2 different from FHIR?
HL7 v2 is an event-driven messaging format designed for real-time clinical transactions within hospital environments. FHIR is a resource-based API standard designed for data retrieval and exchange over the web. Many health systems use both — HL7 v2 for real-time internal clinical messaging and FHIR for external-facing API access to patient data.
[ 4 ]
Does Canada use different HL7 standards than the U.S.?
The core HL7 v2 specification is the same internationally, but Canadian implementations have differences — including the use of provincial patient identifiers (PHNs) and the use of HL7 v3 in specific provincial systems (drug information, public health) where U.S. systems typically stayed with v2.
Global presence