TEFCA basics
The Trusted Exchange Framework and Common Agreement (TEFCA) is the U.S. government’s attempt to create a nationwide, interoperable floor for health information exchange. Rather than building a single network, TEFCA establishes a legal, technical, and governance framework that allows existing networks to interconnect under common rules. In 2026, TEFCA is no longer a pilot concept; it is increasingly treated as a baseline expectation for national-scale data exchange.
At its core, TEFCA defines who can exchange data, for what purposes, and under what conditions. It standardizes exchange for Treatment, Payment, Health Care Operations, Public Health, and Individual Access Services, while leaving room for future expansion. The framework is administered by the Recognized Coordinating Entity (RCE), currently The Sequoia Project, which oversees onboarding, compliance, and dispute resolution. Importantly, TEFCA does not replace HIPAA, existing state privacy laws, or organizational policies. Instead, it layers uniform exchange obligations on top of them. Participants must meet minimum requirements for identity proofing, security controls, response times, and permitted uses of data. This creates predictability across networks, but also new compliance burdens.
For vendors and providers, TEFCA matters because it changes the default question from “Do we exchange data?” to “Why wouldn’t we?” Health systems increasingly expect that exchanging data across networks, without custom interfaces or one-off agreements, is simply part of doing business. TEFCA provides the mechanism to make that expectation realistic, but participation requires preparation.
What a QHIN is in practical terms
A Qualified Health Information Network (QHIN) is the backbone of TEFCA. In practical terms, a QHIN is a large exchange network authorized to connect to other QHINs and route queries and responses on behalf of its participants. QHINs do not merely pass messages; they enforce TEFCA rules, validate requests, and provide a trusted intermediary layer. For most vendors and providers, interacting with TEFCA means interacting with a QHIN, either directly or through a downstream participant. Becoming a QHIN is complex and expensive, requiring significant technical infrastructure, governance maturity, and ongoing compliance. Most organizations will instead connect through an existing QHIN, inheriting access to nationwide exchange without bearing full operational responsibility.
Crucially, QHIN participation does not grant unrestricted access to all data. Access is purpose-limited, audited, and subject to consent and policy constraints. TEFCA enables exchange, but it does not eliminate the need for good data hygiene, clear access controls, and operational discipline.
What “QHIN expansion” changes in 2026
New connectivity expectations
By 2026, the most important change is not a single new technical requirement, but a shift in expectations. TEFCA connectivity, once viewed as optional or experimental, is increasingly treated as a default capability for national-scale health information exchange. Health systems, payers, and public sector partners are beginning to assume that core clinical data can be exchanged across networks without bespoke interfaces. QHIN expansion reflects both broader participation and broader use. More organizations are connected, directly or indirectly, through QHINs, and more exchange purposes are being operationalized beyond basic treatment queries. This increases the likelihood that a vendor’s product will be expected to send and receive data, not merely consume it.
Practically, this means vendors can no longer design for one-way data ingestion alone. Products that only pull records, without supporting outbound responses or acknowledgments, risk being seen as incomplete. Latency, availability, and error handling also matter more as exchange volume grows. In effect, QHIN expansion raises the bar from “can you connect?” to “can you operate reliably at scale?”
Likely procurement questions from health systems
As TEFCA matures, it is increasingly surfacing in procurement and RFP conversations. Health systems are asking direct questions such as: Are you TEFCA-connected? Through which QHIN? What exchange purposes do you support today? How do you handle identity matching and consent? These questions are not purely technical. They are proxies for risk management and future-proofing. A vendor that cannot articulate a TEFCA strategy may be perceived as increasing integration burden or limiting long-term interoperability options.
In 2026, credible answers typically include not just a yes/no response, but documentation: QHIN partner details, supported transactions, security posture, and an implementation roadmap. Vendors that treat TEFCA as a checkbox often struggle to meet these expectations once customers begin to operationalize exchange at scale.
Product implications for connected health
Identity, consent, and access control
QHIN expansion places new pressure on identity resolution and access control, even for products that previously operated within closed ecosystems. Under TEFCA, data exchange assumes that participants can reliably identify who is requesting data, on whose behalf, and for what permitted purpose. Weak patient matching or ambiguous user identity becomes a scaling problem once data flows across networks rather than within a single organization.
Consent handling is another inflection point. TEFCA does not impose a single national consent model, but it requires that participants honor applicable consent, privacy, and access restrictions consistently. Vendors must be able to ingest, interpret, and enforce consent signals, whether derived from state law, organizational policy, or patient preference, without manual intervention. Products that treat consent as an external problem handled “upstream” increasingly struggle in QHIN-enabled environments. Access control must also become more granular. Role-based access, purpose-of-use validation, and logging are no longer optional features reserved for enterprise systems. In 2026, health systems expect vendors to demonstrate that only authorized users can initiate or respond to TEFCA-enabled exchanges, and that access decisions are defensible in audit scenarios.
Data quality, provenance, and auditability
As exchange volume increases, data quality and provenance become operational, not theoretical, concerns. QHINs route data across multiple networks; by the time information reaches an end system, it may have passed through several intermediaries. Vendors are increasingly expected to preserve provenance metadata: where the data came from, when it was created, and under what context it was shared.
This matters for clinical trust and legal defensibility. Clinicians need to understand whether data is current, complete, and attributable to a reliable source. From a compliance perspective, organizations must be able to reconstruct who accessed what data, when, and why. “We simply pass through what we receive” is no longer an acceptable posture when errors, omissions, or inappropriate access are investigated.
In practice, TEFCA readiness pushes vendors toward stronger validation, logging, and audit capabilities. Products that cannot surface provenance or support traceability risk becoming bottlenecks in connected workflows or being excluded from exchange pathways altogether.
Integration pathways
Direct vs via partners
For most organizations, the first TEFCA decision is how to connect, and not whether. In practice, there are two viable pathways: becoming a direct QHIN participant or connecting indirectly through a QHIN partner (such as an EHR vendor, HIE, or national network). The choice has meaningful implications for cost, control, and speed.
Becoming a direct participant or a QHIN itself is resource-intensive. It requires dedicated interoperability infrastructure, 24/7 operational support, formal governance processes, and ongoing compliance with the Common Agreement. This path is typically viable only for large EHR vendors, national HIEs, or organizations with a strategic mandate to act as exchange hubs.
Most digital health vendors and provider organizations instead connect via an existing QHIN. This approach trades some control for faster time to market and lower operational burden. The partner QHIN handles routing, trust enforcement, and many compliance obligations. However, vendors remain responsible for how data is used within their product, and for meeting downstream security, consent, and audit requirements. Choosing a QHIN partner is therefore a strategic decision, not a purely technical one.
FHIR readiness and mapping considerations
Although TEFCA is transport-agnostic, FHIR readiness increasingly determines practical success. Many QHIN-enabled exchanges rely on FHIR-based APIs, profiles, or mappings, even when legacy standards remain in use. Vendors that treat FHIR as an optional add-on often encounter friction when customers attempt to operationalize TEFCA connectivity.
Common challenges include incomplete resource coverage, inconsistent terminology mapping, and loss of context during transformation from proprietary data models. Incremental readiness (supporting core resources, preserving provenance, and handling extensions) is often more realistic than full refactoring, but it still requires deliberate investment.
In 2026, TEFCA integration success depends less on claiming “FHIR support” and more on demonstrating robust, tested mappings that preserve clinical meaning across exchanges.
Governance and risk
Security posture and incident response
QHIN expansion raises the minimum acceptable security posture for any organization participating in nationwide exchange. TEFCA does not introduce entirely new security concepts, but it does standardize expectations around authentication, authorization, logging, and incident response across networks. In practice, this reduces tolerance for informal or undocumented security controls. Participants are expected to detect and respond to incidents that involve exchanged data, not just local systems. This includes inappropriate access, misrouted queries, and data integrity issues that may originate upstream or downstream. In 2026, incident response plans increasingly need to account for multi-party coordination, including notification obligations to QHIN partners and affected participants.
From a vendor perspective, this means security is no longer evaluated solely within the product boundary. Customers and partners may ask for evidence of penetration testing, access reviews, and response drills that specifically reference TEFCA-enabled exchange, not just general IT security.
Contracting and operational obligations
TEFCA participation introduces a layered contractual environment. Vendors and providers must navigate QHIN participation agreements, flow-down terms, and internal customer contracts that reflect Common Agreement obligations. These contracts define permitted uses of data, response expectations, audit rights, and dispute resolution mechanisms.
Operationally, TEFCA is not “set and forget.” Participants are responsible for maintaining compliance as specifications evolve, onboarding new users appropriately, and responding to compliance inquiries. In 2026, organizations increasingly assign explicit internal ownership for TEFCA, often spanning legal, compliance, IT, and product teams, to avoid gaps.
Failure to manage these obligations does not always result in immediate penalties, but it can lead to suspension from exchange, reputational damage, or loss of customer trust. Governance maturity is therefore as critical as technical connectivity.
Readiness checklist (technical + operational)
Use the checklist below to assess TEFCA readiness in 2026, whether you are a vendor connecting through a QHIN or a provider enabling exchange across systems. This is designed as a practical internal review, not a certification exercise.
Identity and access
- Reliable patient matching strategy documented (demographics, identifiers, fallback handling)
- User identity proofing and role-based access controls in place
- Purpose-of-use enforcement aligned with TEFCA exchange purposes
Consent and privacy
- Ability to ingest and honor consent restrictions from upstream sources
- Clear policy for handling state-specific privacy requirements
- Audit trail for consent enforcement decisions
Data standards and quality
- Supported data elements mapped to TEFCA-relevant standards (FHIR where applicable)
- Provenance metadata preserved and surfaced
- Validation checks for incomplete or conflicting data
Security and monitoring
- Logging of TEFCA-related queries and responses
- Incident response plan includes multi-party exchange scenarios
- Regular access and security reviews documented
Operations and ownership
- QHIN partner identified and contractual terms reviewed
- Internal owner for TEFCA compliance designated
- Change management process for evolving specifications
Organizations that treat this checklist as a living document, revisited as exchange volume grows, are better positioned to scale TEFCA participation without disruption.
FAQs
Do we need to be a QHIN to participate in TEFCA?
No. Most vendors and providers will not become QHINs. TEFCA is designed so that the majority of participants connect through an existing QHIN, gaining access to nationwide exchange without assuming full operational and governance responsibility. Becoming a QHIN is typically appropriate only for large networks or organizations intending to operate as exchange hubs.
Is TEFCA mandatory?
TEFCA is not legally mandatory in the way HIPAA is. However, in practice, it is becoming a de facto requirement in many procurement, partnership, and public-sector contexts. Health systems increasingly expect vendors to support TEFCA-aligned exchange, and lack of a clear TEFCA strategy can be a competitive disadvantage in 2026.
How fast will customers expect TEFCA connectivity?
Expectations are accelerating. Many organizations are already asking about TEFCA during contracting, even if they do not plan immediate implementation. In 2026, customers often expect at least a credible roadmap including QHIN partnerships, supported use cases, and timelines, rather than a vague future commitment.
References
- Office of the National Coordinator for Health Information Technology (ONC). (2022, updated 2024). Trusted Exchange Framework and Common Agreement (TEFCA). https://www.healthit.gov/topic/interoperability/trusted-exchange-framework-and-common-agreement-tefca
- The Sequoia Project. (2024). Recognized Coordinating Entity (RCE) for TEFCA: QHIN Technical Framework. https://www.sequoiaproject.org/tefca/
