HL7 V2, V3, and FHIR: Definitions and Scope

Healthcare interoperability has emerged as a strategic objective for health institutions seeking to improve patient outcomes. Legacy messaging standards, such as HL7 Version 2 and Version 3, have supported clinical data interchange for decades; however, their limitations in semantic consistency and web integration hinder the growth of digital ecosystems. 

Fast Healthcare Interoperability Resources (FHIR), which uses RESTful APIs, JSON, and SMART on FHIR frameworks, is increasingly emerging as the architecture for data transfer. 

The blog provides a full comparison between HL7 V2/V3 and FHIR, including current regulatory obligations, adoption trends, and implementation best practices as of 2025.

HL7 Version 2.x (HL7 V2)

The classic messaging standard used for exchanging clinical and administrative data. HL7 V2 messages are pipe-delimited text segments. It is extremely widespread, used in >90% of U.S. hospitals, because it is mature, backward-compatible, and supports real-time workflows. 

However, V2 is rigid and “archaic” by modern IT standards: it has limited semantic consistency (each system may interpret fields differently) and no native web/API support.

HL7 Version 3 (HL7 V3, CDA)

A model-driven standard developed from 1995 onward, based on a common Reference Information Model. V3 aimed to formalize all healthcare data definitions so that messages and documents share a consistent meaning. Its primary implementation has been the Clinical Document Architecture, an XML-based document standard. 

V3/CDA provides strong semantic rigor, but it is complex and heavyweight. It has seen limited adoption and is not backward-compatible with V2. Many of its goals are now met by FHIR.

FHIR (Fast Healthcare Interoperability Resources)

A modern HL7 standard (introduced ~2011) designed for ease of use and web/mobile integration. FHIR defines healthcare “resources” (e.g., Patient, Observation, Medication) and a RESTful API for CRUD operations. It uses JSON (or XML) payloads and standard HTTP methods. 

FHIR leverages current web technologies (HTTPS/REST, OAuth2, HTML/CSS, JSON) to ensure interoperability across different systems. It is specifically intended to be easier to implement, more extensible, and more developer-friendly than HL7 V2 or V3. In practice, FHIR has become the centerpiece of U.S. interoperability mandates (e.g., ONC’s API rules) and is rapidly proliferating in health IT.

Related: The Ultimate Guide to Transforming HL7 CDA to FHIR Using Visual Tools

Adoption: HL7 and FHIR in the U.S. and Globally

U.S. (Hospitals and Health Systems)

HL7 V2 remains the workhorse of hospital data exchange, with an estimated >90% penetration in U.S. hospitals. Every hospital information system still heavily relies on V2 messaging for admitting/discharging patients, lab results, orders, etc. 

At the same time, FHIR adoption has accelerated under federal mandates. 

• For example, by 2022, about 2/3 of U.S. hospitals had implemented at least one FHIR-based API for patient access to records. 
• The ONC/CMS rules (see below) now require certified EHRs and payers to support FHIR US Core APIs, so that number is expected to rise toward nearly universal FHIR API availability by 2025.

International

Many countries are also embracing FHIR. 

• The UK’s NHS is rolling out a FHIR UK Core framework to enable cross-border EHR access, with unified FHIR profiles for England, Scotland, Wales, and Northern Ireland. 
• Australia’s My Health Record program is undergoing modernization to add FHIR-based interoperability: in 2024, the Digital Health Agency tendered major contracts to build a FHIR API platform for My Health Record. 
• Canada and other nations (via Canada Health Infoway and HL7 affiliates) are likewise building FHIR implementation guides and pilot projects. 

In short, FHIR has moved well beyond the pilot phase: it is embedded in national strategies from the NHS to My Health Record, complementing or replacing legacy HL7 standards.

Regulatory Updates (CMS, ONC, TEFCA)

1. ONC Cures Act Final Rule (2020)

Implemented the 21st Century Cures Act. It mandated standardized FHIR APIs for patient access: certified EHRs must offer FHIR “US Core” APIs exposing at least USCDI v1 data (demographics, meds, allergies, etc). This rule also prohibits information blocking. CMS simultaneously adopted these ONC standards for Medicare/Medicaid payers.

2. ONC HTI-1 Final Rule (2024)

In January 2024, ONC issued a new Certification Program rule that updates the earlier requirements. It adopts FHIR US Core IG version 6.1.0 (aligned to USCDI v3) for APIs. 

