What is the CMS mandate for FHIR, and does it apply to my organization?

The CMS Interoperability and Patient Access Final Rule (CMS-9115-F) and the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) require payers regulated by CMS (Medicare Advantage, Medicaid, CHIP, and QHP issuers) to implement FHIR R4-based Patient Access APIs, Provider Directory APIs, and Prior Authorization APIs. ONC's 21st Century Cures Act Final Rule requires Certified EHR Technology (CEHRT) to support FHIR R4 APIs. If you are a payer or EHR vendor, FHIR compliance is already legally required.

Can we convert HL7 v2 messages to FHIR automatically?

Partial automation is possible. The HL7 v2-to-FHIR Implementation Guide provides a standardized mapping between common v2 message types (ADT, ORU, ORM) and FHIR resources. Tools like the LinuxForHealth HL7 to FHIR Converter and Azure Health Data Services implement portions of this mapping. However, Z-segment data, site-specific field usage, and local code system mappings require custom transformation logic that cannot be fully automated without human configuration.

What is SMART on FHIR?

SMART on FHIR (Substitutable Medical Applications and Reusable Technologies) is an authorization framework built on OAuth 2.0 that enables third-party applications to securely access FHIR data with patient or provider consent. It is the foundation of the EHR app marketplace ecosystem — Epic App Orchard, Oracle Health App Gallery, and athenahealth's Marketplace all use SMART on FHIR for app authorization. If you are building a healthcare application that needs to access EHR data on behalf of patients or providers, SMART on FHIR is the standard to implement.

Healthcare Integration

FHIR vs HL7: Healthcare Interoperability Standards Explained

FHIR and HL7 v2 are both HL7 standards — but they represent fundamentally different eras of health IT. FHIR is the modern, RESTful, developer-friendly API standard mandated by CMS and ONC for new interoperability requirements. HL7 v2 is the legacy pipe-delimited messaging format that still handles the majority of real-world clinical data exchange. Most health IT environments require both.

Halkwinds Verdict—Build all new integrations on HL7 FHIR R4 — it is the regulatory-mandated standard for patient access APIs, the foundation of modern health app ecosystems, and far easier for developers to implement than HL7 v2. However, HL7 v2 is deeply embedded in hospital ADT feeds, lab interfaces, and EHR-to-EHR messaging and will remain in production for decades. A pragmatic health IT strategy maintains HL7 v2 support for legacy system connectivity while investing in FHIR-native architecture for all new development.

Option A

HL7 FHIR R4

Modern RESTful API standard — mandated for new interoperability

Typical Cost

Open-source FHIR servers free; managed FHIR (Azure, AWS, Google) $0.01–$0.10 per resource; implementation $200K–$1M+

Timeline

3–9 months for a production FHIR API; 6–18 months for full EHR integration program

Pros

RESTful JSON/XML API — familiar to any web developer, no proprietary tooling required

Mandated by CMS and ONC for patient access APIs, prior authorization, and payer-to-payer data exchange

Rich resource model covering 140+ clinical domains with defined relationships and terminology bindings

Enables modern app development patterns: OAuth 2.0 / SMART on FHIR for secure patient and provider app authorization

Strong ecosystem of open-source libraries, validators, and testing tools (HAPI FHIR, Microsoft FHIR server, etc.)

Cons

Limited real-world legacy adoption — most existing hospital systems still exchange data via HL7 v2, not FHIR

Profile proliferation: US Core, Da Vinci, Gravity, and other implementation guides add complexity beyond base FHIR

FHIR R4 implementations vary in conformance — a server claiming FHIR R4 support may not implement all required resources

Terminology binding to SNOMED, LOINC, and RxNorm requires licensing and mapping effort

Operational-scale FHIR servers (bulk data, $everything operations) require significant infrastructure and tuning

Option B

HL7 v2

Legacy pipe-delimited messaging — ubiquitous in existing clinical infrastructure

Typical Cost

Interface engine licensing $10K–$100K/year; integration engine hosting $20K–$200K/year; per-interface development $10K–$50K

Timeline

2–6 weeks per interface; 3–9 months for a full interface engine deployment

Pros

Deployed in virtually every hospital and clinical lab in the United States — guaranteed support for legacy integrations

Mature tooling ecosystem: Mirth Connect, Rhapsody, Iguana, and Azure Health Data Services handle v2 parsing

Optimized for high-volume, real-time event messaging (ADT admits, lab results, pharmacy orders)

