TEFCA and FHIR: What It Takes to Connect

Every explainer about TEFCA tells you what it is. Almost none tell you what you have to build.

That gap has become expensive. TEFCA carried roughly 10 million records in January 2025. By February 2026, the figure was near 500 million, and the rules governing who must answer a query have tightened three times since. The most recent change took effect on 3 August 2026 and widened the set of organizations obliged to respond to treatment requests.

The framework is written in the language of governance. The work lands on engineering. This page covers that layer: how TEFCA and FHIR relate, what connecting through a QHIN demands of your systems, which exchange path to choose, and what changed this year that your roadmap may not reflect.

TEFCA in One Page

TEFCA, the Trusted Exchange Framework and Common Agreement, was created by the 21st Century Cures Act in 2016 to give the United States one legal and technical foundation for exchanging health data across organizations.

It has two parts. The Trusted Exchange Framework sets principles covering privacy, security, standardization, and accountability. The Common Agreement is the binding contract that Qualified Health Information Networks sign, fixing their responsibilities, the permitted uses of data, and their compliance obligations.

QHINs are the operational layer. They are established health information networks that met the technical and cybersecurity criteria, signed the Common Agreement, and now interconnect. Once your organization joins one as a Participant or Subparticipant, you can exchange with any organization connected to any other QHIN. You build one connection instead of many.

Eleven QHINs are designated as of July 2026: CommonWell Health Alliance, eClinicalWorks PrismaNet, eHealth Exchange, Epic Nexus, Health Gorilla, Kno2, KONZA, MedAllies, Netsmart, Oracle Health Information Network, and Surescripts. The list changes because applications are accepted on a rolling basis. Check the current roster on the RCE site rather than trusting any article, including this one.

The Sequoia Project serves as the Recognized Coordinating Entity, running QHIN applications, technical onboarding, the directory, and the Standard Operating Procedures that turn the Common Agreement into daily practice. Policy oversight sits with the Assistant Secretary for Technology Policy and the Office of the National Coordinator for Health Information Technology, now written ASTP/ONC.

That is the civics. Here is the part that costs money.

TEFCA and FHIR: How the Two Relate

The most common confusion we hear is that TEFCA and FHIR are alternatives, or that adopting one satisfies the other. They answer different questions.

FHIR is a data standard. It defines what a patient record looks like on the wire and how a system asks for it, at the level of individual data elements rather than whole documents. TEFCA is a trust framework. It defines who you are permitted to ask, under what legal terms, and for which purposes.

You can run FHIR without TEFCA, and most organizations already do, through payer APIs, SMART on FHIR apps, and point-to-point integrations governed by individual contracts. You can run TEFCA without FHIR, and in the early phase most exchanges did exactly that, using document-based transactions built on IHE profiles and C-CDA.

The two meet in Facilitated FHIR, which lets organizations transact directly with other TEFCA participants without a prior connection in place. It works because the RCE Directory Service provides scalable endpoint discovery, the Common Agreement supplies consistent policy, and the QHIN Technical Framework supplies the technical rules. Patient discovery still runs through a QHIN query. The data retrieval can then go straight to a FHIR-enabled organization that has published an endpoint in the directory.

If your platform has no FHIR layer today, TEFCA participation does not force you to build one immediately. It does make that build inevitable. Teams who scope the two as one programme rather than two spend less, which is the work our FHIR integration services cover.

What Connecting Through a QHIN Requires

Joining TEFCA is not a certification you pass. It is a set of connections, registrations, and standing obligations your systems have to carry.

You choose a role. Most organizations join as a Participant of a QHIN, or as a Subparticipant of a Participant. Under Common Agreement v2.0, a participant may connect through more than one QHIN. Becoming a QHIN is a different order of commitment, with cybersecurity certification and full technical onboarding.

You register in the RCE Directory. Every entity is published there with the identity and endpoint metadata other nodes need to authenticate you, including Organization ID and Home Community ID. Stale endpoints fail quietly, and you hear about it from a partner rather than a monitor.

You meet the USCDI floor, and that floor moved. Data created or captured and sent on or after 31 December 2024 was expected to conform to USCDI v1. From 1 January 2026, data must conform to USCDI v3 data classes, elements and vocabulary requirements. If your mapping work was scoped against v1, it is now behind, and the gap usually sits in terminology and in data classes the source system never captured cleanly.

You decide about delegation. A principal may authorize a delegate to query or push on its behalf, provided a written agreement is in place. Both parties sign the Framework Agreement and appear in the directory.