In practice, this means by 2025, certified health IT must support FHIR APIs exposing the expanded USCDI v3 data elements, and must implement the new SMART App Launch v2.0 framework for OAuth-based apps. In short, ONC now requires FHIR US Core 6.x and SMART 2.0 support by 2025.

3. CMS Interoperability & Patient Access Rule (CMS-9115-F, 2020)

Required Medicare Advantage, Medicaid, and many ACA plans to publish payer APIs (using FHIR US Core) for member data access. It adopted the ONC FHIR US Core standards so that providers and patients can query payers via FHIR. The rule’s intent was “liberating” patient data (MA, Medicaid, CHIP) and encouraging apps and mobile access.

4. CMS Payer/Provider Exchange & Prior Auth Rule (CMS-0057-F, 2024)

Released Jan 2024, this rule extends interoperability to payer–provider data exchange and prior authorizations. It enhances the 2020 CMS rules and adds new requirements for payer APIs (e.g. prior auth, formulary, network data) using FHIR. 

Affected payers will have API mandates phased in by 2026–2027. Notably, CMS clarified that providers/payers may use FHIR-based prior auth instead of the older X12 278 format. In sum, CMS now expects comprehensive FHIR APIs across the healthcare ecosystem.

5. TEFCA (Trusted Exchange Framework & Common Agreement)

A federal initiative to link health information networks nationwide. ONC and the Sequoia Project (RCE) released an updated TEFCA roadmap in 2024. Early stages focus on established exchange (e.g., C-CDA) but explicitly plan FHIR networking in the next phase. 

The Sequoia “FHIR Roadmap” calls for piloting a QHIN-to-QHIN FHIR exchange in 2025. In other words, TEFCA’s nationwide “network of networks” will eventually use FHIR for cross-network queries, but that capability is still being phased in.

Technical Comparison: HL7 vs FHIR

This highlights why FHIR differs: it is built as a modern web service (REST, JSON, OAuth) to address use cases (mobile apps, patient-facing portals, etc.) that HL7 V2/V3 were not designed for.

Related: HL7 FHIR vs. Traditional Data Standards: Why Interoperability Matters

Benefits and Limitations of HL7 Versions and FHIR (2025)

1. HL7 V2. x

• Benefits: Supports real-time hospital workflows; backward-compatible (so old systems still work).
• Limitations: Low semantic clarity (often free-text); rigid formatting and a lack of standard data models; no native support for modern APIs or mobile apps. 
• Mapping V2 fields to newer standards is difficult, and hospitals must maintain custom interfaces.

2. HL7 V3/CDA

• Benefits: Strong underlying model (RIM) ensures consistent definitions; widely used for clinical document exchange. 
• Limitations: Very complex (heavy XML); slow to develop and implement; only subsets (like CDA) gained traction. 
• Many interoperability needs (especially granular queries) are better served by FHIR now.

3. FHIR

• Benefits: Modern Web Standards – uses RESTful HTTP, JSON, OAuth2/SMART, etc., making it easy to integrate with today’s systems. 
• It has fine-grained, standardized “resources” so apps can query exactly the data they need. 
• This supports developer-driven innovation (e.g., SMART apps, patient apps) and meets regulatory mandates. FHIR also improves provenance and data freshness via APIs. 
• Limitations: FHIR is still maturing. Resources and implementation guides evolve (e.g., US Core IG versions), so consistent deployment requires coordination. 
• Not all legacy data maps neatly to existing resources, and coverage of some data domains is incomplete. Implementation quality varies by vendor. 
• Security and privacy must be carefully managed with OAuth and consent. 
• As one recent review notes, FHIR’s changing content, legal/safety concerns, and technical setup (FHIR server infrastructure) are ongoing challenges.

Implementation Challenges for FHIR at Scale

1. Integration with Legacy Systems

Most hospitals still run older EHRs built for HL7 V2. Bridging these “patchwork” infrastructures to FHIR often requires middleware or dual support. Mapping V2 message fields to FHIR resources is labor-intensive and can introduce errors.

2. Data Standardization

True interoperability needs common code sets (SNOMED, LOINC, etc.) and consistent data models. In practice, different organizations use varied coding and local extensions, complicating FHIR data harmonization. Rolling out US Core (or other profiles) uniformly is a big effort.

3. Scalability & Performance

