Short answer: TEFCA (Trusted Exchange Framework and Common Agreement) is the United States' framework for connecting health information networks into one nationwide exchange, created by the 21st Century Cures Act (2016) and run by the federal health IT office (ASTP/ONC) through a Recognized Coordinating Entity (RCE), The Sequoia Project. Networks that sign the Common Agreement and pass onboarding become Qualified Health Information Networks (QHINs); the first were designated in December 2023. Providers, payers, public health agencies and apps join as participants or sub-participants of a QHIN, and a query for a patient's records travels from one QHIN to another under common rules. Exchange started on IHE document standards and is moving to FHIR; Individual Access Services let patients pull their own records through TEFCA-connected apps.
The structure
TEFCA has a layered structure: ASTP/ONC sets policy and publishes the Trusted Exchange Framework and the Common Agreement; the Recognized Coordinating Entity (The Sequoia Project) designates QHINs and maintains the technical framework; QHINs connect to every other QHIN; participants such as hospitals, EHR vendors and payers contract with one QHIN, and sub-participants such as clinics and apps connect through them.
- ASTP/ONC sets policy and publishes the Trusted Exchange Framework (principles) and the Common Agreement (the contract).
- The RCE (The Sequoia Project) designates QHINs, maintains the technical framework (the QHIN Technical Framework, QTF), standard operating procedures and the directory, and handles disputes.
- QHINs are networks that connect to every other QHIN. Designated QHINs include eHealth Exchange, Epic Nexus, Health Gorilla, KONZA, MedAllies, CommonWell Health Alliance, Kno2 and Surescripts, with others in onboarding.
- Participants (hospitals, health systems, EHR vendors, HIEs, payers) contract with one QHIN; sub-participants (clinics, apps) connect through a participant. The flow-down terms of the Common Agreement bind everyone.
Exchange purposes
Under TEFCA, data may be requested only for six defined exchange purposes: treatment, payment, health care operations, public health, government benefits determination and individual access services. Each purpose has rules on who may ask and whether a response is mandatory; responses for treatment and individual access are required, while the other purposes are being phased in.
The purpose is asserted in the query and audited.
How a query works
A TEFCA query under the initial QHIN Technical Framework uses IHE profiles: XCPD finds the patient across networks and XCA queries and retrieves documents, typically C-CDA, with SAML assertions carrying the purpose and the requester. Common Agreement version 2.0 (2024) added FHIR-based exchange, with endpoints in the RCE directory and UDAP-based security, while document exchange continues alongside.
Under the initial QTF, QHIN-to-QHIN exchange uses IHE profiles: XCPD to find the patient across networks, XCA to query and retrieve documents (typically C-CDA), with SAML assertions carrying the purpose and the requester. Common Agreement version 2.0 (2024) added support for FHIR-based exchange: participants can publish FHIR endpoints in the RCE directory, use the TEFCA FHIR roadmap's authentication (UDAP-based dynamic client registration and certificates) and query resources directly, with the QHINs brokering trust rather than relaying documents. Document exchange continues alongside; FHIR adoption is the direction.
Individual Access Services
Individual Access Services (IAS) is the TEFCA exchange purpose that lets a patient use an app to pull their own records from every connected provider: a QHIN or participant offers IAS, the patient verifies identity at assurance level IAL2, and responders must reply within the Common Agreement's timelines. It is the TEFCA counterpart of the Cures Act API access rights.
A QHIN or participant can offer IAS: a patient uses an app, verifies identity at a defined assurance level (IAL2), and the app queries TEFCA for the patient's records across every connected provider. Responders must reply within the Common Agreement's timelines. This is the TEFCA counterpart of the API access rights under the Cures Act rules and of Europe's EHDS patient access, and it is what allows a personal health record to pull data without one-by-one portal logins. See Health records online.
Where Carequality and CommonWell fit
Carequality and CommonWell Health Alliance are the two private frameworks that connected most US providers before TEFCA, exchanging tens of millions of documents a month. CommonWell has become a QHIN, and Carequality is aligning its framework with TEFCA so implementers transition rather than connect twice; today they carry the volume, while TEFCA carries the obligations and the FHIR future.
Before TEFCA, two private frameworks already connected most US providers: Carequality (a trust framework, also run by The Sequoia Project) and CommonWell Health Alliance (a network with a record locator service). Both exchange tens of millions of documents a month. CommonWell became a QHIN; Carequality is aligning its framework with TEFCA so that implementers transition rather than connect twice. For a developer today, Carequality and CommonWell are where the volume is; TEFCA is where the obligations and the FHIR future are.
What it changes for developers
For developers, TEFCA replaces bilateral network agreements with a single legal framework, adds identity and security requirements (certificates, UDAP for FHIR, IAL2 for individual access, audit logging, breach notification to the RCE), provides directory-based discovery of endpoints nationwide, delivers data as C-CDA now and FHIR US Core increasingly, and sits alongside the information-blocking rules that apply regardless.
- A single legal framework (the Common Agreement and its flow-downs) instead of bilateral agreements with each network.
- Identity and security requirements: certificates, UDAP for FHIR, IAL2 for individual access, audit logging, breach notification to the RCE.
- Directory-based discovery of endpoints across the country.
- Data in C-CDA now, FHIR US Core increasingly: your record must consume both, map to the USCDI data classes and handle patient matching across networks (Patient matching).
- Information blocking: certified health IT and providers must not unreasonably interfere with access and exchange; TEFCA participation is one way to demonstrate exchange.
The European counterpart
The EU's MyHealth@EU and the EHDS play the role of TEFCA for cross-border exchange: national contact points instead of QHINs, the European EHR exchange format instead of USCDI, and a regulation instead of a voluntary agreement. See MyHealth@EU and the cross-border patient summary and Your medical data in the EU.
Anpheros is a European platform; for US use, its FHIR record consumes C-CDA and FHIR US Core data a patient obtains through portals, IAS apps or direct clinic connections, and keeps provenance per source.
This page explains regulation for product and engineering teams. It is not legal advice; the texts linked under Sources are the authority, and your data protection officer, notified body or counsel decides for your case. Last reviewed: October 2026.
Related pages
- USCDI explained
- CDA and C-CDA explained
- Patient matching and the master patient index
- Health records online: EU, UK and US
- HIPAA vs GDPR
- Health data regulation map
- MyHealth@EU and the cross-border patient summary
- National electronic health records in Europe and the US
Sources
- ASTP/ONC: Trusted Exchange Framework and Common Agreement (TEFCA)
- The Sequoia Project: RCE, Common Agreement and QHIN directory
- RCE: QHIN Technical Framework
- Carequality
- CommonWell Health Alliance
- 21st Century Cures Act, section 4003 (trusted exchange framework)
Frequently asked questions
Is TEFCA mandatory?
Participation is voluntary, but it is increasingly referenced in federal rules (for example as a way to meet certain exchange requirements) and expected by large health systems and payers. Information-blocking rules apply regardless of TEFCA participation.
What is the difference between a QHIN and an HIE?
A health information exchange is any organisation that moves health data among participants, often regionally. A QHIN is an HIE or network that has signed the Common Agreement, passed the RCE's onboarding and connects to every other QHIN under the same rules.
Can a patient app connect to TEFCA directly?
Through a QHIN or participant that offers Individual Access Services, with the patient's identity verified at IAL2. The app does not become a QHIN; it becomes a sub-participant or a customer of one.
Does TEFCA use FHIR?
Increasingly. The initial exchange used IHE document standards (XCPD, XCA, C-CDA). Common Agreement 2.0 and the QTF added FHIR-based exchange with UDAP security; both run in parallel while networks migrate.
Try it free in the sandbox
Your first FHIR call in 5 minutes. An HL7 FHIR R4 API with the patient's consent built in: try it in the sandbox, then connect your own app or clinic system.
Free · 30 synthetic patients · no card
Anpheros builds a medical record that the patient controls and can share with any clinic, on an HL7 FHIR R4 platform, based in the EU. These guides help you understand and organise your health; they do not replace your doctor.
About Anpheros →
AnpherosThe more you log, the clearer your record
Your health history in one place, under your control.
Free · Works in your browser · No card
