TEFCA: Complete Guide

What is TEFCA, and how does it work?

TEFCA is a federal framework for nationwide health information exchange in which Qualified Health Information Networks (QHINs) connect to each other and carry queries and records for the organizations below them. Every organization signs terms that flow down from one Common Agreement, so a single connection replaces dozens of separate network agreements.

In practice, TEFCA is three things at once: a legal agreement, a set of technical specifications for queries and responses, and a governance structure that decides who may join and what they may ask for.

Joining is voluntary. Organizations join because it widens the set of records they can reach and because many EHR vendors and health information exchanges now offer TEFCA as their route to national exchange.

Who runs TEFCA, and who can join?

ASTP/ONC sets TEFCA policy, a Recognized Coordinating Entity (RCE) manages the Common Agreement day to day, and QHINs carry the traffic. The Sequoia Project serves as the RCE under a contract with ONC.

• ASTP/ONC: Owns the framework, approves changes to the Common Agreement and oversees the RCE.
• RCE: Designates QHINs, publishes the standard operating procedures and technical specifications, and handles disputes.
• QHIN: A network designated to exchange with other QHINs. It routes queries, answers them on behalf of its members and enforces the flow-down terms.
• Participant: An organization that signs directly with a QHIN, such as a health system, an EHR vendor, a health information exchange or an app developer.
• Subparticipant: An organization that connects through a Participant, such as a clinic on a vendor's platform.

Most provider organizations end up as Subparticipants without noticing, because their EHR vendor is the Participant. Product companies that need their own connection usually sign as a Participant with a QHIN or as a Subparticipant under a health information exchange.

How a TEFCA query travels

TEFCA works as a network of networks. Health systems, payers, public health agencies and individual access apps sit under a QHIN, the QHINs exchange with each other, and the RCE manages the Common Agreement that binds them all. A typical treatment query runs in five steps.

• 1. Request: A clinician opens a chart, and the EHR or product sends a query with the patient's demographics and the exchange purpose to its QHIN, directly or through a Participant.
• 2. Broadcast or target: The initiating QHIN sends the query to other QHINs, either to all of them or to those likely to hold records for the patient.
• 3. Match: Each responding QHIN passes the query to its members, which run their own patient matching against the demographics and return a list of available documents or resources.
• 4. Retrieve: The initiating system asks for the documents it wants. Document exchange in C-CDA format came first, and FHIR-based exchange is being added.
• 5. Use and log: The receiving system stores, deduplicates and shows the records, and both sides log the transaction for audit.

Steps 3 and 5 are where most of the engineering effort goes. The network moves the bytes; your system has to find the right patient and make the result usable.

Designing the matching and storage layer

• Outbound demographics: Send every identifier you hold, including previous names, prior addresses and a normalized phone number, because the responder matches only on what you send.
• Inbound matching: When you answer queries, set match thresholds with your health information management team and route borderline matches to a review queue instead of returning them.
• Document store: Keep retrieved documents with their source organization, retrieval time and exchange purpose, so a later audit can show where each record came from.
• Reconciliation: Parse problems, medications and allergies from received documents into a list the clinician accepts or rejects, rather than writing them straight into the chart.

These four pieces are the same whichever QHIN you pick, so they can be designed before the network contract is signed.

Which exchange purposes can you use?

Every TEFCA request must carry an exchange purpose, and the purpose decides who may ask and what the responder must consider. ASTP/ONC lists treatment, payment, health care operations, public health, government benefits determination and individual access services, and says the list will grow over time.

• Treatment: The most used purpose. A provider asks for records to care for a patient.
• Payment and health care operations: A payer or provider asks for data tied to claims, quality or care management. Responders often apply narrower rules here.
• Public health: A public health agency asks for or receives data for case investigation or reporting.
• Government benefits determination: A government agency asks for records to decide eligibility for a benefit.
• Individual access services: A patient, through an app, asks for their own records. This purpose carries identity verification requirements set in the RCE's procedures.

Start with one purpose, usually treatment, and add others once the first flow works. Each purpose brings its own response rules, consent questions and audit needs, so adding them one at a time keeps testing manageable.