Enterprise-scale FHIR deployments must handle high volumes (real-time queries and bulk data). Ensuring the FHIR server and API endpoints remain responsive under heavy load (e.g., thousands of patient lookups or population queries) is non-trivial. Bulk FHIR export (Flat FHIR) for analytics or public health is still emerging.

4. Vendor and Resource Constraints

EHR vendors are updating products to meet regulatory deadlines, but support levels vary. Larger systems may build robust APIs; smaller vendors may lag. Implementers often must wait for vendor upgrades or invest in custom FHIR solutions. Recruiting skilled staff (FHIR architects, API developers) and funding these projects is a challenge.

5. Evolving Standards and Governance

There are many FHIR implementation guides. Organizations must choose the right IGs and stay current with versions (e.g., ONC’s US Core 6.1.0 requirement). Without strong governance, different systems may use conflicting profiles, undermining interoperability.

6. Security and Policy

Introducing FHIR APIs changes the security model (e.g. OAuth token management, consent tracking). Institutions must ensure HIPAA-compliant configurations. Devising policies for API usage (who can access which data when) adds complexity.

7. Stakeholder Buy-In

Finally, culture and process matter. Moving to API-driven workflows requires training and change management. Some providers and IT leaders resist disrupting long-established interfaces. 

To address these gaps, HL7 and industry groups have launched initiatives: Da Vinci’s Trebuchet pilot program and the FHIR at Scale Taskforce (FAST) are actively identifying and solving common barriers.

Related: How HL7 FHIR is Embracing Advanced PHI De-Identification Solutions

Use Cases and Ecosystem Trends

1. Payer–Provider Data Exchange

FHIR now underpins new workflows between health plans and providers. For example, the HL7 Da Vinci Payer Data Exchange (PDex) IG lets providers query payer systems for member data (benefit plans, formularies, claims status) via FHIR. 

Da Vinci also covers FHIR-based prior authorization, quality data exchange, etc. On the patient side, the CARIN Blue Button IG uses FHIR to let consumers retrieve their claims/EOB data from payers. These initiatives dovetail with CMS rules requiring payers to open up this data through standardized FHIR APIs.

2. Patient Access & Mobile Apps

Federal rules now mandate patient-facing FHIR APIs. As a result, many hospitals and health systems offer FHIR-based patient portals and third-party apps. By 2022, roughly 66% of hospitals allowed patients to use FHIR APIs to access their records through apps, up 12 points from 2021. Mobile health apps use these FHIR APIs to fetch clinical data. 

Similarly, payers must support mobile apps via FHIR (e.g., Blue Button apps under CMS rules). In short, smartphones and tablets are now integrated into the health data ecosystem through FHIR.

3. SMART Apps and Clinical Workflows

The SMART on FHIR framework is driving an ecosystem of reusable apps (for patients and clinicians). Hospitals can “plug in” SMART apps for decision support, telehealth, appointment scheduling, etc., all standardized on FHIR and OAuth. 

This trend makes “app-store”-style innovation possible in healthcare IT. For example, clinicians can launch FHIR apps inside the EHR (via SMART) to perform specialized tasks without leaving the chart.

4. Population/Public Health

FHIR is also emerging in analytics and reporting. Bulk Data Export APIs (Flat FHIR) are being used for quality measurement, research registries, and public health reporting. 

Government programs (CDC Electronic Case Reporting, HRSA UDS+) are starting to use FHIR-based data submissions. This means clinical data from many providers can flow to public health systems more efficiently.

CapMinds HL7 FHIR Service for Healthcare Practice

CapMinds offers the best all-in-one health interoperability solution for healthcare practices. Our HL7 FHIR service will understand your clinical needs and requirements to cater to our solution.

We have years of experience in this field, faced many challenges, and tackled them with ease.

Why can CapMinds be your Go-to Interoperability Solution?

• We are experienced professionals with years of experience in the field.
• Our technical team is an expert that will analyze your healthcare practice thoroughly to tailor the Interoperability solution.
• We prioritize safety, security, encryption, and authentication to protect your healthcare practice’s patients’ data.
• Our comprehensive solution ensures seamless interoperability, adhering to industry standards and using standard protocols.
• We offer comprehensive training sessions to healthcare staff.
• Our affordable health interoperability solution benefits healthcare practices at all levels.

If you are searching for the best interoperability service for your practice, CapMinds is your choice. We can assist you by navigating all potential challenges and ensuring seamless health data exchange.

Reach out to CapMinds Health Data Exchange Solutions for your Healthcare Practice.

Contact Us