You take on identity assurance. Individual Access Services carry identity proofing and patient matching obligations that most clinical systems were never designed to meet. The IAS Exchange Purpose Implementation SOP v3.0 took effect on 3 August 2026, and it preserves the responder’s ability to verify third-party requests for access. This is the requirement that surprises product teams late.

You accept enforcement. Violations of the SOPs are breaches of the Common Agreement, with codes of conduct, escalation, and attestation codified under 45 CFR Part 172, effective 15 January 2025.

Organizations that move fastest treat TEFCA as an extension of an interoperability roadmap they already have. If you are still building that roadmap, our healthcare interoperability solutions set out the architecture decisions that come first.

Document Exchange or FHIR: Choosing Your Path

The QHIN Technical Framework keeps a baseline of required IHE transactions and adds FHIR on top. Both paths are valid. They cost different things.

QTF v2 sets three FHIR requirements: security through the HL7 UDAP Security for Scalable Registration, Authentication and Authorization Implementation Guide, FHIR Provenance, and the HL7 FHIR US Core Implementation Guide v3.1.1. FHIR Release 4 is enabled for all use cases. Three further implementation guides are supported but not required: HL7 Bulk Data Access v1.0.1 for large volume transfers, IHE Mobile access to Health Documents v4.2.0 for document repositories, and HL7 Da Vinci Payer Data Exchange v1.0.0 for provider-to-payer flows.

The decision usually turns on one question: is TEFCA the only reason you would build FHIR? For most vendors, payers, and larger provider organizations, the answer is no, and building the FHIR layer first serves several obligations at once. If the answer is yes and you have working IHE infrastructure, document exchange is a defensible starting position. Plan the FHIR path anyway, because the optional guides above are where payer and analytics use cases are heading.

Exchange Purposes and What You Must Answer

TEFCA permits exchange for six defined Exchange Purposes: Treatment, Payment, Health Care Operations, Public Health, Government Benefits Determination, and Individual Access Services. QHINs support all six technically. Responding organizations answer a narrower set, and that set is widening on a published schedule.

Treatment runs on two codes. T-TREAT is the general code, where a response is optional. T-TRTMNT is TEFCA Required Treatment, where a response is mandatory and automated. Version 2.0 of the Treatment XP Implementation SOP, published on 8 July 2026 and effective 3 August 2026, removed the requirement to match a named provider category. Any vetted Covered Entity Health Care Provider, or its delegate, now qualifies for the required-response tier. The SOP also sets out in detail which activities count as being in connection with treatment, naming referrals, provider consultations, prescription fills, medication reconciliation, and care transitions.

If your organization previously sat outside the named categories and concluded the required-response tier did not apply to you, that conclusion expired last week.

Individual Access Services also carries required response, under the IAS SOP v3.0 effective the same day.

Health Care Operations moved on a transition timetable. The initial SOP set an eighteen-month clock from publication, after which responding nodes must answer queries for Level 2 HCO codes, covering care coordination and case management, quality reporting, and HEDIS reporting. HCO XP Implementation SOP v2.0 took effect on 15 February 2026 alongside Exchange Purposes SOP v5.0, adding codes and flexibility for these use cases.

Government Benefits Determination became live practice rather than theory. ASTP/ONC, the Social Security Administration, and the RCE released the Government Benefits Determination XP Implementation SOP, with QTF v2.1 updated so that government requests route to organizations known to hold the relevant records instead of querying the whole network. SSA connected through the eHealth Exchange QHIN in early 2026 and expects disability claims processing time to fall by more than half in many cases.

Public health exchange shows the mechanics. A public health authority or its delegate initiates a query or push carrying an XP Code such as T-PH-ECR for electronic case reporting or T-PH-ELR for electronic laboratory reporting, with jurisdiction metadata and date range criteria attached. The responding node returns standardized content.

For a product team, this translates into concrete work: parsing XP Codes, enforcing purpose-based access control, distinguishing required from optional response paths in your own logic, logging what was released and to whom, and returning content that meets the current USCDI version rather than whatever the database happens to hold.

The Information Blocking Exception and What It Obliges

The final rule issued on 16 December 2024 codified TEFCA definitions and structure in 45 CFR Part 172 and created a TEFCA-specific exception within the information blocking regulations, effective 15 January 2025.

TEFCA participation therefore sits inside your information blocking posture, not beside it. Declining to answer a request that TEFCA obliges you to answer is a compliance question rather than a product prioritization question. At the ASTP/ONC annual meeting in February 2026, officials signalled sustained attention to information blocking with participation from the FTC, DOJ and the HHS Office of Inspector General, and invited comment on the HTI-5 proposed rule.