Decades of production hardening — edge cases, encoding variants, and Z-segments are well understood by integration engineers

No OAuth or API infrastructure required — direct TCP/IP MLLP connections are operationally simple

Cons

Pipe-delimited, non-hierarchical format is difficult for modern developers to parse and debug

No standard for RESTful queries — HL7 v2 is event-driven push, not queryable pull

Significant variability in field usage across organizations — 'HL7 v2.5.1' means different things at different hospitals

Not compliant with CMS/ONC interoperability mandates for patient access and payer exchange

No native support for modern security patterns (OAuth, SMART) — relies on VPN and network-level controls

Side-by-Side

Detailed Comparison

Dimension	HL7 FHIR R4	HL7 v2	Winner
API Architecture	RESTful HTTP/JSON — standard web API patterns	Pipe-delimited MLLP messages over TCP/IP sockets	HL7 FHIR R4
Developer Accessibility	Any web developer can work with FHIR JSON	Requires specialized HL7 v2 integration engineering expertise	HL7 FHIR R4
Real-World Deployment Coverage	Growing but not yet universal in hospital backends	Installed in virtually every US hospital and clinical lab	HL7 v2
CMS/ONC Regulatory Compliance	Required for patient access, prior auth, and payer exchange APIs	Not compliant with current interoperability mandates	HL7 FHIR R4
Real-Time Event Messaging	Supported via FHIR Subscriptions (R4B/R5) — still maturing	Native push messaging — battle-tested for ADT, lab, and orders	HL7 v2
Security & Authorization Model	OAuth 2.0 / SMART on FHIR — modern app authorization patterns	Network-level VPN/firewall controls; no application-layer auth standard	HL7 FHIR R4
Data Model Consistency	Defined resources with terminology bindings — consistent across conformant servers	Highly variable field usage across organizations — Z-segments are non-standard	HL7 FHIR R4
Tooling & Integration Engine Support	HAPI FHIR, Microsoft/Azure, AWS, Google Cloud Healthcare API	Mirth Connect, Rhapsody, Iguana, Corepoint — mature and widely deployed	Tie
Implementation Complexity	Lower for new greenfield builds; complex for legacy EHR integration	Lower for existing hospital integrations; complex for developers new to HL7	Tie
Long-Term Strategic Trajectory	Regulatory-mandated future — investment will compound	Maintenance mode — no new mandates; legacy support only	HL7 FHIR R4

Decision Framework

When to Choose Each Option

Choose HL7 FHIR R4 when...

You are building a new application, API, or data platform and have control over the integration design
You must comply with CMS Interoperability and Prior Authorization Final Rule or ONC information blocking requirements
You are developing a SMART on FHIR app for the Epic, Cerner, or athenahealth app marketplace
Your engineering team has web API experience but limited HL7 integration background
You are designing a health data platform or analytics pipeline that needs normalized, queryable clinical data

Choose HL7 v2 when...

You are connecting to an existing hospital ADT, lab result, or pharmacy order feed that only exposes HL7 v2
Your integration partner has not yet implemented a FHIR API and HL7 v2 is the only available interface
You are building high-volume, low-latency real-time event processing where FHIR Subscriptions are not yet mature enough
You are maintaining an existing interface engine deployment that already handles v2 translation reliably

Not sure which is right for your project?

If you are building a new application, patient portal, or data platform, implement FHIR R4 as your primary API. If you are integrating with a hospital's existing ADT, ORM, or ORU feeds, budget for HL7 v2 interface engines (Mirth Connect, Rhapsody, Azure Health Data Services). For regulatory compliance under CMS Interoperability and Prior Authorization rules, FHIR R4 is non-negotiable.

Related Resources

Related Services

Industries We Serve

HealthcareClinical & health-tech solutions

Our Platforms

Insights & Resources

Common Questions

Frequently Asked Questions

Yes — both are standards published by Health Level Seven International (HL7). HL7 v2 has been in use since 1987 and is maintained in its current form. FHIR (Fast Healthcare Interoperability Resources) was published as a normative standard in 2019. Despite sharing the HL7 name, they are architecturally unrelated — FHIR does not extend or replace v2, and v2 messages cannot be automatically converted to FHIR resources without mapping and transformation logic.

Work With Halkwinds

Ready to Make the Right Decision?

A 30-minute scoping call is enough to recommend the right approach for your specific context, budget, and timeline.

Browse All Comparisons