TEFCA grew fast in 2025, but payer exchange is still optional

TEFCA grew fast in 2025, but payer exchange is still optional. The national framework for health information exchange, which went live in December 2023, had shared more than 474 million documents across more than 70,000 sites by February 2026, according to the Assistant Secretary for Technology Policy. A year earlier, the total was closer to 10 million.

That growth has come mostly from the uses TEFCA was built around first, clinicians querying for records to treat patients and individuals requesting their own information. The rules reflect those priorities. Under TEFCA’s current exchange purposes procedure, participants that are health care providers must answer queries labeled for required treatment, and every responding node must answer queries for individual access. A query for payment, by contrast, may be answered. A query for health care operations, including quality measurement and care coordination, should be.

For health plans, that distinction matters more than the headline numbers. This analysis explains where TEFCA stands in early 2026 and why payer queries carry weaker guarantees. It also places CMS’s separate interoperability framework alongside it and sets out what payers can expect this year.

Key takeaways

• Volume is real. More than 474 million documents had been shared through TEFCA by February 2026, with 11 Qualified Health Information Networks designated since launch.
• Obligations are uneven. Individual access queries must be answered, as must required treatment queries sent to provider nodes. Payment queries may be answered, and operations queries should be.
• Payers get the weakest guarantee. The exchange purposes that payers use most carry no obligation to respond, partly because HIPAA treats those disclosures more cautiously than treatment.
• Joining has a cost for payers. A payer that responds through TEFCA must answer individual access queries, which brings identity and privacy work with it.
• A parallel federal track is running. CMS’s voluntary interoperability framework, launched in July 2025, has its own aligned networks and FHIR expectations, and the first payer went live on one in March 2026.
• 2026 is about trust and FHIR. Federal priorities for the year focus on identity proofing for individual access and on moving more exchange to FHIR.

How TEFCA works

The 21st Century Cures Act of 2016 directed the federal government to build a trusted exchange framework so that networks could connect to each other under common rules, rather than through hundreds of separate agreements. The result has 3 layers. The Common Agreement sets the legal terms, and a Recognized Coordinating Entity, The Sequoia Project, operates the framework under contract with federal health IT officials. Qualified Health Information Networks, or QHINs, connect to each other and bring their own participants and subparticipants along.

A typical query works like this. A clinician’s system, connected through a participant, sends a request for a patient’s records. Its QHIN passes the request to the other QHINs, which pass it to their participants, which search for matching patients and return what they hold. Today most of that exchange uses document-based standards, with clinical summaries returned as structured documents. FHIR-based exchange, in which systems request specific data elements through APIs, is growing but is still the smaller share. The Common Agreement has been revised since launch, notably to support FHIR-based exchange.

TEFCA defines 6 exchange purposes, listed in the table further down, and each query carries a code that says which purpose it serves. The rules for whether a recipient must answer depend on that code.

Participation is voluntary. But federal rules give it weight. The information blocking regulations include a TEFCA manner exception, adopted in the HTI-1 final rule, under which an actor that offers to share information through TEFCA can in some circumstances satisfy a request that way rather than in the manner the requester asked for.

How fast it grew

TEFCA’s early months were slow. The framework went live with its first QHINs in December 2023 and spent much of 2024 onboarding participants and settling procedures. Volume climbed sharply in 2025.

Sources are listed in each row. Measures differ in what they count, so the rows are not strictly comparable.

TEFCA designated 3 QHINs in 2025, including Netsmart in August, bringing the total since launch to 11, according to TechTarget’s March 2026 review of interoperability. The same review reported that the volume of records exchanged was approaching 600 million in early March 2026.

A document in these counts is usually a clinical summary returned in response to a query, such as a summary of a visit or a hospital stay. A single patient query can return several. The counts therefore measure how much is moving, not how many patients or decisions were affected.

Federal partners have also begun to join. The Indian Health Service became the first federal partner to sign with a QHIN, and the Social Security Administration joined for government benefits determination, according to the February 2026 federal presentation.

What the public numbers do not show is the mix. The framework’s technical rules require QHINs to report transaction volumes by exchange purpose, but no breakdown by purpose has been published. Readers cannot yet tell how much of the growth is treatment and how much, if any, is payment or operations.

What participants must answer

The rules on responses are set out in TEFCA’s exchange purposes procedure, updated in December 2025. They use standards language, in which must is a requirement and should a recommendation.

From The Sequoia Project’s Exchange Purposes SOP, version 5 (December 2025). Exceptions apply, including when the requested information is not required information under the framework.

