HL7 Integration in US Healthcare: Meeting ONC and CMS Interoperability Requirements

The United States healthcare system has undergone a regulatory transformation over the past several years. With the passage of landmark legislation and the subsequent publication of federal rules, healthcare providers, payers, and health IT vendors are now legally obligated to support interoperability in ways they never were before. At the heart of this transformation is HL7 FHIR — and understanding the regulatory landscape is essential for any organization developing an HL7 integration strategy.

This guide breaks down the key US interoperability requirements, what they mandate, who they apply to, and what your organization must do to comply.

US Interoperability Landscape

For decades, healthcare data in the US was locked in proprietary systems with no standardized way to share it. Patients couldn't easily access their own records. Providers couldn't see complete patient histories. Payers couldn't connect with providers efficiently. The result was wasted money, medical errors, and frustrated patients.

Beginning in the early 2010s with the HITECH Act and Meaningful Use programs, the federal government began pushing healthcare organizations toward electronic health records. But it wasn't until the 21st Century Cures Act of 2016 and the subsequent 2020 final rules from ONC and CMS that interoperability became a true mandate with real enforcement teeth.

Today, any organization that participates in federal healthcare programs — Medicare, Medicaid, or operates a certified EHR — must meet specific interoperability standards. HL7 integration is no longer optional; it is a compliance requirement.

21st Century Cures Act

The 21st Century Cures Act, signed into law in December 2016, is one of the most consequential pieces of health IT legislation in US history. Among its many provisions, the Cures Act specifically addresses interoperability and information blocking.

Key provisions relevant to HL7 integration include:

• Information Blocking Prohibition — Healthcare providers, health IT developers, and health information networks are prohibited from taking actions that interfere with the access, exchange, or use of electronic health information. Violations can result in civil monetary penalties up to $1 million per violation.
• Standardized APIs — Health IT developers must provide standardized, openly published APIs (based on FHIR) to enable patient access to their health information without special effort.
• Patient Access Requirements — Patients have the right to access their electronic health information (EHI) through third-party applications of their choosing.
• ONC Certification Requirements — EHR products seeking ONC certification must meet updated interoperability criteria, including FHIR R4 API support.

The Cures Act set the legal foundation; the ONC and CMS rules published in 2020 provided the operational requirements.

ONC Final Rule (21st Century Cures Act Final Rule)

The ONC 21st Century Cures Act Final Rule (published May 2020) implements the interoperability provisions of the Cures Act. It applies primarily to health IT developers of certified health IT, health information exchanges (HIEs), and health information networks (HINs).

Core requirements of the ONC Final Rule include:

• FHIR R4 API Requirement — Certified EHR technology must support a standardized FHIR R4-based API for patient data access. This is the US Core Data for Interoperability (USCDI) standard.
• Information Blocking Exceptions — The rule defines eight specific exceptions to the information blocking prohibition (privacy, security, preventing harm, promoting interoperability, etc.).
• USCDI v1 Adoption — All certified systems must support the US Core Data for Interoperability (USCDI), a standardized set of data classes and elements required for interoperability.
• Conditions and Maintenance of Certification — New ongoing obligations for health IT developers to maintain their certifications, including assurance testing, real-world testing, and enhanced surveillance.

For organizations building or procuring EHR technology, the ONC Final Rule means your system must support FHIR R4 APIs and the USCDI data set. Traditional HL7 v2 interfaces alone are no longer sufficient for certification.

CMS Interoperability and Patient Access Final Rule

The CMS Interoperability and Patient Access Final Rule (also published in 2020, with phased implementation) applies to a different audience: payers — specifically Medicare Advantage, Medicaid, CHIP, and Qualified Health Plan issuers on the federal exchanges.

Key CMS requirements include:

• Patient Access API — Payers must implement and maintain a FHIR R4-based Patient Access API that allows members to access their claims data, clinical data, and formulary information through third-party apps. This API must use HL7 FHIR R4 and the Da Vinci implementation guides.
• Provider Directory API — Payers must publish a publicly accessible FHIR-based Provider Directory API so patients, providers, and applications can find in-network providers.
• Payer-to-Payer Data Exchange — When a member switches payers, the new payer can request up to five years of clinical data from the previous payer. This uses the FHIR-based Da Vinci Payer Data Exchange (PDex) implementation guide.
• Prior Authorization API — A subsequent CMS rule (CMS-0057-F, effective January 2026) requires payers to implement FHIR-based prior authorization APIs, dramatically reducing administrative burden for providers.

For payers, the CMS rules represent a major FHIR implementation project. Most payers have needed to build or procure FHIR servers, implement multiple Da Vinci IGs, and integrate those FHIR endpoints with their existing claims and clinical data systems — which typically still use HL7 v2 internally.

What Providers Must Do

While the ONC rule primarily targets health IT developers and the CMS rule targets payers, healthcare providers are not exempt from interoperability obligations. Here is what providers need to address:

• Comply with Information Blocking Rules — Providers (as defined by the Cures Act) must not take actions that constitute information blocking. This means having policies and workflows that support timely patient data access.
• Enable Patient API Access — If you use a certified EHR, ensure the FHIR Patient Access API is enabled and your patients can use third-party apps to access their data.
• Support Electronic Prior Authorization — With the CMS prior authorization rule now in effect, providers need their EHR and practice management systems to support the FHIR-based prior authorization workflow with participating payers.
• Connect to Health Information Exchanges — Many states require or incentivize provider participation in HIE networks for care coordination and public health reporting.
• Maintain HL7 v2 Interfaces — Despite the FHIR mandates, HL7 v2 remains essential for internal clinical workflows: lab orders and results, ADT notifications, radiology orders, and more. Providers need both v2 and FHIR capabilities.

The practical reality for most provider organizations is a hybrid HL7 v2 + FHIR architecture: existing internal workflows continue over HL7 v2 messaging, while new patient-facing and payer-facing integrations use FHIR R4 APIs. An experienced EHR integration partner can help you navigate this complexity.

How Taction Software Helps US Healthcare Organizations

At Taction Software, we specialize in helping US healthcare organizations meet their interoperability obligations while building efficient, scalable integration architectures. Our services span the full spectrum of US compliance requirements:

• FHIR R4 API Development — We build FHIR servers and client applications that comply with USCDI, US Core Implementation Guide, and Da Vinci profiles required by ONC and CMS rules.
• HL7 v2 Interface Development — Our engineers have deep expertise in HL7 v2 integration for ADT, ORU, ORM, SIU, and other clinical message types.
• Mirth Connect Implementation — We design and build Mirth Connect integration engines that handle both v2 and FHIR traffic, with robust routing, transformation, and error handling.
• Prior Authorization API Integration — We implement the CMS prior authorization FHIR APIs on both the payer and provider side, using the Da Vinci Coverage Requirements Discovery (CRD) and Documentation Templates and Rules (DTR) guides.
• HIPAA-Compliant Architecture — All our integrations are designed with HIPAA security and privacy requirements built in from day one.

Whether you are a hospital system, a health plan, a digital health startup, or an EHR vendor seeking ONC certification, our team has the regulatory knowledge and technical depth to deliver compliant, production-grade interoperability solutions. Contact us today for a free consultation.