CMS Interoperability Rules in 2026: What You Actually Need to Do (Not What Vendors Tell You)

If you're a CTO or compliance officer in healthtech, your inbox is full of vendor emails warning you about CMS interoperability deadlines. Most of them are trying to sell you something. Some of them are actually misleading you about what applies to your organization.

CMS has been publishing interoperability rules for years. The 21st Century Cures Act kicked off this wave in 2016. ONC finalized HTI-1 in 2024. CMS-0057-F dropped its hammer on payers. TEFCA went from concept to hundreds of millions of records exchanged. And through all of it, vendor marketing has consistently conflated "this rule exists" with "you must buy our product immediately."

This guide cuts through the noise. We'll cover what rules actually matter in 2026, what the real deadlines are, who they apply to, and what you concretely need to build or buy. No fear marketing. No vague warnings. Just the compliance landscape as it stands today.

The Rules That Matter Now

Three regulatory frameworks are driving interoperability requirements in 2026. If you understand these three, you understand the compliance landscape:

ONC HTI-1 (Health Technology Implementation)

This is ONC's final rule updating certification criteria for health IT. The headline: USCDI v3 data classes are required for certified health IT as of January 2026. If your product is ONC-certified (or depends on ONC-certified systems), this is mandatory. Should your team startup that isn't seeking certification, it still matters because the EHRs you integrate with are now required to expose this data.

CMS-0057-F (Prior Authorization Final Rule)

This rule targets payers — health plans, Medicare Advantage organizations, Medicaid managed care plans, and QHP issuers on the exchanges. Payers must implement FHIR-based prior authorization APIs. The compliance date was January 1, 2026. If you build prior authorization software, your entire technical architecture is affected.

CMS Interoperability and Patient Access

The broader CMS interoperability framework mandates three API categories for impacted payers: Patient Access API (FHIR R4-based), Provider Directory API, and Payer-to-Payer data exchange. These aren't new concepts, but enforcement has teeth now. Payers that don't comply risk sanctions and exclusion from federal programs.

Notice a pattern? Two of the three target payers and certified health IT. If you're a startup that builds on top of these systems, you're not directly regulated — but the systems you depend on are changing underneath you. Ignore these changes at your own risk.

USCDI v3 — What's New and What to Build

The United States Core Data for Interoperability version 3 is the data standard that underpins HTI-1 compliance. If USCDI v1 was "the basics" (patient demographics, allergies, medications, lab results), USCDI v3 expands the required data set significantly.

New data classes in USCDI v3:

• Health Insurance Information — Coverage details, plan identifiers, payer information. This is huge for revenue cycle and eligibility workflows.
• Clinical Tests — Non-lab clinical test results (e.g., pulmonary function tests, cardiac stress tests). Previously optional, now required.
• Diagnostic Imaging — Imaging reports and associated metadata. Not the images themselves (that's still DICOM territory), but the structured reports.
• Care Team Members — Structured data about who's involved in a patient's care, including roles and contact information.

All of these are exposed via FHIR US Core profiles. The implementation guides are published, the profiles are defined, and the validation tools exist.

What this means for you:

When teams certified EHR or health IT vendor: This is mandatory. Your FHIR API must serve these data classes using the correct US Core profiles. Your certification depends on it. The ONC-ACB (Authorized Certification Body) will test for this.

If you're a startup building on top of EHRs: Your data sources will now expose this data. Plan your FHIR queries accordingly. If you've been screen-scraping insurance information or manually collecting care team data, there's now a standardized API for it. Update your integration layer.

In cases where you health system IT team: Work with your EHR vendor to confirm their USCDI v3 timeline. Most major vendors (Epic, Oracle Health/Cerner, MEDITECH) have shipped updates, but you may need to enable new FHIR resources or update your SMART on FHIR app configurations.

Prior Authorization API (CMS-0057-F)

This is the rule that sent the prior authorization industry scrambling. And for good reason — it fundamentally changes how prior auth works at a technical level.

What payers must implement (as of January 2026):

• FHIR Prior Authorization API (Da Vinci PAS IG) — A FHIR-based API for submitting, querying, and updating prior authorization requests. Uses the Claim resource with the $submit operation. Real-time responses required for most request types.
• Document Requirement Lookup (Da Vinci CRD) — CDS Hooks-based service that tells providers what documentation is needed before they submit the prior auth. Integrated into the EHR workflow via SMART on FHIR.
• Documentation Templates and Rules (Da Vinci DTR) — FHIR Questionnaire resources that define exactly what information the payer needs. Providers fill these out within their EHR. No more guessing what the payer wants.

What this means for startups:

If you build prior authorization software, your architecture must be FHIR-native. The days of building prior auth on fax, X12 278, or proprietary payer portals are numbered. CMS-0057-F doesn't eliminate X12 overnight, but it creates a parallel FHIR path that payers are required to support.

Here's what your tech stack needs:

• FHIR R4 client capable of the $submit operation on Claim resources
• CDS Hooks client for consuming CRD responses
• FHIR Questionnaire renderer for DTR workflows
• SMART on FHIR authentication (you're authenticating against payer FHIR servers now, not just EHRs)
• Subscription support for async prior auth status updates

If you're a payer: you already know this. Should your team provider organization: push your payers on timeline and test connectivity. When teams startup: this is a massive market opportunity, but only if your technical foundation is right.

TEFCA — The National Network

The Trusted Exchange Framework and Common Agreement (TEFCA) has gone from bureaucratic concept to operational reality faster than most people expected.

The numbers tell the story:

As of February 2026, approximately 500 million records have been exchanged through TEFCA — up from roughly 10 million in January 2025. That's 50x growth in thirteen months. The network is real, and it's scaling.

How TEFCA works:

TEFCA operates through Qualified Health Information Networks (QHINs) — organizations that have been designated by the Sequoia Project (operating as the Recognized Coordinating Entity) to facilitate nationwide health information exchange. QHINs connect to each other, creating a network-of-networks model. If you're connected to one QHIN, you can theoretically exchange data with organizations connected to any other QHIN.

Current QHINs include eHealth Exchange, CommonWell Health Alliance, Epic Nexus, KONZA National Network, MedAllies, and others. The list is growing.

The FHIR mandate:

TEFCA requires FHIR alignment by July 2026. This means QHINs and their participants must support FHIR-based query and response in addition to (or replacing) existing IHE-based document exchange. This is a big deal — it means TEFCA isn't just a document exchange network anymore; it's becoming a FHIR query network.

What to do:

If your organization needs cross-organizational data exchange (and most health IT organizations do), evaluate two paths:

• TEFCA participation — Connect through a QHIN. Best for broad, nationwide reach. You get access to the entire network through a single connection. Cost and complexity vary by QHIN.
• Direct connections — Point-to-point FHIR integrations with specific organizations. Best for deep, bilateral integrations where you need real-time data and tight coupling. More control, but doesn't scale to hundreds of partners.

For most startups, the answer is both. Use TEFCA for broad reach and direct FHIR connections for your core integration partners.

Information Blocking — What You Can't Do

The 21st Century Cures Act's anti-information blocking provisions are fully in effect, and ONC's enforcement arm (the Office of the Inspector General) is actively investigating complaints.

The rule is simple in principle:

You cannot restrict access to Electronic Health Information (EHI) through:

• Technical barriers — Intentionally designing interfaces that limit data access, using proprietary formats when standards exist, or failing to implement required APIs.
• Unreasonable fees — Charging excessive prices for API access, data export, or integration support that effectively blocks data exchange.
• Restrictive licensing — Terms of service or contracts that prevent downstream use of health data that patients or providers have a right to access.

Exceptions exist but are narrow:

ONC defined eight exceptions (preventing harm, privacy, security, infeasibility, health IT performance, content and manner, fees, and licensing). But these are narrowly scoped. "We didn't get around to building the API" is not an exception. "Our business model depends on data lock-in" is not an exception. "It's technically possible but we chose not to" is definitely not an exception.

The penalty:

Up to $1 million per violation. OIG has the authority to investigate and impose civil monetary penalties. They've received thousands of complaints and are actively triaging them. The first enforcement actions have begun.

Notably, what for you:

If you build health IT, audit your product for anything that could be construed as information blocking. Common pitfalls: requiring paid API tiers for basic data access, using non-standard data formats, restricting data export, or making it unreasonably difficult to switch vendors. Fix these before someone files a complaint.

What Vendors Won't Tell You

Here's the part that vendor webinars skip: not everything requires immediate action from every organization.

Rules that apply primarily to payers and certified EHRs:

• CMS-0057-F prior auth APIs: mandatory for payers, not for providers or startups (directly)
• USCDI v3 certification: mandatory for ONC-certified health IT, not for non-certified software
• Patient Access API: mandatory for CMS-regulated payers, not for providers

But here's the catch:

If you integrate with these systems, their compliance changes affect your data flows. When Epic updates their FHIR API to support USCDI v3, your integration might break if you're not expecting new resources. When a payer stands up a Da Vinci PAS endpoint, your prior auth workflow should use it. When a health system connects to TEFCA, your data exchange patterns may change.

The real impact for startups:

• More FHIR data available — The regulatory push means more data is accessible via standardized APIs. This is good for you.
• Better APIs — Payers and EHRs are investing in their FHIR infrastructure. API reliability and performance are improving.
• But you need to consume them correctly — Sloppy FHIR implementations won't cut it. Use validated FHIR clients. Conform to US Core profiles. Handle pagination, includes, and error responses properly.

The vendor pitch is usually "you need our platform to be compliant." usually "you need to understand these standards and implement them correctly." Those are different things.

Your 2026 Compliance Checklist

Here's the practical, no-nonsense checklist for healthtech organizations in 2026. Not every item applies to every organization — use judgment based on your role in the ecosystem.

FHIR R4 Support

• Are your integrations FHIR-native, or are you wrapping legacy formats in FHIR wrappers?
• Do you support FHIR R4 (not DSTU2, not STU3)?
• Can you handle FHIR bundles, pagination, and search parameters correctly?

US Core Profile Conformance

• Do your FHIR resources conform to US Core 6.1+ profiles?
• Are you validating resources against the profile definitions?
• Are you handling Must Support elements correctly (not ignoring them, not failing on them)?

SMART on FHIR Authentication

• Do you support SMART App Launch Framework (standalone and EHR-launch)?
• Are you handling scopes correctly (patient/*.read, user/*.read)?
• Do you support PKCE (Proof Key for Code Exchange)? It's required for public clients.

USCDI v3 Data Class Support

• Can you consume the new USCDI v3 data classes (health insurance, clinical tests, diagnostic imaging, care team)?
• Have you updated your data models to accommodate these new resources?
• Are you testing against EHR sandbox environments that support USCDI v3?

Bulk FHIR for Population Data

• If you need population-level data, do you support the Bulk Data Access IG?
• Can you handle NDJSON exports and async polling patterns?
• Are you using SMART Backend Services authorization for system-to-system access?

Prior Authorization FHIR Support

• If applicable: can you submit prior auth via Da Vinci PAS?
• Can you consume CDS Hooks responses from CRD?
• Can you render FHIR Questionnaires from DTR?

Security and Compliance

• TLS 1.2+ on all endpoints (TLS 1.3 preferred)?
• Comprehensive audit logging for all data access?
• HIPAA technical safeguards in place (encryption at rest, access controls, breach notification)?
• Regular penetration testing and vulnerability scanning?

The Bottom Line

The CMS interoperability landscape in 2026 is more mature, more enforceable, and more consequential than ever. But it's also more navigable than vendor marketing would have you believe. The standards are published. The implementation guides are tested. The reference implementations exist. The hard part isn't understanding what to do — it's doing the engineering work to implement it correctly.

Stop buying vendor promises. Start building standards-compliant infrastructure. The organizations that invested in FHIR fluency two years ago are the ones shipping features today while their competitors are still evaluating platforms.

If you need help navigating these requirements or building FHIR-native infrastructure, talk to our team. We build this stuff — and we'll tell you honestly what you need and what you don't.

Struggling with healthcare data exchange? Our Healthcare Interoperability Solutions practice helps organizations connect clinical systems at scale. We also offer specialized Healthcare AI Solutions services. Talk to our team to get started.