The table shows 2 features worth noting. First, the framework has split treatment in 2. An ordinary treatment query should be answered, while a query under the required treatment code must be answered by provider nodes. Second, the strongest obligation in the framework belongs to individual access. Any responding node, whatever kind of organization runs it, must answer a properly authenticated individual’s request for their own information.

TEFCA guarantees an answer to a patient asking for their own records. It does not guarantee an answer to a health plan asking for anything.

What this means for payers

Health plans use TEFCA, if at all, mainly for payment and health care operations, such as gathering documentation for a prior authorization or closing quality gaps for HEDIS measures. These are exactly the purposes where a response is optional or only recommended.

The weaker obligation has a basis in HIPAA. Disclosures for treatment are exempt from the Privacy Rule’s minimum necessary standard, so a provider answering a treatment query can share a full clinical summary without deciding which parts the requester needs. Disclosures for payment and health care operations are subject to that standard, and disclosures to another covered entity for its operations are permitted only for certain purposes and when both have a relationship with the patient. A provider answering a payer query has to make judgments that a treatment query does not require. A framework that compelled those answers would be compelling those judgments too.

That shapes what a payer can build on TEFCA. A plan can send a payment or operations query and may get useful results, especially from organizations that have decided to answer. It cannot design a process that depends on a response, because no rule requires one. A provider organization weighing whether to answer payer queries has real reasons to hesitate, from the work of reviewing what is shared to the risk of sharing more than the minimum necessary.

Consider a plan reviewing a request to extend an inpatient stay. It needs the latest progress notes and the discharge plan. Through TEFCA, it could send a payment or operations query to the hospital’s network. If the hospital answers, the plan gets clinical summaries that may or may not contain the notes it needs. If the hospital does not, nothing in the framework says it must. The plan is back to calling or faxing, against a decision deadline that keeps running.

The obligations run the other way as well. A payer that joins TEFCA as a responding node takes on the duty to answer individual access queries. That means matching an individual’s identity to the right member record and returning the information in a usable form. Those are capabilities payers have been building for the CMS Patient Access API, but they now have to work across a network, not only through the plan’s own app connections.

Where TEFCA can help payers now

None of this makes TEFCA useless for plans. Several payer uses produce value even when only some organizations answer.

• Quality measurement. HEDIS and other quality programs already rely on chart review for measures that claims cannot answer. A query that returns clinical summaries from some providers replaces some of that chart chasing, and every response that arrives is one fewer record request.
• New member history. When a member joins mid-year, records from providers the plan has never contracted with can help with care management before the first claim arrives.
• Care coordination. After an admission, a plan’s care managers can use operations queries to find recent summaries from facilities outside the plan’s direct connections.
• Appeals and reviews. For a decision that is already in reconsideration, additional clinical history from other organizations can support a fuller review, without the decision depending on it.

For the core payer workflows, the more dependable federal path in the near term runs through CMS’s January 2024 interoperability and prior authorization rule, not through TEFCA. That rule requires impacted payers to build new FHIR APIs by January 2027, including a Prior Authorization API, with specific obligations attached. TEFCA can complement those APIs. It does not replace them.

The CMS framework runs alongside

In July 2025, CMS announced a voluntary interoperability framework at a White House event, with more than 60 companies pledging to deliver results in the first quarter of 2026. At launch, 21 networks pledged to meet the framework’s criteria and become CMS Aligned Networks, and 30 companies pledged to build tools for patients. The framework expects participants to provide or facilitate access to data through FHIR APIs, with an emphasis on individuals and the apps they choose.

The relationship between the 2 tracks is not fully settled. Several organizations operate in both, as QHINs and as networks pledging to align with CMS. CMS’s announcement did not describe how the framework would interact with TEFCA. In practice, the 2 are converging on the same technical direction, FHIR-based exchange with strong identity verification, while keeping separate governance.

The first payer milestone under the CMS framework arrived in March 2026, when Clover Health became the first payer to go live on a CMS Aligned Network, according to TechTarget. A single payer is a start, not a trend, but it shows that the framework’s payer pathway has moved from pledge to production.

The 2026 agenda

The February 2026 federal update laid out 4 priorities for TEFCA this year.

• Trusted individual access. Increase trusted responses to individual access queries, including work on identity proofing at the IAL2 level and on how self-asserted demographic data can be used.
• Compelled treatment responses. Ensure that every HIPAA covered health care provider can compel a response for treatment, through better vetting and an expanded required treatment response.
• Stronger onboarding. Update the onboarding and designation procedure to require upfront and periodic review of the people responsible for participants and subparticipants.
• More FHIR. A revised facilitated FHIR implementation procedure took effect in March 2026, and an updated procedure for individual access providers, which requires them to disclose publicly whether they both send and receive data or only request it, is scheduled to take effect later in the month.