Build the audit trail while you build the connection. Producing evidence later costs more than capturing it as you go.

Where Teams Get Stuck

The failures we see are rarely about the framework. They are about the data underneath it.

Legacy systems hold clinical data in shapes that predate USCDI, so conforming to US Core exposes gaps in coding, terminology, and completeness that nobody had to confront while the data stayed internal. The move from USCDI v1 to v3 widened those gaps for teams who scoped their mapping work in 2024. Identity and endpoint management gets treated as configuration rather than as a system with an owner, and directory entries drift. Purpose-based access control gets bolted on after the exchange works, which means building it twice. And FHIR work gets scoped as a translation layer over an unchanged core, which holds until the first partner asks for something the core cannot express.

None of this makes the timeline long by default. On a FHIR enablement completed in six weeks for an ambulatory EHR vendor, the decisive finding came out of discovery: the existing HL7 v2 infrastructure did not need replacing. A FHIR R4 layer on Azure went up while Mirth Connect channels mapped the live ADT, ORU and ORM feeds to Patient, Encounter, Observation, Practitioner and Condition resources, with SMART on FHIR authentication configured before endpoint development began and Inferno validation before deployment. Running server setup and translation in parallel, rather than in sequence, is what compressed the schedule. We worked through a FHIR enhancement for an EHR platform separately, where the constraint was the product architecture rather than the standard. The variable is how much data groundwork was already done.

Timeline and Current State

Frequently Asked Questions

Is TEFCA a federal regulation?

Partly. TEFCA itself is a framework created under the 21st Century Cures Act and operated through a private contract, the Common Agreement, that QHINs sign with the Recognized Coordinating Entity. The federal rule issued in December 2024 codified TEFCA’s definitions and structure in 45 CFR Part 172 and created a TEFCA-specific exception in the information blocking regulations. So participation is voluntary, and the obligations that follow participation are enforceable.

What is the difference between TEFCA and FHIR?

FHIR is a data standard that defines how health data is structured and requested. TEFCA is a trust framework that defines who you may request it from, under what legal terms, and for which purposes. Neither replaces the other, and Facilitated FHIR is where they meet.

Does TEFCA require us to use FHIR?

No. The QHIN Technical Framework keeps a baseline of required IHE document transactions, so an organization can participate through document exchange alone. FHIR is enabled rather than mandatory. Most organizations building for TEFCA find they need a FHIR layer for other obligations anyway.

What are the TEFCA exchange purposes?

Six: Treatment, Payment, Health Care Operations, Public Health, Government Benefits Determination, and Individual Access Services. QHINs support all six technically. Responding organizations answer a narrower set, and that set has widened three times in the past year.

Do we have to respond to every TEFCA query?

No. Response is required for TEFCA Required Treatment (the T-TRTMNT code) and for Individual Access Services, and Health Care Operations Level 2 codes moved onto a required-response timetable. The general treatment code, T-TREAT, remains optional. The distinction between required and optional response has to be built into your own access logic, not assumed at the network layer.

Which USCDI version applies to TEFCA exchange?

USCDI v3, for data created or captured and sent from 1 January 2026 onward. Earlier guidance pointed to v1, so mapping work scoped before 2026 is worth re-checking.

What does TEFCA compliance involve in practice?

Choosing a QHIN and a role, registering accurate endpoint and identity metadata in the RCE Directory, meeting the USCDI floor, enforcing purpose-based access control, handling identity assurance for individual access, and keeping an audit trail of what was released and to whom.

Find Your Starting Point

If TEFCA is on your roadmap and you are working out what it costs, the first useful step is not a vendor conversation. It is an honest look at two things: whether your data meets USCDI v3 without a rebuild, and whether the FHIR layer TEFCA needs is a layer you needed anyway. Most teams find the answer to the second question changes the shape of the first.

A short conversation with our engineering team will usually make that clear, and there is no cost to working it out.

[Talk to an engineer] or write to us at info@nalashaa.com

The following two tabs change content below.

• Bio
• Latest Posts

Priti Prabha

Priti is a marketing enthusiast with a keen interest in digital advancements. She finds immense joy in crafting impactful content that addresses challenges and spreads awareness in the healthcare sector. Her work consistently showcases how technology aligns with value-based care to improve patient outcomes and operational efficiencies. When not immersed in content writing, Priti enjoys geeking out on pop music or delving into the latest tech magazines.

Latest posts by Priti Prabha (see all)

• Telemedicine Software Solutions: How to Choose, Integrate, or Build One  - August 6, 2026