Check the current standard operating procedures for which purposes your organization must respond to, not only which ones it may send. A connection that only sends queries can fall short of the terms it signed.

What changed for TEFCA recently?

TEFCA now has a regulation behind it and reported volume to match. Two federal actions matter for anyone planning a connection.

• Regulation: The TEFCA final rule, published on 16 December 2024, added 45 CFR Part 172. It sets QHIN qualifications, the onboarding and designation process, suspension, termination and the review of RCE or ASTP/ONC decisions.
• Volume and oversight: On 26 June 2026, HHS announced that records exchanged through TEFCA had grown from 10 million to more than 1 billion in less than a year, and that ONC had added reviews of QHINs and their participants to confirm they follow TEFCA's rules.

For a product team, the practical effect is that QHIN status is now a regulated designation and that compliance reviews are real. Treat your audit trail and purpose handling as things a reviewer will ask to see.

Should you join through a QHIN, a Participant or your EHR vendor?

Most organizations should join through the route that already holds their patient data, which is usually the EHR vendor. A direct QHIN or Participant agreement makes sense when you build your own product or need purposes your vendor does not offer.

• EHR vendor connection: Fits a provider whose records live in one major EHR. Matching, retrieval and display are already built, and the main work is configuration, policy and training.
• Health information exchange as Participant: Fits regional providers and smaller vendors that already send data to an exchange. You inherit its matching and its TEFCA terms.
• Direct Participant with a QHIN: Fits product companies, payers and multi-EHR organizations that need control over queries, purposes and data handling. You build or buy the gateway, matching and storage.
• Individual access services app: Fits consumer apps that fetch records for patients. Identity proofing, consent screens and the app's privacy terms become the core of the build.

When you compare QHINs, ask about the exchange purposes each supports, its FHIR readiness, its fees, its testing environment and how it handles responses from members that time out.

Where TEFCA connections break

The engineering risk in a TEFCA connection sits at the edges, where demographics, documents and clinicians meet, more than in the network layer.

• Weak demographics: Queries sent with missing middle names, old addresses or unformatted phone numbers return no match, so clinicians conclude the network is empty.
• Duplicate floods: A broad query can return the same discharge summary from several organizations. Without deduplication, the chart fills with copies.
• Separate viewer: Outside records shown in a pop-up window that clinicians never open add cost without changing care.
• Purpose drift: A team built for treatment starts sending payment or operations queries without updating consent rules or audit fields.
• Unanswered queries: An organization that sends queries but never configures responses breaks its flow-down terms.
• Thin audit: Logs that record the query but not the purpose, the user or the documents returned cannot answer a reviewer's question.

Each of these is cheaper to design out than to fix after go-live. Patient matching and deduplication in particular depend on your own data quality, so test them on real records, not on vendor sample files.

Checks before the first live query

• Matching test: Run a sample of real patients with name changes, hyphenated surnames and moved addresses through the QHIN's test environment.
• Document handling: Confirm how C-CDA sections map into problems, medications and allergies, and which ones need clinician reconciliation.
• Response path: Prove your system answers inbound queries within the time the QHIN expects.
• Audit review: Pull one transaction end to end and check that purpose, user, patient and returned documents are all recorded.

How Agnotic can help

A TEFCA connection is only as useful as the matching, storage and chart integration behind it. Agnotic Technologies builds that layer as the client's engineering team: the gateway to a QHIN or Participant, patient matching tuned to your demographics, C-CDA and FHIR parsing, deduplication and the audit trail.

You choose the network partner and own the policy decisions on purposes and responses. Agnotic connects your systems to that partner and builds the screens that put outside records in front of clinicians.

Sources

• ASTP/ONC: Trusted Exchange Framework and Common Agreement (TEFCA), exchange purposes and RCE
• 45 CFR Part 172: Trusted Exchange Framework and Common Agreement (Cornell LII)
• ASTP/ONC: HHS announces milestone of one billion health records exchanged through TEFCA (26 June 2026)
• The Sequoia Project: TEFCA Recognized Coordinating Entity