EHR Interoperability in 2026: FHIR, TEFCA, and What Your Practice Needs to Know

What EHR Interoperability Actually Means

At its simplest, interoperability is the ability of different health IT systems to exchange patient data and use it meaningfully. When a patient arrives at your practice from another provider, interoperability means you can electronically retrieve their medication list, allergy history, lab results, and problem list — without faxing, phone calls, or the patient filling out clipboards from memory.

But interoperability is not a binary state. The Healthcare Information and Management Systems Society (HIMSS) defines four levels:

1. Foundational — System A can send data to System B. The receiving system can accept the data but may not interpret it. Think of a fax machine: it delivers information, but it doesn't understand it.
2. Structural — Data is exchanged in a standardized format (such as HL7 or C-CDA documents) so the receiving system can parse the message into discrete fields. The data arrives organized, but clinical terms may not map perfectly.
3. Semantic — Both systems use shared clinical vocabularies — SNOMED CT for diagnoses, LOINC for lab tests, RxNorm for medications — so the meaning of data is preserved across systems. A hemoglobin A1c result from Lab A is recognized as the same test by System B.
4. Organizational — Governance, policies, legal agreements, and consent management align across organizations so data flows not just technically but legally and operationally. This is where TEFCA operates.

Most healthcare organizations today operate somewhere between structural and semantic interoperability. The regulatory push — and the point of this guide — is to get everyone to full organizational interoperability by creating universal rules of the road.

Why Interoperability Matters More Than Ever

Healthcare has talked about interoperability for decades. So why is 2026 the year it demands your attention? Three converging forces.

1. The Data Shows Real Progress

According to ONC's most recent data, 43% of hospitals now engage in all four domains of interoperable exchange — electronically sending, receiving, finding, and integrating data from external sources. That is up from just 28% in 2018. Progress is accelerating, and organizations that lag behind are increasingly visible outliers.

Additional indicators of the shift:

• 88% of hospitals electronically send care summaries to external providers (ONC, 2024)
• 74% of hospitals integrate data received from outside sources into their EHR rather than just viewing it
• 61% of office-based physicians can electronically query external sources for patient data

2. Federal Enforcement Is Now Real

The 21st Century Cures Act was signed in 2016, but enforcement was slow to materialize. That changed. The Information Blocking Rule took effect April 5, 2021. Approximately 1,300 complaints have been filed with ONC. Civil monetary penalties can reach $1 million per violation for health IT developers and health information networks. And in September 2025, HHS announced increased enforcement actions — including referrals to the Office of Inspector General (OIG) for providers. This is no longer theoretical.

3. Patients Expect It

Consumer technology has set the bar. Patients can transfer money between banks instantly, track a package across three continents in real time, and share photos with anyone on any device. They increasingly expect the same frictionless experience with their health data. The CMS Patient Access Rule requires payers to provide FHIR-based APIs so patients can access their claims and clinical data through third-party apps. This expectation is cascading to providers: patients want to download their records, share them with specialists, and view results on their phones. Practices that make this easy earn loyalty. Practices that make it hard lose patients.

The Regulatory Landscape: What You Must Comply With

The interoperability regulatory framework has three pillars. Understanding each is essential for compliance and strategic planning.

21st Century Cures Act (2016)

The foundational law. Signed by President Obama in December 2016, the Cures Act directed ONC and CMS to:

• Establish conditions and maintenance of certification requirements for health IT developers
• Define and prohibit "information blocking" by providers, health IT developers, and health information networks
• Require standardized APIs for patient and provider access to electronic health information (EHI)
• Develop the Trusted Exchange Framework and Common Agreement (TEFCA) for nationwide interoperability

The Cures Act is the legislative backbone. Everything else — the Information Blocking Rule, TEFCA, FHIR API requirements — flows from it.

ONC Cures Act Final Rule (2020)

Published in May 2020, this rule implemented the Cures Act's health IT provisions. Key requirements:

• Standardized FHIR-based APIs — Certified health IT must support the HL7 FHIR standard (specifically US Core Implementation Guide) for patient and population-level data access
• USCDI (United States Core Data for Interoperability) — Defines the minimum set of data classes and elements that must be exchangeable. USCDI v1 launched in 2020; USCDI v4 was finalized in 2024, adding data classes for health insurance, tribal affiliation, and social determinants of health
• Anti-information-blocking provisions — Defined eight exceptions (such as preventing harm, privacy, and security) and required actors to demonstrate they are not interfering with data exchange
• Conditions of Certification — EHR vendors must publish their APIs, not charge unreasonable fees for data access, and attest to compliance annually

CMS Interoperability and Patient Access Rules

CMS has layered additional requirements on payers and providers participating in Medicare and Medicaid:

• Patient Access API — CMS-regulated payers must maintain a FHIR-based Patient Access API so members can access their claims and clinical data via third-party apps
• Provider Directory API — Payers must maintain a FHIR-based provider directory
• Payer-to-Payer Data Exchange — When a patient switches insurance, the new payer must be able to request records from the prior payer electronically
• Prior Authorization API — CMS finalized requirements for payers to support electronic prior authorization through FHIR APIs, with compliance deadlines beginning in 2026

FHIR Explained: The Standard That Changed Everything

FHIR (Fast Healthcare Interoperability Resources, pronounced "fire") is a data exchange standard developed by HL7 International. It has become the cornerstone of modern health data exchange — and understanding it is essential for evaluating any EHR in 2026.

Why FHIR Replaced HL7v2

For decades, healthcare data exchange relied on HL7 Version 2 (HL7v2), a messaging standard developed in the late 1980s. HL7v2 was groundbreaking for its time but carries significant limitations:

• Optionality problem — HL7v2 allows so many optional fields and local variations that two "HL7v2-compliant" systems often cannot understand each other without custom interface mapping. The joke in health IT: "If you've seen one HL7v2 interface, you've seen one HL7v2 interface."
• Point-to-point architecture — HL7v2 was designed for direct connections between two systems, requiring a dedicated interface for every pair. A hospital with 50 systems needs up to 1,225 individual interfaces.
• No native web support — HL7v2 uses a proprietary TCP/IP protocol (MLLP). It predates the web and does not natively support HTTP, REST, or modern authentication methods.

FHIR solves all three problems:

• Granular, standardized resources — FHIR defines over 150 "resources" (Patient, Observation, MedicationRequest, Condition, etc.) with consistent structure. Each resource has a standard set of required and optional fields, drastically reducing ambiguity.
• RESTful API model — FHIR uses the same HTTP-based API architecture that powers every major web application. Developers can query a FHIR server with standard HTTP requests (GET, POST, PUT, DELETE) — no proprietary protocols or middleware required.
• JSON and XML support — FHIR data is exchanged in JSON (the native language of modern web development) or XML, making it accessible to any developer, not just health IT specialists.
• OAuth 2.0 security — FHIR uses industry-standard authentication and authorization (OAuth 2.0 / SMART on FHIR), aligning healthcare with modern security practices.

FHIR Adoption: Where We Stand

FHIR adoption has crossed the tipping point. The numbers are striking:

• 92% of EHR vendors now support FHIR (ONC data). This includes every major vendor: Epic, Oracle Health, MEDITECH, athenahealth, eClinicalWorks, NextGen, and Veradigm.
• 90% of health systems have deployed FHIR-enabled APIs, up from under 50% in 2020
• 81% of non-federal acute care hospitals have enabled patient access APIs using FHIR (ONC Health IT Dashboard)
• FHIR R4 is the current normative (stable) release and the version required by ONC certification. FHIR R5 was published in 2023 and is being adopted selectively, but R4 remains the regulatory baseline.

FHIR in Practice: What It Looks Like

Here is a concrete example. A patient visits Specialist B after seeing Primary Care Provider A. With FHIR:

1. Specialist B's EHR sends a FHIR query to Provider A's EHR (or a shared health information network) requesting the patient's record
2. Provider A's FHIR API returns structured data: medications as MedicationRequest resources, diagnoses as Condition resources, lab results as Observation resources
3. Specialist B's EHR ingests these resources directly into the patient chart — medications populate the medication list, allergies populate the allergy list, lab values display in the results viewer
4. No fax. No phone call. No manual data entry. No interface engine mapping. Discrete, coded data flows between systems in seconds.

This is the vision. We are not fully there yet — gaps in adoption, consent management, and data quality persist — but FHIR has made it technically achievable in a way that HL7v2 never could.

TEFCA: The National Health Data Highway

FHIR is the language. TEFCA is the highway system. While FHIR standardizes how data is formatted and exchanged, TEFCA standardizes the governance, legal agreements, and network infrastructure for exchanging that data at a national scale.

What TEFCA Is

The Trusted Exchange Framework and Common Agreement (TEFCA) is a federal initiative directed by the 21st Century Cures Act and managed by the Sequoia Project (as the Recognized Coordinating Entity) under contract with ONC. TEFCA has two components:

• Trusted Exchange Framework (TEF) — A set of non-binding principles for health information exchange
• Common Agreement (CA) — A legally binding contract that Qualified Health Information Networks (QHINs) sign, committing to minimum terms for data exchange including privacy, security, and technical requirements

How TEFCA Works: The QHIN Model

TEFCA operates through a hub-and-spoke model built on QHINs:

1. QHINs (Qualified Health Information Networks) are organizations designated by the Sequoia Project to serve as national on-ramps to health data exchange. The first QHINs were designated in December 2023 and include organizations like eHealth Exchange, Epic Nexus, KONZA National Network, MedAllies, Health Gorilla, Kno2, and the CommonWell Health Alliance.
2. Participants are organizations (hospitals, health systems, payers) that connect to a QHIN to exchange data
3. Sub-participants are individual providers or entities that connect through a Participant

The key breakthrough: once you connect to any single QHIN, you can exchange data with organizations connected to any other QHIN. One connection provides nationwide reach. This eliminates the need for dozens of point-to-point connections or joining multiple health information exchanges.

TEFCA Exchange Purposes

TEFCA currently supports several standardized exchange purposes:

• Treatment — Querying for patient records to support clinical care
• Payment/Operations — Supporting claims processing and health plan operations
• Individual Access Services (IAS) — Enabling patients to aggregate and access their own records across providers
• Public Health — Reporting to public health agencies
• Government Benefits Determination — Supporting eligibility determination for government programs

FHIR Exchange Under TEFCA

TEFCA initially launched with document-based exchange (C-CDA documents over IHE profiles). But in 2025, TEFCA piloted FHIR-based exchange, enabling granular, resource-level queries rather than full-document retrieval. This is a significant evolution: instead of receiving a 50-page C-CDA document and parsing through it, a provider can query specifically for a patient's active medications or recent lab results.

The convergence of FHIR and TEFCA is the most significant interoperability development in a decade. It means that standardized data (FHIR) flowing over standardized networks (TEFCA) can reach any provider in the country — the closest healthcare has ever been to true nationwide interoperability.

SMART on FHIR: The App Ecosystem

If FHIR is the highway and TEFCA is the traffic system, SMART on FHIR is the app store. SMART (Substitutable Medical Applications and Reusable Technologies) is a technology standard built on top of FHIR that enables third-party applications to launch inside an EHR and securely access patient data.

How SMART on FHIR Works

SMART on FHIR uses OAuth 2.0 for authorization. The workflow:

1. A clinician opens a third-party app from within their EHR (or the app launches in a new window)
2. The app requests permission to access patient data through the EHR's FHIR API
3. The EHR authenticates the user and verifies their access rights
4. The app receives a scoped access token — it can only access the data it has been authorized for
5. The app reads (and potentially writes) data through FHIR APIs

This model is revolutionary because it decouples applications from specific EHR platforms. A SMART on FHIR app built once can run inside Epic, Cerner, MEDITECH, athenahealth, or any EHR that supports the standard — the same way a web app works in Chrome, Firefox, or Safari.

EHR App Marketplaces