Procedures for health care operations and treatment were also revised in early 2026, with the operations procedure adding codes for specific operations uses. A government benefits determination procedure was published in December 2025, supporting the Social Security Administration’s participation.

None of these priorities addresses payer exchange directly. That is not a criticism. The framework is building trust where the stakes are clearest first. But payers should read the agenda as a signal that payment and operations will not become required response purposes in 2026.

Where Redlake stands

We build tools health plans use in utilization review, and nearly every review depends on clinical documentation that a plan does not hold. Much of it still arrives by fax or portal upload, a problem we wrote about in February. TEFCA could eventually change that. Today it cannot be the backbone of a review process, because a plan’s query for documentation may go unanswered.

Our view is that plans should treat TEFCA as a useful source and design around its limits. That means using request-specific exchange, such as the prior authorization and documentation APIs CMS has required for January 2027, for anything a decision depends on, and using TEFCA queries to fill gaps or reach organizations with which the plan has no direct connection. Whatever the channel, every fact used in a decision should carry its source, so a reviewer can see where it came from and a plan can show it later.

Data quality matters as much as data access. A clinical summary that arrives through TEFCA can be incomplete or out of date. A review built on exchanged data needs to show which document each fact came from and when it was created, so the reviewer can judge it rather than assume it.

The right measure of TEFCA for a plan is the one we proposed for any standard, which manual requests it retires. A plan that joins should count, by workflow, how many record requests it used to send by fax or phone and how many it now satisfies through TEFCA queries.

For plans deciding whether to join TEFCA now, the practical checks are concrete.

• Identify the QHIN the plan would connect through and what its participants are willing to answer for payment and operations queries.
• Confirm that the plan can answer individual access queries across a network, with identity matching it trusts.
• Choose operations uses that produce value even with partial response rates, such as HEDIS data collection or transitions of care.
• Decide how to measure what comes back, so the plan can tell whether TEFCA is retiring any manual requests.

What to watch in 2026

• Volume by purpose. Whether the framework publishes a breakdown of transactions by exchange purpose, which would show how much payer exchange is actually happening.
• Required treatment responses. How quickly the expanded required treatment response reaches every covered provider.
• Individual access at scale. Whether IAL2 identity verification and the new disclosure rules for individual access providers increase the share of individual queries that get trusted responses.
• CMS Aligned Networks. How many networks and payers go live in 2026, and whether CMS clarifies how its framework relates to TEFCA.
• Payer-facing procedures. Whether any payment or operations sub-purpose moves from may or should to must.
• The January 2027 API deadline. Whether payers building Provider Access and Payer-to-Payer APIs choose to route any of that exchange through TEFCA.

About this analysis

Basis. The TEFCA material comes from the February 2026 federal update and from procedures and calls published by the Recognized Coordinating Entity. CMS’s July 2025 announcement and TechTarget’s March 2026 review describe the parallel CMS framework.

Data notes. Volume figures come from different sources and count different things, from documents to connected sites. We report each as its source described it. No breakdown of TEFCA volume by exchange purpose was public at the time of writing. The HIPAA discussion summarizes the Privacy Rule’s minimum necessary standard and its rules for disclosures for health care operations, and is not legal advice.

Sources. Assistant Secretary for Technology Policy, TEFCA updates presentation (February 2026). The Sequoia Project, RCE information call (January 2026) and Exchange Purposes SOP version 5 (December 2025). The Sequoia Project, news announcements (2025). CMS, press release on the interoperability framework (July 2025). CMS, interoperability and prior authorization final rule fact sheet (January 2024). TechTarget (March 2026).

Frequently asked questions

What is TEFCA?

The Trusted Exchange Framework and Common Agreement is a national framework, created under the 21st Century Cures Act, that lets health information networks exchange data with each other under common legal and technical rules. Qualified Health Information Networks connect to each other and to their own participants.

How many QHINs are there?

TEFCA had designated 11 QHINs since it went live in December 2023, according to TechTarget’s March 2026 review, including 3 designated in 2025.

Do TEFCA participants have to answer payment queries?

No. Under the exchange purposes procedure updated in December 2025, responding nodes may answer payment queries but are not required to. Health care operations queries should be answered, which is a recommendation rather than a requirement.

Can a health plan join TEFCA?

Yes. A plan can join as a participant or subparticipant through a QHIN. If it responds to queries, it must answer individual access requests. It can also send payment and operations queries, which other participants may or should answer depending on the purpose.

How does the CMS interoperability framework relate to TEFCA?

They are separate voluntary efforts. CMS’s framework, announced in July 2025, defines criteria for CMS Aligned Networks built around FHIR APIs. Some organizations participate in both. CMS has not described a formal relationship between the 2.