HL7 (Health Level Seven) is a standards organization producing healthcare interoperability standards since 1987 — not a single standard. Saying you need an "HL7 integration" without naming which HL7 standard is like specifying a database without saying relational, document, or graph.
First published in 1987, HL7 v2 is a pipe-delimited text format that still carries most real-time clinical messages in North American hospitals — ADT events, lab results, pharmacy orders, radiology reports. Every hospital runs an interface engine managing this traffic.
Developed in the late 1990s as an XML-based replacement for v2, HL7 v3 never reached broad adoption. It remains relevant in Canadian provincial systems and as the basis for C-CDA, the structured clinical document format mandated under U.S. ONC regulations.
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.
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.
Digital health teams building for hospitals in 2026 will encounter all three: HL7 v2 for real-time event data, FHIR R4 APIs for certified EHR access, and C-CDA for structured document exchange. Knowing which applies where is the foundation of sound integration architecture.
A practical decision framework for choosing between HL7 v2, FHIR, and C-CDA based on use case, integration target, and data requirements.
ADT events, lab results, radiology reports, pharmacy orders, and scheduling all flow through hospital interface engines as HL7 v2. Where data lives in the v2 layer, connecting there is usually the most reliable approach — whatever FHIR endpoint the EHR also exposes.
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.
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.
A digital health 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 customer implementations.
Six confusion patterns that appear repeatedly in digital health development — and how each translates directly into expensive integration rework.
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.
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.
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.
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.
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.
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.
Plain language definitions — what each standard is, where it came from, and where it belongs in your integration architecture.
The 1987-era pipe-delimited standard still carrying most real-time clinical data in North American hospitals — ADT events, lab results, radiology reports, pharmacy orders. Digital health teams cannot avoid HL7 v2 in hospitals; the only question is whether they are prepared for it.
The FHIR standard from 2011, now mandated for all certified U.S. EHR systems under ONC regulations. Resource-based and REST-driven, using JSON and OAuth 2.0 — the right standard for on-demand queries, patient-facing data access, and EHR write-back.
The ONC-mandated format for structured clinical document exchange in the U.S. — care summaries, discharge summaries, referral notes, care plans. Every certified EHR must generate and receive C-CDA; it is not interchangeable with FHIR or HL7 v2.
The 2000s-era XML-based standard that never reached broad adoption. Still relevant in Canadian provincial systems and as the technical basis for C-CDA. Encounter HL7 v3 in a new 2026 project and you are almost certainly working with Canadian provincial data or C-CDA documents.
Whether you are designing a new integration architecture, scoping the HL7 v2 and FHIR R4 capability your product needs for the hospital market, or untangling an integration built on misunderstood foundations, our engineers have shipped across the full HL7 v2, FHIR R4, and C-CDA stack for clinical environments in the U.S. and Canada.
Schedule a Free Consultation
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
HL7 v2 has not been replaced because healthcare infrastructure changes far more slowly than technology innovation. The interface engines, HIS configurations, vendor libraries, and processes built around HL7 v2 represent decades of investment, and replacing them means re-implementation, re-testing, and operational disruption that health systems weigh carefully against the benefit. FHIR is growing fast for new integrations, but digital health teams in 2026 need both standards.
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.