Major EHR vendors now operate app marketplaces powered by SMART on FHIR:

• Epic App Orchard / App Market — The largest health IT app marketplace with hundreds of third-party apps spanning clinical decision support, patient engagement, population health, and specialty workflows
• Oracle Health (Cerner) App Gallery — Marketplace for apps that integrate with Oracle Health's EHR through FHIR APIs
• athenahealth Marketplace — Over 250 integrated apps and services for athenahealth's cloud platform
• MEDITECH Greenfield — MEDITECH's app development program for SMART on FHIR integrations

For your practice, SMART on FHIR means you are not locked into your EHR vendor's feature roadmap. If you need a specialized clinical decision support tool, a patient engagement app, or an AI-powered documentation assistant, you can add it through the app marketplace without waiting for your vendor to build it natively.

Information Blocking: What It Is and How to Avoid Violations

The Information Blocking Rule, published as part of the ONC Cures Act Final Rule, is the enforcement mechanism for interoperability. It applies to three categories of "actors":

• Health IT developers of certified health IT (EHR vendors)
• Health information exchanges (HIEs) and health information networks (HINs)
• Healthcare providers (yes, this includes your practice)

What Counts as Information Blocking

Information blocking is any practice that is likely to interfere with, prevent, or materially discourage the access, exchange, or use of electronic health information (EHI). Examples that could trigger a violation:

• Refusing to send records electronically when you have the capability to do so
• Charging excessive fees for data export or interface setup
• Implementing technical barriers that make it unnecessarily difficult for patients to access their records through apps
• Delaying responses to data requests without a valid reason
• Restricting which data elements are available through APIs (beyond what USCDI requires)
• Requiring patients to come to your office in person to pick up records that could be sent electronically

The Eight Exceptions

Not every refusal to share data is information blocking. The rule defines eight exceptions that, if met, shield actors from liability:

1. Preventing Harm — Withholding data to prevent harm to a patient or another person (must meet specific criteria)
2. Privacy — Protecting patient privacy when required by state or federal law
3. Security — Implementing security practices that may limit access (e.g., multi-factor authentication, encryption requirements)
4. Infeasibility — Situations where sharing is technically impossible (e.g., system downtime, incompatible data formats)
5. Health IT Performance — Temporary restrictions to maintain system performance during high-load periods
6. Content and Manner — Offering data in an alternative (but still accessible) format or manner
7. Fees — Charging reasonable fees that do not create barriers to access
8. Licensing — Protecting intellectual property through reasonable licensing terms

Enforcement Reality

As of early 2026, the enforcement landscape has teeth:

• ~1,300 complaints have been filed with ONC's Information Blocking Portal since April 2021
• Penalties for health IT developers and HINs can reach up to $1 million per violation under the HHS disincentive framework
• For providers, HHS can refer cases to the OIG for investigation and potential penalties under existing authorities (False Claims Act, Anti-Kickback Statute, and CMP authorities)
• In September 2025, HHS announced escalated enforcement, including the first formal investigations and the publication of enforcement guidance clarifying what constitutes "reasonable and necessary" practices versus violations

Cloud vs. On-Premise: The Interoperability Dimension

Your EHR's deployment model has a direct impact on your interoperability posture. As we detailed in our comprehensive cloud vs. on-premise comparison, cloud-native EHRs carry meaningful advantages when it comes to data exchange.

Why Cloud Has the Edge

The core reason is architectural: cloud EHRs expose internet-facing APIs by design. Their infrastructure is already set up for external communication. On-premise systems sit behind firewalls and were originally designed for internal use — adapting them for external data exchange requires additional infrastructure (VPNs, DMZs, reverse proxies, interface engines) that adds cost and complexity.

This does not mean on-premise EHRs cannot be interoperable. Epic, Oracle Health, and MEDITECH all support FHIR and network connectivity in on-premise deployments. But the lift is heavier, ongoing maintenance is your responsibility, and you are more likely to fall behind on standards updates. For a complete analysis of the trade-offs beyond interoperability, see our cloud EHR vs. on-premise guide.

