What Is TEFCA and How Does It Change EHR Data Exchange for Clinics?

TL;DR

• TEFCA (Trusted Exchange Framework and Common Agreement) is the ASTP/ONC-coordinated national framework, administered by The Sequoia Project as Recognized Coordinating Entity (RCE), for exchanging health data across networks under one legal and technical rulebook.
• QHINs sign the Common Agreement and move data between networks. Clinics almost never sign it directly; they connect as Subparticipants through their EHR vendor or regional HIE.
• Participation is voluntary today. ONC certification and the information blocking rule (45 CFR Part 171) don't require TEFCA connectivity, but ASTP and CMS rulemaking language has repeatedly signaled that TEFCA-adjacent pathways will carry more weight for public health and payer-to-payer reporting over time.
• TEFCA doesn't replace SMART on FHIR APIs. It's a query-based discovery layer for broad, cross-network lookup; FHIR APIs remain the standard for point-to-point, app-level integration.
• The practical vendor question is specific: which QHIN, live in which markets, under which Exchange Purpose, and what happens when a query returns a bad patient match. Vague answers here are the clearest early signal of an immature integration.

What is TEFCA, and what problem does it actually solve?

TEFCA is a nationwide governance and technical framework, established under the 21st Century Cures Act, that defines one common set of legal terms, privacy and security requirements, and technical standards for cross-network health information exchange. Before TEFCA, exchange was fragmented across regional HIEs, vendor networks (Epic's Care Everywhere, CommonWell), and state systems, each with separate participation agreements. A clinic in one network often couldn't pull records from a hospital in another without a bilateral deal between the two.

TEFCA's Common Agreement replaces bilateral negotiation with a shared set of obligations: permitted purposes for exchange, minimum technical capabilities, and required response behavior, all governed through a layered structure of the Framework Agreement itself, a set of Standard Operating Procedures (SOPs) that specify operational details like performance and privacy requirements, and the QHIN Technical Framework (QTF), which defines the actual transaction specifications QHINs must support. A "Flow Down" provision in the Common Agreement requires QHINs to bind their Participants, and Participants to bind their Subparticipants, to equivalent obligations. That structure is why a clinic can inherit TEFCA obligations and benefits without ever negotiating anything directly.

TEFCA is not an EHR, a single database, or a documentation mandate. It's a governance layer that sits above existing networks and defines how they interoperate.

How is this different from FHIR-based interoperability?

TEFCA governs who can exchange data and under what legal terms across networks. FHIR (and SMART on FHIR), the HL7 standard underlying most modern health IT integration work, defines the technical format and API pattern for that data once a connection exists. They're complementary, not competing.

FHIR APIs required under ONC certification (the Patient Access API, provider-access concepts referenced in CMS interoperability rules, and Bulk FHIR for population-level pulls) define a point-to-point relationship: a specific app requests specific data from a specific EHR endpoint. TEFCA is built for broad, query-based discovery across many organizations at once, closer to the older IHE profiles (XCA, XCPD), though ASTP has been pushing TEFCA toward FHIR-based query and response, sometimes called Facilitated FHIR. The distinction that matters operationally: FHIR APIs are what you use to build a specific integration; TEFCA is what lets a clinician ask "does anyone in the country have records on this patient" without your practice having built a bilateral interface with every hospital that patient has ever visited.

How does a clinic actually connect to a QHIN?

Below each QHIN sit Participants (larger health systems, EHR vendors, health information networks), and below Participants sit Subparticipants, which is where most ambulatory practices land. Your EHR vendor or regional HIE becomes a Participant or connects to a QHIN, and your organization inherits that connectivity without negotiating the Common Agreement yourself.

This means the decision to "join TEFCA" is usually made for a clinic by its EHR vendor, not by clinic IT leadership. That's exactly why TEFCA readiness belongs in vendor evaluation rather than as a standalone IT project.

Do clinics have to participate to meet ONC requirements?

No. QHIN participation is voluntary today. ONC certification criteria and the information blocking rule (45 CFR Part 171) don't require TEFCA connectivity. What certified EHR technology must support are specific standards: USCDI data classes, the Patient Access API and related FHIR-based APIs, and exchange capabilities tied to the ONC Health IT Certification Program, expanded further under HTI-1 and subsequent rulemakings. These obligations are framed around standards and information blocking, not TEFCA membership.

Two things are true simultaneously. Information blocking obligations can be satisfied through non-TEFCA channels: direct interfaces, existing HIEs, standards-based APIs. But ASTP and CMS have both signaled, through rulemaking commentary, that TEFCA participation may increasingly function as a preferred or streamlined path to demonstrate broad interoperability, particularly for public health reporting and payer-to-payer exchange. HIMSS interoperability surveys in recent years have consistently found that provider organizations rank patient matching and data completeness, not network availability, as the largest practical barrier to using cross-network exchange once it's technically live. Treat "not currently mandatory" as a description of today's rule, not a permanent guarantee, and ask vendors about their TEFCA roadmap even when it isn't yet a hard requirement.

What exchange purposes apply, and where does obligation actually sit?

The Common Agreement defines specific Exchange Purposes, and obligations differ by purpose: Treatment, Payment, Health Care Operations, Public Health, Individual Access Services, and Government Benefits Determination.

Treatment is the dominant use case for ambulatory clinics: a clinician needs records on a patient with history elsewhere. Under the Common Agreement, organizations responding to a Treatment-purpose query generally cannot refuse to respond because they compete with the requester, which directly reinforces information blocking prohibitions. Health Care Operations and Payment carry additional minimum-necessary restrictions, and clinics relying on these purposes for quality reporting or value-based contract reconciliation should understand that purpose-of-use tagging accuracy is enforced by the requesting organization's Participant or Subparticipant agreement, meaning compliance risk for a mistagged query sits with the requester, not the network carrying it.

Where TEFCA actually breaks in practice

The gap between "TEFCA-connected" and "clinically useful" shows up in three recurring failure modes, and none of them are hypothetical:

1. Patient matching errors. Cross-network patient identity matching remains an unsolved problem industry-wide. Published evaluations in the health informatics literature, including work referenced in JAMA and JAMIA over the past several years, have repeatedly identified identity matching as the leading source of both false negatives (missed records that exist) and false positives (records attached to the wrong patient) in query-based exchange. A query that silently returns nothing because of a name or DOB mismatch looks identical, from the clinician's screen, to a query that correctly found no outside records.
2. Document dumps instead of discrete data. A query can return a scanned discharge summary PDF rather than structured lab values or medication history. That's compliant, but it doesn't populate a flowsheet or a CGM trend view, it just adds another document a clinician has to open and read during a visit.
3. Regional and QHIN-specific coverage gaps. Two clinics with the same EHR vendor can have meaningfully different real-world TEFCA experiences depending on which QHIN their vendor connects through and how much of that clinic's referral network has actually joined. A vendor being "TEFCA-connected" nationally doesn't guarantee coverage in any specific metro area or specialty referral pattern.

The implementation lesson: TEFCA connectivity should be evaluated the same way you'd evaluate any interface, by asking what percentage of actual outside-care encounters for your patient population return usable data, not by asking whether the checkbox is technically true.

A decision rule for vendor evaluation

Before treating TEFCA as satisfied, apply one test: pull a list of your last 20 referred-out or hospitalized patients and ask the vendor to show, in production, what their platform actually returned for those specific patients through TEFCA or QHIN exchange. If the vendor can't produce this for your market, the connection is a roadmap item, not a working capability, regardless of what the sales materials say.

How does this affect EHR vendor selection for multi-site practices?

For a multi-site endocrinology or primary care group, TEFCA status should be an explicit line item, because it determines how much external patient history clinicians get automatically versus how much IT has to build and maintain manually.

A practice referring frequently outside its immediate HIE region benefits disproportionately from a vendor already live as a Participant, or through a Participant, with one or more QHINs. Without that, IT teams manage a patchwork of bilateral interfaces, manual record requests by fax or portal, and inconsistent access depending on which health system a patient happened to use. That patchwork is expensive and creates real clinical risk: the ADA Standards of Care has, in recent editions, emphasized timely integration of glucose and CGM data into clinical decision-making, and a diabetes patient's outside labs or hospitalization summary arriving after the next visit rather than before it undermines exactly the kind of continuity the standard of care assumes.

The honest tradeoff is that TEFCA connectivity through a vendor doesn't guarantee national coverage. QHIN participation is still expanding, and query-based exchange returns documents and summaries that require clinical review, not a reconciled problem list. IT leaders should ask vendors: which QHIN, live in production or still onboarding, which exchange purposes are supported today, and how patient matching errors are handled, silently dropped or flagged for review.

What should IT admins ask a vendor before signing?

Ask for specifics, not intentions: which QHIN the vendor connects through, whether that connection is live in production for your market, and what happens when a query returns no data or an ambiguous patient match. A vendor stating "we support TEFCA" without naming a QHIN, a go-live date, or a supported exchange purpose is describing a roadmap item.

Ask for a reference site already using the connection in production. Ask how patient matching discrepancies surface to clinicians, silently dropped or flagged for review. Ask whether connectivity extends to your specific specialty workflows, since a query returning a scanned discharge summary is useful but different from returning structured, discrete lab or medication data that lands directly in a flowsheet or CGM review screen.

Thyra treats TEFCA and broader interoperability as infrastructure that has to work reliably behind the scenes, not a marketing checkbox. Because Thyra's Smart Inbox, Longitudinal AI Scribe, CGM viewer, and orders share the same underlying patient context, records pulled in through any exchange channel, direct interface, regional HIE, or QHIN connection, need to land where clinicians actually look during the visit, not in a separate repository requiring a second login.

Frequently Asked Questions

Is TEFCA the same thing as an HIE?

No. A regional HIE is a single network with its own agreement and governance. TEFCA is a national framework that lets HIEs, vendor networks, and QHINs exchange with each other under one common rulebook, connecting HIEs rather than replacing them.

If our EHR vendor is TEFCA-connected, are we automatically compliant with information blocking rules?

Not automatically. TEFCA connectivity helps demonstrate broad interoperability, but information blocking compliance under 45 CFR Part 171 is assessed on your organization's actual practices responding to requests, regardless of which network carries the data.

Does joining a QHIN cost the clinic money directly?

Most small to mid-size clinics don't pay a QHIN directly, since they connect as Subparticipants through their EHR vendor or HIE. Costs, if any, are usually embedded in vendor or HIE participation fees.

Will TEFCA participation become mandatory?

Not today. ASTP and CMS have signaled they may lean more on TEFCA-connected pathways for public health reporting and payer data exchange over time, but no universal mandate exists as of this writing.

How does TEFCA affect patients directly?

Individual Access Services is a defined Exchange Purpose under the Common Agreement, meaning patients or apps acting on their behalf may eventually request records through TEFCA-connected channels, extending existing patient access API rights with broader nationwide reach.

About the Author

This article was prepared by the clinical and product team at Thyra, an EHR built for endocrinology and primary care by Dr. Jean Jacques Nya Ngatchou. Thyra's approach to interoperability reflects day-to-day realities of chronic disease management, where CGM data, outside labs, and specialist notes need to reach the point of care reliably, not just theoretically through a compliant API.

References

• ASTP/ONC, Trusted Exchange Framework and Common Agreement (TEFCA) program materials, including QHIN Technical Framework and Common Agreement SOPs
• The Sequoia Project, Recognized Coordinating Entity resources on QHIN onboarding and Flow Down obligations
• HHS Office of the National Coordinator for Health Information Technology, Information Blocking regulations, 45 CFR Part 171
• ASTP/ONC HTI-1 Final Rule and related certification criteria documentation
• CMS Interoperability and Patient Access final rules and related FHIR API requirements
• HL7 FHIR and SMART on FHIR implementation specifications
• HIMSS interoperability survey findings on patient matching and data completeness barriers
• American Diabetes Association, Standards of Care in Diabetes, on technology integration and data continuity in chronic disease management
• Health informatics literature, including work published in JAMA and JAMIA, on patient identity matching in cross-network exchange