HL7 v2 — The Standard That Refuses to Retire
First published in 1987, HL7 v2 is a pipe-delimited text format still carrying most real-time clinical messages in North American hospitals — ADT events, lab results, pharmacy orders, radiology reports.
What HL7 Actually Is — and Why It Matters
HL7 (Health Level Seven) is a standards organization producing healthcare interoperability standards since 1987 — not a single standard. Asking for an "HL7 integration" without naming which one is like specifying a database without saying relational, document, or graph.
HL7 v3 — Important to Know, Limited in Practice
An XML-based replacement for v2 from the late 1990s, HL7 v3 never reached broad adoption. It survives in Canadian provincial systems and as the basis for C-CDA, the clinical document format mandated under U.S. ONC regulations.
FHIR — The Modern Standard
FHIR (Fast Healthcare Interoperability Resources) is the primary standard for new implementations globally, using REST, JSON, and OAuth 2.0. FHIR R4 is the mandated version in the United States under ONC regulations.
C-CDA — For Structured Clinical Documents
The Consolidated Clinical Document Architecture is the mandated format for structured clinical document exchange under U.S. ONC regulations — covering care summaries, discharge summaries, referral notes, and care plans.
The Practical Reality for 2026
Teams building for hospitals in 2026 will hit all three: HL7 v2 for real-time events, FHIR R4 APIs for certified EHR access, and C-CDA for document exchange. Knowing which applies where is the foundation of sound integration architecture.
When to Use Which Standard
A practical decision framework for choosing between HL7 v2, FHIR, and C-CDA based on use case, integration target, and data requirements.
Use HL7 v2 for Real-Time Event-Based Clinical Notifications
ADT events, lab results, radiology reports, pharmacy orders, and scheduling flow through hospital interface engines as HL7 v2. Where data lives in the v2 layer, connecting there is usually most reliable — whatever FHIR endpoint the EHR also exposes.
Use FHIR for On-Demand Data Queries and EHR Write-Back
FHIR R4 is the right standard for querying patient data on demand, integrating with ONC-mandated EHR APIs, EHR write-back through a standardized interface, and patient-facing data access under information access regulations.
Use C-CDA for Structured Clinical Document Exchange
C-CDA is the ONC-mandated format for care summaries, discharge summaries, referral notes, and care plans. Every certified EHR is required to generate and receive C-CDA for document-level interoperability.
Most Hospital Integrations Require All Three
A product serving hospital customers in 2026 typically needs HL7 v2 for real-time clinical events, FHIR R4 for on-demand queries and write-back, and C-CDA for document interoperability. Designing for only one leaves gaps that surface during live implementations.
The Specific Confusions That Break Integrations
Six confusion patterns that appear repeatedly in digital health development — and how each translates directly into expensive integration rework.
Most Expensive
Assuming FHIR Has Replaced HL7 v2
Teams that design entirely on FHIR discover that real-time clinical data flows only through HL7 v2 interfaces. Adding v2 support after the fact is significant rework, usually surfacing during a live customer integration.
Versions Matter
Treating FHIR as a Single Standard
FHIR R4 is mandated in the U.S.; FHIR R5 is the latest release. Guides like U.S. Core and Canadian Core add profiles per context, so building FHIR without naming version and guide fails conformance.
False Signals
Conflating Interface Engines with FHIR Servers
Interface engines like Mirth Connect surface FHIR-flavored layers over HL7 v2, faking FHIR capability. Validate actual FHIR endpoints through testing, not vendor claims — that data may be incomplete or non-conformant.
Document Exchange
Forgetting C-CDA for Document Workflows
Teams building document exchange on FHIR overlook that C-CDA is the ONC-mandated format for clinical documents. Certified EHRs must generate and receive C-CDA — not FHIR Documents — for care summaries.
Geography
Applying U.S. FHIR Profiles Internationally
FHIR R4 compliant under U.S. Core is not compliant for Canadian or EU deployments. Canadian Core, EU FHIR guides, and other regional profiles carry local terminology and regulatory requirements needing separate work.
Authorization
Underestimating OAuth and SMART on FHIR Complexity
SMART on FHIR defines how clinical apps launch and authenticate against EHR FHIR endpoints. Its OAuth flows, launch contexts, and scope definitions carry complexity developers outside healthcare routinely underestimate.
The Four Standards Every Digital Health Team Needs to Understand
Plain-language definitions — what each standard is and where it belongs in your integration.
HL7 v2 — Real-Time Clinical Messaging
The 1987-era pipe-delimited standard still carrying most real-time hospital data — ADT, labs, and pharmacy orders.
FHIR R4 — Modern REST API for Clinical Data
The 2011 standard mandated for certified U.S. EHRs — REST, JSON, and OAuth 2.0 for on-demand data access.
C-CDA — Structured Clinical Documents
The ONC-mandated format for structured document exchange — discharge summaries, referrals, and care plans.
HL7 v3 / CDA — Know It, Do Not Build New Things on It
The 2000s-era XML standard that never gained broad adoption — still seen in Canadian systems and behind C-CDA.
Building a Healthcare Integration and Need to Get the Standards Right?
Our engineers have shipped across the full HL7 v2, FHIR R4, and C-CDA stack for clinical environments in the U.S. and Canada — from new integration architecture to untangling one built on misunderstood foundations.
Schedule a Free 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 ]
If FHIR is so much better than HL7 v2, why has v2 not been replaced?
HL7 v2 has not been replaced because healthcare infrastructure changes far more slowly than technology. The interface engines, HIS configurations, and vendor libraries built around HL7 v2 represent decades of investment, and replacing them means re-implementation, re-testing, and operational disruption. FHIR is growing fast for new integrations, but digital health teams in 2026 need both standards.
[ 2 ]
Is FHIR the same everywhere in the world?
The FHIR base standard from HL7 International is consistent, but national implementation guides create meaningful differences. U.S. Core defines requirements under ONC regulations; Canadian Core reflects provincial identifier systems and data governance; the EU, Australia, and other regions have their own guides. A FHIR integration built for one national context is not automatically compliant with another, even when both use FHIR R4 as the base.
Global presence
