Overview
HL7 v2 and FHIR are two healthcare interoperability standards from HL7 International representing two different paradigms for healthcare data exchange. Both remain in active use, and many healthcare organizations operate hybrid environments combining both. Understanding their differences and appropriate use cases is essential for interoperability strategy.
HL7 v2 history and characteristics: HL7 v2.x dates to 1987 and became the dominant clinical messaging standard in US healthcare. Messages are pipe-delimited ASCII text with specific message types (ADT for admission-discharge-transfer, ORM for orders, ORU for results, MDM for documents, SIU for scheduling, etc.). Each message contains segments (PID for patient identification, PV1 for patient visit, OBX for observation), and each segment contains fields. The format is compact, efficient, and widely supported across legacy and current systems. HL7 v2 is typically transported over MLLP (Minimal Lower Layer Protocol) or increasingly over HTTPS; v2 interfaces are nearly universal in EHRs and clinical systems.
FHIR history and characteristics: FHIR (Fast Healthcare Interoperability Resources) was introduced by HL7 in 2014 as a modern alternative to HL7 v2 and v3 (which saw limited adoption). FHIR uses modern web standards — REST, HTTP, JSON/XML, OAuth — familiar to software developers outside healthcare. Clinical data is organized into structured resources (Patient, Observation, MedicationRequest, Encounter, etc.) rather than messages. FHIR APIs expose resources at REST endpoints; clients retrieve specific resources or subsets through search. FHIR R4 (2019) is the current normative version with R5 recently published.
Paradigm differences: HL7 v2 is message-centric and event-driven. Systems send messages when events occur (patient admitted → ADT message sent). Messages flow one-way from source to destination; receiving systems process messages and update their data. FHIR is resource-centric and query-driven. Systems maintain FHIR-accessible resources; consumers query for specific data when needed. FHIR supports both pull (query for data) and push (Subscription notifications) patterns.
Use case fit: HL7 v2 is strong for real-time clinical messaging within an integrated delivery network — EHR to ancillary systems (lab, radiology, pharmacy), order routing, result delivery, ADT distribution. FHIR is strong for modern API consumption, mobile and web apps, patient-mediated exchange, population-level analytics (Bulk Data), and cross-organizational exchange. Many organizations use both: v2 for operational clinical messaging, FHIR for modern apps and regulatory interop (USCDI, patient access APIs).
Advantages of FHIR over v2: Easier implementation (modern tooling, web developers can build FHIR apps), richer data model (structured resources with clear semantics vs. v2's flat segments), modern API patterns (query, search, pagination, conditional access), native web interop (JSON, OAuth, SMART on FHIR), and regulatory alignment (USCDI, CMS APIs, ONC certification increasingly require FHIR).
Advantages of v2 over FHIR: Ubiquity (nearly universal support in existing healthcare IT), compact format (efficient for high-volume message traffic), mature ecosystem (decades of implementation experience, interface engines, trouble-shooting patterns), and performance for specific use cases (event-driven messaging patterns).
Transition dynamics: Healthcare is in a multi-decade transition from v2-dominant to FHIR-prominent interoperability. New regulatory requirements (USCDI, CMS APIs, ONC certification) are FHIR-based. New applications (mobile, patient apps, AI) prefer FHIR. Core clinical messaging (orders, results, ADT) remains largely v2 for operational reasons. Interface engines (Rhapsody, Mirth, InterSystems) increasingly support both, enabling bidirectional translation.
For RCM operations, both standards appear. Claims use X12 (not HL7) but related clinical data often flows via v2 or FHIR. Charge capture may use v2 from clinical systems to billing. Modern RCM applications (patient portals, estimate tools, patient payment apps) typically use FHIR. Integration strategy should support both with appropriate use case mapping.
Future trajectory: FHIR will progressively expand at v2's expense. Regulatory drivers (USCDI, CMS rules, 21st Century Cures Act) and technology drivers (apps, AI, cloud) favor FHIR. v2 will persist indefinitely for core clinical messaging given installed base and operational stability. Mature interoperability strategy embraces both while investing in FHIR for new development.
Industry benchmark
HL7 v2: widely deployed for clinical messaging since 1987. FHIR: modern API standard since 2014, expanding. Both remain in active use. Regulatory direction: FHIR-centric.
Worked example
A hospital IT environment uses HL7 v2 for core clinical messaging: EHR sends ADT messages to lab, radiology, pharmacy, and billing systems; lab sends ORU results back to EHR; radiology sends ORU reports. Simultaneously, the hospital exposes FHIR APIs for its patient portal, mobile app, regulatory patient access (CMS Patient Access API), and affiliated clinician's SMART on FHIR apps. Interface engines translate between formats where needed. Strategic investment favors FHIR for new development; v2 maintains operational backbone.
Frequently asked questions — HL7 v2 vs FHIR
Which standard should new systems use?
FHIR for most new interoperability development — aligns with regulatory direction, modern tooling, and rich data model. HL7 v2 remains appropriate for high-volume operational clinical messaging within established clinical environments.
Will HL7 v2 go away?
Not anytime soon. v2 has massive installed base in clinical systems and operational messaging. FHIR will expand at v2's expense over many years, but v2 will persist indefinitely for specific use cases.
Do organizations need to pick one?
No. Most organizations operate hybrid environments with both standards for different use cases. Interface engines translate between formats as needed.
Disclaimer
This glossary entry is operational reference for revenue-cycle and medical-billing professionals. It is not legal, clinical, or contractual advice. Industry benchmarks cite named public sources where available; always verify against the current guidance from the authority body before relying on a number in a contract, policy, or compliance filing.