TEFCA — the Trusted Exchange Framework and Common Agreement — is the federal framework meant to let health information move between organizations under one set of rules rather than a patchwork of bilateral agreements, and QHINs are the network operators authorized to carry that exchange. For a company building healthcare software the practical question is narrower than the policy discussion suggests: you do not join TEFCA directly unless you intend to operate as or through a QHIN, and most software vendors reach it indirectly, through customers who are already participants. What changes for you is what becomes reachable — a participating customer can request records from other participants under a common legal framework, which can reduce the number of point-to-point interfaces you would otherwise build. What does not change is your existing Epic or Oracle Health work, which continues to operate exactly as it does now.

What Is TEFCA?

TEFCA is a set of legal and technical rules, established under the 21st Century Cures Act and administered by ASTP (the Assistant Secretary for Technology Policy, formerly ONC), that lets organizations exchange health information nationwide under one common agreement instead of negotiating separate bilateral data-sharing agreements with every partner. Rather than exchanging data directly with every other organization, participants connect through a QHIN, which handles the actual network routing. As of this writing, more than 23,000 organizations are live on TEFCA — QHINs, their Participants, and Subparticipants — representing over 100,000 unique connections to clinicians, hospitals, clinics, post-acute and long-term care facilities, and public health authorities, according to the RCE’s own published figures. The framework itself continues to evolve; several exchange-purpose implementation specifications took effect in August 2026 alone, which is exactly why this is a bad topic to write about once and never revisit.

What Is a QHIN?

A QHIN — Qualified Health Information Network — is an organization designated by the RCE (the Recognized Coordinating Entity, a role held by the Sequoia Project on ASTP’s behalf) to operate the actual exchange infrastructure other participants connect through. QHIN designation is a rolling, ongoing process, not a fixed list set once and left alone — verify the current designated list directly against the RCE’s own page before citing a count, since it changes as new applicants are accepted. As of this writing the designated QHINs include eHealth Exchange, Health Gorilla, Epic Nexus, MedAllies, KONZA, CommonWell Health Alliance, Kno2, eClinicalWorks, and Oracle Health Information Network. A software vendor almost never becomes a QHIN itself — that’s a significant operational and legal undertaking. What matters for most builders is simply that a customer’s existing EHR or exchange vendor may already be a QHIN Participant, which is the indirect path that actually applies to you.

Do You Actually Need to Care?

Here’s the honest scoping most coverage skips: there are two distinct positions relative to TEFCA, and they have almost nothing in common. Direct participation — becoming or connecting directly as a QHIN, Participant, or Subparticipant — is a real undertaking involving legal agreements, technical conformance testing, and ongoing compliance obligations; very few software vendors need to be here. Indirect exposure — building software for a customer whose EHR vendor or health system is already a QHIN Participant — is the far more common position, and here TEFCA is something that happens around your integration, not something you build against directly. If your customer is a hospital system already connected through Epic Nexus or another QHIN, TEFCA participation is largely their vendor’s and their own IT department’s concern. Your job is understanding what becomes reachable as a result, covered next — not implementing TEFCA’s technical specification yourself.

How TEFCA Relates to What You Already Built

TEFCA does not replace a direct Epic or Oracle Health interface, and it’s worth being direct about why: a point-to-point integration you’ve built — say, a FHIR-based interface into a specific customer’s Epic instance — gives you a defined, tested, contractually scoped connection to that one system. TEFCA exchange, by contrast, is broader and shallower: it can make records reachable across many participating organizations under a common legal framework, but the query-response pattern and the specific data returned depend on what the responding organization has made available, not on a contract you negotiated with them directly. The two are not competing approaches — they solve different problems. A direct interface is what you build when you need reliable, specific, high-volume exchange with one known partner. TEFCA exchange is what becomes available when you need occasional access to records from partners you don’t have a direct relationship with. Most production healthcare software will keep its direct interfaces and treat TEFCA reachability as an additional, complementary path — not a replacement for the integration work already covered in healthcare data integration beyond HL7 and FHIR.

Exchange Purposes and What They Permit

Verify the current exchange-purpose specifications directly against the RCE before relying on this section — these are actively revised. TEFCA currently defines six Exchange Purposes: Treatment, Payment, Health Care Operations, Public Health, Government Benefits Determination, and Individual Access Services (IAS). Each has its own implementation specification governing exactly what can be requested and under what obligations. Treatment, for instance, runs on two distinct codes as of the version effective August 2026 — a general code where a response is optional, and a “TEFCA Required Treatment” code where a response is mandatory and automated from any vetted covered-entity provider or its delegate. Individual Access Services — the purpose that lets a patient direct their own records to a third-party app — was also updated in 2026 to give patients more transparency into their sharing choices, and it involves its own identity-verification, patient-matching, and consent workflow. The purpose your use case falls under determines what you can request and what obligations attach to responding — this is not a detail to guess at.

Where TEFCA Actually Helps

The genuine value case: broader record reach without negotiating a bilateral agreement for every new partner. A health system that needs occasional records from an out-of-network provider, or a care-coordination product that needs to reach organizations outside its established interfaces, gets a real benefit from TEFCA’s common legal framework — one agreement, many potential connections, instead of a new contract negotiation each time. For a growing digital health company, that can genuinely reduce the number of point-to-point interfaces needed to reach an acceptable breadth of data sources over time.

Where It Doesn’t

Equally honest about the limits: TEFCA is not a substitute for a defined, tested, high-reliability interface with a specific partner you depend on daily. Participation coverage is still incomplete — not every organization you might want to reach is a live participant yet, even with more than 23,000 organizations on the network. Response latency and data completeness vary by responding organization; a query under TEFCA doesn’t guarantee a fast or complete answer the way a direct interface with an agreed SLA does. And the exchange-purpose framework means you can’t simply request anything for any reason — the request has to fit one of the defined purposes and satisfy that purpose’s specific requirements. Treat TEFCA as a supplementary reach mechanism, not core infrastructure for your product’s critical-path data flows.

Next Steps

For most healthcare software builders, TEFCA changes what’s reachable at the edges of your integration strategy, not the core interfaces you’ve already built and depend on. See information blocking and the Cures Act for the related regulatory obligation, and our broader EHR interoperability guide for how this fits the wider picture. If you’re scoping an integration strategy and trying to figure out where TEFCA genuinely helps versus where you still need a direct interface, our team can help you map it — reach out.