TEFCA — Trusted Exchange Framework and Common Agreement
TEFCA — Trusted Exchange Framework and Common Agreement
The Trusted Exchange Framework and Common Agreement (TEFCA) is ONC’s mechanism for creating a national governance framework for health information exchange. TEFCA is not a technical standard, not a law, and not a mandate — it is a governance framework that defines how organizations can exchange health data across a “network of networks” under a common set of rules.
TEFCA was authorized by the 21st Century Cures Act and developed by ONC over several years. The Common Agreement version 1 was released January 2022. Designated QHINs began operations in late 2023.
The problem TEFCA addresses
Before TEFCA, health information exchange in the United States was fragmented:
- Hundreds of regional HIEs — each with their own governance, participation agreements, and technical approaches
- Two national networks — CommonWell Health Alliance and Carequality, each with substantial connectivity but separate governance and different query frameworks
- Point-to-point connections — direct agreements between individual organizations (hospital to lab, EHR vendor to EHR vendor), creating a web of bilateral contracts
- No universal floor — no common privacy standards, no common dispute resolution, no consistent permitted use framework across networks
A hospital participating in a regional HIE could exchange data with other participants in that HIE. If a patient received care at a facility on CommonWell but the hospital was on Carequality, exchange was possible through a bridging arrangement — but not guaranteed and not governed by common rules.
TEFCA’s approach: create a single governance layer — a Common Agreement — that all participating organizations sign. Any organization that joins TEFCA can exchange data with any other TEFCA participant, regardless of which network they connect through, because all participants are bound by the same agreement.
Structure of TEFCA
TEFCA has a tiered participation structure. Understanding which tier an organization sits in determines what they must do to participate.
The Common Agreement
The Common Agreement (CA) is the legal document that all TEFCA participants — directly or through their QHIN — adhere to. It establishes:
- Permitted exchange purposes — the specific, enumerated reasons for which TEFCA data exchange is authorized (see exchange purposes below)
- Privacy and security requirements — the minimum standards all participants must meet, building on HIPAA but extending it in some areas
- Technical requirements — what TEFCA participants must support technically (referenced through the QHIN Technical Framework)
- Individual access services — rights and processes for patients to access their own data through TEFCA
- Dispute resolution — the process for resolving disagreements between participants
- Reciprocal access obligations — participants who respond to queries must also be able to send queries; participation is not one-directional
The Recognized Coordinating Entity (RCE) is responsible for maintaining and updating the Common Agreement.
Recognized Coordinating Entity (RCE)
ONC designated The Sequoia Project as the Recognized Coordinating Entity — the independent organization that manages TEFCA. The RCE’s responsibilities include:
- Reviewing and designating QHINs
- Maintaining the Common Agreement and the QHIN Technical Framework
- Monitoring QHIN compliance
- Adjudicating disputes between participants
- Reporting to ONC on TEFCA operations
The RCE is not a government agency but operates under a cooperative agreement with ONC. The Sequoia Project was selected because of its prior experience operating Carequality’s policy framework.
Qualified Health Information Networks (QHINs)
QHINs are the backbone of TEFCA. A QHIN is an organization that:
- Signs the Common Agreement directly with the RCE
- Connects to other QHINs via QHIN-to-QHIN exchange
- Onboards Participants (healthcare organizations) under their governance
- Operates the technical infrastructure for TEFCA exchange
QHINs designated as of early 2026:
| QHIN | Notes |
|---|---|
| CommonWell Health Alliance | Pre-existing national network; now a QHIN |
| eHealth Exchange | Pre-existing federal/state health data exchange network |
| Epic (Nexus) | Epic’s own QHIN, connecting Epic-using organizations |
| Health Gorilla | Digital health data network |
| Kno2 | Health information network focused on post-acute care |
| MedAllies | QHIN with focus on direct secure messaging and HIE |
| KONZA | Public health-focused QHIN |
| Carequality (via The Sequoia Project) | Carequality’s framework now operates as/within TEFCA |
QHIN-to-QHIN connections mean that a Participant connected to one QHIN can exchange data with a Participant connected to any other QHIN without bilateral agreements.
Participants
Healthcare organizations — hospitals, health systems, physician practices, laboratories, pharmacies, health plans — connect to TEFCA as Participants by signing with a QHIN. The Participant:
- Signs the QHIN’s participation agreement (which incorporates the Common Agreement obligations)
- Meets the technical requirements for participation (or connects through a compliant vendor)
- Is responsible for the exchange activities of their organization under TEFCA
A health system that joins TEFCA through Epic Nexus QHIN (for example) becomes a Participant under that QHIN.
Sub-participants
Vendors, intermediaries, and smaller organizations that connect through a Participant are Sub-participants. A health IT vendor might connect as a Sub-participant through a larger health system Participant, enabling their customers to exchange data via TEFCA without each customer directly joining.
Exchange purposes
TEFCA does not permit unlimited data access. Exchange must fall within one of the defined exchange purposes. These are enumerated categories — not free-form justifications.
| Exchange purpose | Code | Description |
|---|---|---|
| Treatment | TreatmentTEFCA | Exchange for the treatment of an individual patient, including care coordination and referrals |
| Payment | PaymentTEFCA | Exchange for payment activities — claims, eligibility verification, prior authorization |
| Health care operations | HealthCareOperationsTEFCA | Exchange for operational purposes — quality improvement, care management, compliance |
| Individual access services | IAS | A patient requesting access to their own health data through a TEFCA-connected app or service |
| Public health | PublicHealthTEFCA | Exchange with public health agencies for reporting, surveillance, and population health |
| Benefits determination | BenefitsDeterminationTEFCA | Exchange to determine eligibility for government benefit programs |
| Government health data access | GHDATEA | Exchange with federal or state government entities for authorized oversight or program administration |
The exchange purpose must be documented and is auditable. A Participant cannot use a treatment-purpose query to retrieve data for a non-treatment operational purpose.
Individual Access Services (IAS)
IAS is particularly significant because it creates a patient-initiated access pathway through TEFCA. Under IAS, a patient can authorize a TEFCA-connected app or service to query the network for their health data across all TEFCA participants. The patient’s authorization is the basis for the query — not a treating relationship or operational need.
IAS under TEFCA is conceptually similar to the SMART App Launch model in the Patient Access API (CMS-9115-F), but operates at the network level rather than the individual payer level. A patient using an IAS-capable app can potentially retrieve data from any TEFCA-connected provider or payer that holds their records, rather than only from a single payer’s API.
Technical standards
IHE profiles (document exchange)
TEFCA QHINs must support IHE (Integrating the Healthcare Enterprise) document exchange profiles for query and retrieve:
- XCPD (Cross-Community Patient Discovery) — finding a patient across communities using demographics
- XCA (Cross-Community Access) — querying for and retrieving documents from other communities
- XDS (Cross-Document Sharing) — the underlying document sharing architecture
These profiles have been the foundation of HIE and health data exchange for over a decade. CommonWell, eHealth Exchange, and most regional HIEs already use these profiles. TEFCA preserves this existing technical infrastructure.
FHIR-based exchange
TEFCA QHINs must also support FHIR R4-based exchange, with rollout beginning in 2024. The QHIN Technical Framework (QTF) specifies the FHIR requirements, which build on US Core profiles and align with the broader CMS and ONC FHIR mandates.
FHIR exchange in TEFCA enables querying at the resource level — not just document retrieval — and aligns with the app ecosystem built on SMART App Launch. The combination of IHE document exchange (for existing infrastructure) and FHIR (for modern API-based exchange) gives TEFCA backward compatibility while enabling the future state.
QHIN Technical Framework (QTF)
The QTF is the document that specifies the technical requirements QHINs must meet to achieve and maintain designation. It includes:
- Required IHE profiles and transactions
- FHIR R4 requirements and US Core alignment
- Security requirements (TLS, mutual authentication)
- Audit logging requirements
- Performance and availability requirements
Relationship to CommonWell and Carequality
CommonWell and Carequality are the two pre-TEFCA national exchange networks. Both predate TEFCA significantly and have established participant ecosystems.
Carequality: Operated by The Sequoia Project (the same organization that is now the RCE). Carequality’s governance framework was the model that ONC used when designing TEFCA’s governance structure. Under TEFCA, Carequality’s framework integrates into the TEFCA governance structure — the Sequoia Project operates both.
CommonWell: A separate organization originally formed by EHR vendors (including Allscripts, athenahealth, Cerner, Greenway, McKesson, and others). CommonWell connected to Carequality through a bridging agreement. Under TEFCA, CommonWell has designated as a QHIN, making it a first-class TEFCA participant rather than a separate network.
The practical effect: organizations that were previously connected to CommonWell or Carequality but not to each other now exchange data through the TEFCA QHIN-to-QHIN connections. TEFCA does not eliminate CommonWell and Carequality — it integrates them into a common governance layer.
TEFCA and information blocking
TEFCA participation does not satisfy the information blocking prohibition. These are separate obligations under different legal authorities:
- Information blocking is a statutory prohibition under 21st Century Cures Act § 3022, enforced by OIG and CMS
- TEFCA is a voluntary governance framework with no direct statutory enforcement mechanism
An organization that joins TEFCA but still refuses to respond to legitimate queries — or charges unreasonable fees for data access through TEFCA — may still be engaged in information blocking. TEFCA participation is not a safe harbor for information blocking.
The relationship works in the other direction: TEFCA makes it easier to comply with information blocking obligations by providing a practical mechanism and governance framework for data exchange. Having a QHIN connection provides an available pathway for sharing data that might otherwise be claimed as technically infeasible.
See Information Blocking Rule for the prohibition and exceptions.
Current status (as of early 2026)
| Dimension | Status |
|---|---|
| QHINs designated | Eight QHINs operational |
| IHE document exchange | Operational across QHINs |
| FHIR exchange | Rolling out; required capability for QHINs |
| IAS (patient-initiated) | Available through TEFCA-connected apps |
| Participation mandate | Voluntary — no legal mandate to join TEFCA |
| CMS payment linkage | Not yet established; under policy discussion |
Participation in TEFCA is voluntary. There is no federal law requiring hospitals, health systems, providers, or payers to join TEFCA. CMS has discussed but not finalized tying TEFCA participation to payment incentives or CMS program participation requirements.
Despite the voluntary nature, TEFCA participation is growing because it provides practical interoperability value — particularly for referral networks, care transitions, and multi-site organizations that previously maintained many bilateral exchange agreements.
Should your organization participate in TEFCA?
For health systems and hospitals
TEFCA provides broader connectivity than a collection of bilateral HIE agreements. For health systems with complex referral networks spanning multiple HIEs and networks, TEFCA’s QHIN connection can replace or reduce the need for many individual agreements.
Practical use cases:
- Querying for patient records at admission from any TEFCA-connected facility (treatment purpose)
- Care coordination with post-acute providers (skilled nursing facilities, home health agencies) that may not be on the health system’s regional HIE
- Receiving referral records automatically through IHE document exchange
For EHR vendors
QHIN connectivity is increasingly expected by health system customers, particularly those with complex care coordination needs. EHR vendors that connect as Participants or Sub-participants through a QHIN can offer TEFCA connectivity as a feature.
Epic operates its own QHIN (Nexus), giving Epic-using health systems automatic TEFCA connectivity. Other EHR vendors connect through existing QHINs (CommonWell, eHealth Exchange, etc.).
For payers
Payer participation pathways are emerging for TEFCA exchange purposes including BenefitsDeterminationTEFCA, PaymentTEFCA, and HealthCareOperationsTEFCA. TEFCA provides payers with a mechanism to query for clinical data across a broad provider network for care management and prior authorization support, without needing bilateral agreements with each provider.
TEFCA participation may also simplify compliance with CMS-0057-F’s Provider Access API obligations by providing a network connectivity layer.
See also
- Information Blocking Rule — ONC’s prohibition on obstructing data access
- ONC 21st Century Cures Act Final Rule — the statutory basis for TEFCA and the certification framework
- Patient Access API — CMS-9115-F patient-initiated data access, conceptually related to IAS
- CMS Interoperability Rules — CMS obligations that TEFCA connectivity can support