Choosing an Interoperable EHR Vendor: The Questions to Ask

Whether you are selecting a new EHR or evaluating your current vendor's interoperability readiness, these are the questions that separate truly interoperable platforms from those that merely check a box.

Certification and Standards

1. Are you certified under the ONC Health IT Certification Program (2015 Edition Cures Update)? — This is the baseline. Without it, you cannot attest for Promoting Interoperability and the vendor may not be compliant with anti-information-blocking rules.
2. Which version of FHIR do you support? — The answer should be FHIR R4 at minimum. Ask specifically about US Core Implementation Guide compliance and which USCDI version they support (should be USCDI v3 or v4).
3. Do you support Bulk FHIR for population-level data export? — Important for quality reporting, research, and payer data exchange.

Network Connectivity

4. Which health information networks do you participate in? — Look for Carequality, CommonWell Health Alliance, and/or a TEFCA-designated QHIN. The more networks, the broader your reach.
5. Are you connected to a TEFCA QHIN, or do you have a timeline for TEFCA participation? — This is becoming the standard for nationwide exchange. Vendors with no TEFCA roadmap are behind.
6. How many organizations can I exchange data with through your network? — Ask for specifics. Epic's Care Everywhere network connects over 300 million patient records. Carequality connects over 70% of US hospitals. Numbers matter.

App Ecosystem

7. Do you support SMART on FHIR for third-party app integration? — If yes, ask to see the app marketplace and how many apps are currently available.
8. What is the process for adding a new third-party app? — Understand the approval timeline, security review requirements, and any fees.

Data Portability

9. Can I export all of my data in a standards-based format? — The answer should be yes, in FHIR, C-CDA, or both. Beware vendors that charge excessive fees for data export — this may itself constitute information blocking.
10. What is your data migration support if I switch vendors? — A good vendor provides export tools, documentation, and transition support even when you are leaving. An information-blocking-compliant vendor must not create barriers.

For a structured approach to evaluating vendors beyond interoperability, including usability, cost, implementation, and support, use our complete EHR selection process guide. And when you are ready to implement, our EHR implementation checklist covers every phase from contract signing through post-go-live optimization.

If you are specifically evaluating EHRs for behavioral health or substance abuse treatment, interoperability requirements have nuances around 42 CFR Part 2 (substance use disorder privacy) and state consent laws. See our behavioral health EHR comparison for specialty-specific guidance.

Frequently Asked Questions

Your Interoperability Action Plan

Interoperability is no longer a future-state aspiration. Federal rules are in effect. Penalties are being levied. Patients expect it. And the technology — FHIR, TEFCA, SMART on FHIR — is mature enough to deliver it. Here is what to do now.

1. Audit your current state — Can your EHR send, receive, find, and integrate external data today? If you are not doing all four, identify the gaps.
2. Verify your vendor's certification — Check the ONC CHPL database to confirm your EHR is certified under the 2015 Edition Cures Update. If it is not, you have a compliance problem.
3. Ask about TEFCA — Contact your EHR vendor and ask for their TEFCA participation status or roadmap. If they have no plan, start evaluating alternatives using our EHR selection process.
4. Review your information blocking posture — Audit your current policies for releasing records. Does your staff default to sharing? Do you charge fees for electronic record requests? Fix any practices that could be construed as information blocking.
5. Enable patient access APIs — If your EHR supports FHIR-based patient access (and if it is certified, it must), make sure it is turned on and patients know how to use it.
6. Explore SMART on FHIR apps — Check your vendor's app marketplace for tools that could improve your clinical workflows — especially AI documentation tools, clinical decision support, and patient engagement apps.
7. Plan for USCDI v4 — The latest version of USCDI adds new data elements including social determinants of health. Ensure your documentation workflows capture this data in structured, coded form.

The organizations that thrive in the next decade of healthcare will be the ones that treat data exchange not as a regulatory burden but as a strategic capability — reducing duplicate testing, improving care coordination, accelerating referrals, and delivering the seamless experience that patients increasingly demand.