TEFCA Explained: What Every Healthcare Developer and CTO Needs to Know in 2026

If you build, integrate, or lead technology decisions for healthcare organizations in the United States, TEFCA is no longer optional knowledge. The Trusted Exchange Framework and Common Agreement has quietly become the most consequential interoperability initiative in American healthcare — and in 2026, it reached a scale that makes it impossible to ignore.

As of February 2026, more than 500 million health records have been exchanged through TEFCA. That number was 10 million in January 2025. In thirteen months, TEFCA went from a promising pilot to the dominant national health data exchange framework, connecting 14,214 organizations through 79,000+ unique connections. Eight Qualified Health Information Networks (QHINs) are now live, with more applications pending.

Yet most healthcare developers and CTOs still understand TEFCA only in the abstract — as a government initiative they will "get to eventually." This guide changes that. We break down exactly how TEFCA works at the technical level, what it means for your application architecture, how to connect, what it costs, and what happens if you do not participate as federal mandates tighten.

What Is TEFCA? The Network of Networks, Explained

TEFCA stands for the Trusted Exchange Framework and Common Agreement. Think of it as the interstate highway system for health data. Before TEFCA, health data exchange in the United States was fragmented across dozens of regional health information exchanges (HIEs), proprietary networks (Epic's Care Everywhere, CommonWell Health Alliance, Carequality), and point-to-point connections. Each network had its own rules, its own technical requirements, its own legal agreements.

TEFCA creates a single, standardized framework that connects all of these networks together. It establishes:

• A common set of rules (the Common Agreement) that all participants must follow
• A standardized technical framework (the QHIN Technical Framework, or QTF) that specifies how data is exchanged
• A governance structure with a Recognized Coordinating Entity (RCE) — the Sequoia Project — that oversees compliance
• Designated exchange purposes that define when and why data can be shared

The result: any organization connected to any QHIN can exchange health data with any organization connected to any other QHIN, using a single legal agreement and a single set of technical standards. You sign one agreement. You implement one set of APIs. You connect to the entire national network.

To put this in concrete terms: before TEFCA, if a hospital in Boston wanted to query patient records from a clinic in San Diego, it needed a direct connection to that clinic's network, a bilateral data-sharing agreement, compatible technical implementations, and often months of integration work. With TEFCA, the Boston hospital queries through its QHIN, which routes to the San Diego clinic's QHIN, which returns the records — all under a single pre-negotiated agreement, using standardized protocols, with no point-to-point integration required.

This is the vision that the Office of the National Coordinator for Health IT (now the Assistant Secretary for Technology Policy, or ASTP) has been building toward since the 21st Century Cures Act was signed in December 2016. A decade of regulatory groundwork is now producing real-world results at scale.

Why TEFCA Matters NOW: The Numbers That Changed Everything

TEFCA's growth trajectory in 2025-2026 has been extraordinary — and it fundamentally changes the calculus for every healthcare technology leader.

The scale numbers (as of February 2026):

• 500 million+ health records exchanged through TEFCA (source: Sequoia Project RCE updates)
• 14,214 organizations connected as participants or subparticipants
• 79,000+ unique connections between organizations
• 8 designated QHINs operational, with additional applications under review
• 50x growth in records exchanged in 13 months (10M in Jan 2025 to 500M in Feb 2026)

The TEFCA 10x10 Coalition — a partnership of 10 major payers and 10 major providers — is actively driving adoption. This coalition represents a significant share of covered lives in the US and signals that both the payer and provider communities are betting on TEFCA as the primary exchange mechanism going forward.

The regulatory pressure:

• The CMS Interoperability and Prior Authorization Final Rule established Q1 2026 compliance deadlines for payers implementing Patient Access APIs, Provider Access APIs, and Payer-to-Payer data exchange
• HTI-1 (Health Data, Technology, and Interoperability rule) updated certification criteria to require FHIR-based bulk data access and USCDI v3 support
• The December 2024 Federal Register ruling further tightened information blocking enforcement, with penalties of up to $1 million per violation
• ASTP began issuing letters of nonconformity to certified EHR developers in February 2026 — the first concrete enforcement actions

The message from federal regulators is clear: health data exchange is not optional, and TEFCA is the preferred mechanism for achieving it.

How TEFCA Works: Architecture for Developers

Understanding TEFCA's architecture is essential for any developer or architect planning an integration. The framework operates on a three-tier hierarchy, with clear roles and responsibilities at each level.

Tier 1: Recognized Coordinating Entity (RCE)

The Sequoia Project serves as the RCE — the governing body of TEFCA. The RCE:

• Develops and maintains the Common Agreement and QTF
• Designates and monitors QHINs
• Resolves disputes between participants
• Updates technical requirements as standards evolve

As a developer, you will not interact directly with the RCE. But the rules they set flow down through the entire hierarchy and determine the technical requirements you must meet.

Tier 2: Qualified Health Information Networks (QHINs)

QHINs are the backbone of TEFCA. They are large-scale health information networks that have been designated by the RCE after demonstrating compliance with the Common Agreement and QTF. QHINs connect directly to each other, forming the "network of networks."

As of March 2026, eight QHINs are designated and operational:

• eHealth Exchange — The largest health information network in the US, connecting federal agencies (VA, DoD), state HIEs, and major health systems. Operated by the Sequoia Project.
• CommonWell Health Alliance — A health IT industry alliance with 35,000+ provider locations, strong in the ambulatory and post-acute care space.
• Epic Nexus — Epic's QHIN offering, providing TEFCA connectivity for Epic-connected organizations and enabling cross-network exchange beyond the Epic ecosystem.
• KONZA National Network — Focused on connecting rural and underserved healthcare organizations, with strong coverage in the Midwest.
• MedAllies — A health information service provider with deep expertise in clinical data exchange and patient matching.
• Health Gorilla — A clinical data network specializing in real-time access to labs, imaging, and clinical records, with strong API-first architecture.
• Kno2 — A health data exchange platform focused on simplifying connectivity for smaller healthcare organizations and health IT vendors.
• Datavant — A health data connectivity company specializing in linking de-identified and identified health data across organizations.

Tier 3: Participants and Subparticipants

Participants are organizations that sign a Standard Participant Agreement (SPA) directly with a QHIN. They agree to comply with the Common Agreement and QTF requirements. Participants are typically large health systems, payers, state HIEs, or health IT vendors.

Subparticipants connect through a Participant, not directly to a QHIN. They sign a Subparticipant Agreement with their Participant. Subparticipants are typically individual clinics, physician practices, labs, pharmacies, or health applications.

This is the key architectural decision for most developers: you will almost certainly connect as a Subparticipant through an existing Participant or QHIN, not as a direct QHIN or Participant. This dramatically reduces your compliance burden while giving you access to the full TEFCA network.

Exchange Purposes

TEFCA defines five permitted exchange purposes — the legal reasons for which health data can be requested and shared:

• Treatment (T) — Clinical care coordination, referrals, transitions of care. The most common exchange purpose.
• Payment (P) — Claims processing, eligibility verification, prior authorization, billing.
• Healthcare Operations (HCOPS) — Quality assessment, credentialing, business planning, population health management.
• Public Health Activities (PHA) — Disease surveillance, case reporting, immunization registries, vital records.
• Individual Access Services (IAS) — Enabling patients to access and direct their own health data through apps or services of their choice.

Every TEFCA exchange must specify which exchange purpose it falls under. The QTF defines the technical mechanisms for conveying this purpose in API requests.

Exchange Modalities

TEFCA currently supports three primary exchange modalities:

• Query-based exchange — A requesting organization queries for patient records from responding organizations. This is the primary modality today, using IHE profiles (XCA/XCPD) for cross-community queries.
• Document exchange — Push-based delivery of clinical documents (C-CDA documents, discharge summaries, referral packages).
• FHIR-based exchange — The newest modality, being phased in to support RESTful API-based data access using FHIR R4 resources. QHINs must implement FAST security protocols for FHIR exchanges as of January 2026.

For developers building new applications, FHIR-based exchange is where you should focus. The QTF's FHIR requirements align closely with the broader FHIR interoperability standards that modern healthcare applications already need to support.

The QHINs: Who Is Connected and What They Offer

Choosing the right QHIN partner is one of the most important decisions you will make when connecting to TEFCA. Each QHIN has different strengths, different participant networks, and different onboarding experiences.

For health IT vendors and app developers: Health Gorilla and Kno2 offer the most developer-friendly onboarding, with well-documented APIs and faster time-to-connection. eHealth Exchange provides the broadest reach but has a more complex onboarding process suited to larger organizations.

For health systems and hospitals: If you are an Epic shop, Epic Nexus provides native integration. CommonWell offers broad ambulatory coverage. eHealth Exchange connects you to federal agencies (VA, DoD, CMS).

For payers: eHealth Exchange and Datavant offer the strongest payer-oriented capabilities, including support for the Payment and Healthcare Operations exchange purposes that are critical for claims and prior authorization workflows.

For startups and smaller organizations: Connect as a Subparticipant through a QHIN or Participant that offers managed connectivity. Kno2 and Health Gorilla specifically target this segment with simplified onboarding.

Technical Requirements for Developers

If you are building or integrating a healthcare application that will connect to TEFCA, here are the technical requirements you need to plan for. The QTF specifies these in detail, but this section distills them into actionable engineering requirements.

FHIR R4 and US Core Profiles

TEFCA's FHIR-based exchange requires compliance with:

• FHIR R4 (4.0.1) as the base specification
• US Core Implementation Guide 6.1 — defines the minimum data elements and API behaviors for US healthcare
• USCDI v3 (United States Core Data for Interoperability) — 24 data classes and their constituent data elements that must be supported
• Bulk FHIR for population-level data queries (required for certain exchange purposes)

If you are already building FHIR-native applications — which you should be in 2026 — most of these requirements will align with work you have already done or planned. The incremental lift for TEFCA is primarily in the security and identity layers.

UDAP Security and Authentication

This is where TEFCA's technical requirements diverge most significantly from standard SMART on FHIR implementations. TEFCA requires UDAP (Unified Data Access Profiles) for secure, trust-based authentication between organizations:

• JWT-based client authentication — Clients authenticate using signed JWTs rather than client secrets. This eliminates the need for shared secrets between organizations.
• Dynamic client registration — Applications register with TEFCA endpoints dynamically using signed software statements, rather than manual pre-registration.
• X.509 certificate chains — Trust is established through certificate hierarchies rooted in trusted Certificate Authorities. Each organization's identity is cryptographically verified.
• Fine-grained OAuth 2.0 scopes — TEFCA defines specific OAuth scopes for each exchange purpose and data type, enabling precise access control.

For development teams familiar with SMART on FHIR authentication, UDAP adds a layer of organizational trust on top of the user-level authentication you already implement. The key difference: SMART authenticates individual users to applications; UDAP authenticates organizations to each other.

Patient Identity Resolution

One of the hardest technical problems in health data exchange is matching the right records to the right patient across organizations that use different identifiers. TEFCA addresses this through:

• Demographics-based patient matching — Using combinations of name, date of birth, gender, address, and phone number to match patients across systems
• Match confidence scoring — Algorithms that produce match confidence scores, with configurable thresholds for automatic vs. manual review
• Cross-network identity linking — Once a patient is matched across two organizations, that link can be cached and reused for future exchanges
• Record locator services — QHINs maintain indices of which patients have records at which organizations, enabling targeted queries rather than broadcast searches

Patient matching accuracy is critical. False positives (matching the wrong patient's records) create safety and privacy risks. False negatives (failing to find matching records) create gaps in care. The QTF sets minimum match accuracy requirements that QHINs must meet.

In practice, patient matching remains one of the most technically challenging aspects of TEFCA implementation. The United States does not have a universal patient identifier, so matching relies entirely on demographic data — which is notoriously inconsistent across systems. Name spellings vary, addresses change, phone numbers rotate. Sophisticated matching algorithms use probabilistic scoring, weighting each demographic element and applying machine-learning models trained on large-scale matching datasets. Organizations participating in TEFCA need to evaluate their QHIN's matching approach carefully, understand the false-positive and false-negative rates, and implement workflows for manual review of low-confidence matches.

QTF Compliance Requirements

Beyond FHIR and security, the QTF specifies operational requirements that flow down from QHINs to Participants to Subparticipants:

• Message delivery SLAs — Maximum response times for queries and document deliveries
• Error handling standards — Standardized error codes, retry logic, and escalation procedures
• Audit logging — Comprehensive logging of all exchange activities for compliance and troubleshooting
• Incident response — Defined procedures for security incidents, data breaches, and system outages
• Minimum availability — Uptime requirements for production systems participating in TEFCA exchange

TEFCA vs. CommonWell vs. Carequality vs. Direct: How They Relate

One of the most common sources of confusion is how TEFCA relates to existing health data exchange networks. Here is the clearest way to think about it:

TEFCA is the framework. The others are networks within it.

CommonWell Health Alliance is a designated QHIN within TEFCA. If you are already connected to CommonWell, you are already part of the TEFCA network. CommonWell's 35,000+ provider locations are accessible through TEFCA, and CommonWell participants can now query across TEFCA to reach organizations connected through other QHINs.

Carequality is an interoperability framework (not a QHIN itself) that predated TEFCA. Several QHINs — including eHealth Exchange — use Carequality's query framework as part of their infrastructure. Carequality connects approximately 70% of US hospitals. Its relationship with TEFCA is complementary: Carequality provides the technical plumbing for cross-network queries that TEFCA formalizes under a single governance structure.

Direct (Direct Trust / HISP) is a secure messaging protocol for point-to-point health data exchange. It is the oldest of these networks and is primarily used for sending clinical documents (C-CDAs) between known parties. Direct is not a QHIN, but some QHINs support Direct as a delivery mechanism. Direct's usage is declining as query-based and FHIR-based exchange through TEFCA offers more powerful capabilities.

Epic Care Everywhere is Epic's proprietary network for exchanging data between Epic-connected organizations. Epic Nexus (the QHIN) extends this network into TEFCA, allowing Epic organizations to exchange data with non-Epic organizations through the TEFCA framework.

The practical implication: if your organization is already connected to any of these networks, you may already have a pathway into TEFCA through a QHIN that participates in your existing network. Check with your current network operator about their TEFCA participation status.

It is also worth understanding what TEFCA replaces and what it does not. TEFCA does not eliminate the need for point-to-point interfaces in all cases. Real-time clinical workflows — like a lab sending results directly to an ordering physician's EHR — may still use HL7 v2 messages or FHIR subscriptions through direct integrations. TEFCA excels at cross-organizational record discovery, patient record aggregation, and broad-network data exchange. Think of it as the system you use when you need to find and retrieve patient data from organizations you do not have a direct relationship with — which, in a mobile patient population, is increasingly the norm.

For teams building healthcare integration architectures, the strategic question is not "TEFCA or direct interfaces?" but rather "which use cases belong on TEFCA and which need dedicated connections?" A well-designed integration architecture uses both: TEFCA for broad network reach and record discovery, direct FHIR connections for real-time clinical workflows with known partners, and standards like HL7 and FHIR across both channels.

How to Connect Your Application to TEFCA

For most healthcare developers, connecting to TEFCA means becoming a Subparticipant through an existing QHIN or Participant. Here is the step-by-step process.

Step 1: Choose Your Connection Path

You have three options, in order of increasing complexity:

• Subparticipant (recommended for most developers) — Connect through an existing Participant or QHIN. Lowest barrier to entry. The Participant/QHIN handles most compliance requirements on your behalf.
• Participant — Sign a Standard Participant Agreement (SPA) directly with a QHIN. Appropriate for health systems, large EHR vendors, or organizations that want more control over their TEFCA connectivity.
• QHIN — Apply to become a designated QHIN through the RCE. This is a significant undertaking appropriate only for large-scale health information networks.

Step 2: Select a QHIN Partner

Evaluate QHINs based on:

• Network reach — Which organizations are accessible through this QHIN?
• Technical compatibility — Does the QHIN support your preferred standards (FHIR R4, C-CDA, both)?
• Onboarding experience — How long does onboarding take? What is the documentation quality? Is there developer support?
• Cost structure — What are the fees for connectivity, per-transaction costs, and minimum commitments?
• Exchange purpose support — Does the QHIN support all the exchange purposes you need (Treatment, Payment, IAS, etc.)?

Step 3: Implement Technical Requirements

Based on your chosen connection path and QHIN, implement:

• FHIR R4 server or client capabilities (depending on whether you are responding to queries or initiating them)
• UDAP authentication (JWT signing, certificate management, dynamic registration)
• Patient identity matching (or integration with your QHIN's matching service)
• US Core profile support for all required USCDI v3 data classes
• Audit logging and monitoring per QTF requirements

If you are building FHIR infrastructure from the ground up, working with a team that has deep healthcare interoperability experience can significantly accelerate this phase.

Step 4: Complete Legal and SLA Agreements

Sign the appropriate agreement (Subparticipant Agreement or SPA) with your QHIN/Participant. These agreements cover:

• Data use and privacy obligations
• Security requirements and breach notification
• SLA commitments (uptime, response times)
• Dispute resolution procedures
• Liability and indemnification

Step 5: Testing and Certification

Complete conformance testing with your QHIN to verify:

• Technical interoperability (can you send and receive data correctly?)
• Patient matching accuracy
• Security compliance (UDAP, certificate validation)
• Exchange purpose handling
• Error handling and edge cases

Step 6: Go Live

After successful testing, your QHIN activates your production connection. You can now exchange health data with any organization connected to any QHIN in the TEFCA network.

Implementation Timeline and Costs

Realistic timelines and cost ranges for TEFCA connectivity:

Subparticipant (most common for developers):

• Timeline: 3-6 months from initial engagement to go-live
• Cost: $25,000-$150,000 depending on your existing FHIR capabilities, the QHIN's pricing, and the complexity of your use case
• Ongoing: Monthly connectivity fees ($500-$5,000/month) plus per-transaction costs (varies by QHIN)

Participant:

• Timeline: 6-12 months, including legal review, technical implementation, and conformance testing
• Cost: $100,000-$500,000+ for initial implementation, including legal, technical, and compliance costs
• Ongoing: Higher monthly fees reflecting the broader compliance obligations

QHIN designation:

• Timeline: 12-24+ months
• Cost: $1M+ investment in infrastructure, compliance, and organizational capacity
• Ongoing: Significant operational costs for maintaining QHIN designation

These costs should be weighed against the alternative: building and maintaining dozens of individual point-to-point connections, each with its own legal agreement, technical implementation, and ongoing maintenance. For organizations that need to exchange data with multiple partners, TEFCA's single-agreement model provides significant cost savings at scale.

What drives cost variation:

The biggest cost variable is your existing FHIR maturity. Organizations that already have production FHIR R4 servers with US Core profiles can focus their TEFCA investment on the security layer (UDAP implementation), patient matching integration, and QTF compliance — typically the lower end of the cost range. Organizations starting from scratch with FHIR need to budget for the full stack: FHIR server implementation, data mapping from legacy formats, SMART on FHIR authentication, and then the TEFCA-specific requirements on top.

Staff investment is also significant. You will need engineers who understand both FHIR and the specifics of UDAP security, a compliance or legal resource to navigate the Common Agreement and SPA, and project management capacity for the 3-12 month onboarding process. Many organizations underestimate the staff time required for conformance testing and the iterative troubleshooting that comes with cross-network interoperability.

ROI calculation:

For organizations currently maintaining 10+ point-to-point connections, the TEFCA ROI calculation is straightforward. Each point-to-point connection costs $15,000-$50,000 to implement and $5,000-$15,000/year to maintain (interface monitoring, certificate rotation, version upgrades, troubleshooting). Ten connections cost $150,000-$500,000 to build and $50,000-$150,000/year to maintain. A single TEFCA connection that replaces all ten at $100,000 initial cost and $3,000/month ongoing produces positive ROI within 12-18 months — with the added benefit of reaching 14,000+ organizations instead of just ten.

CMS Compliance: What Happens If You Do Not Join

While TEFCA participation is not yet legally mandated for all healthcare organizations, the regulatory landscape is rapidly narrowing the space for non-participation.

For payers (health plans):

• The CMS Interoperability and Prior Authorization Final Rule requires payers to implement Patient Access APIs (FHIR-based), Provider Access APIs, and Payer-to-Payer data exchange by Q1 2026
• While these requirements do not explicitly mandate TEFCA, TEFCA is the most efficient mechanism for meeting Payer-to-Payer exchange requirements
• CMS has signaled that future rulemaking may explicitly incorporate TEFCA participation as a compliance pathway

For providers (hospitals, health systems, clinics):

• Information blocking penalties of up to $1 million per violation are now actively enforced
• Medicare payment disincentives for providers who cannot demonstrate meaningful data exchange
• Promoting Interoperability program requirements increasingly align with TEFCA-supported exchange standards
• MIPS scoring includes measures for health information exchange that TEFCA participation directly addresses

For health IT developers:

• ONC certification requirements under HTI-1 require FHIR R4 APIs, USCDI v3 support, and Bulk FHIR capabilities — all of which align with TEFCA's technical requirements
• ASTP began issuing letters of nonconformity to certified EHR developers in February 2026
• The HTI-5 proposed rule (published December 2025) further tightens certification requirements and expands the definition of information blocking to include AI systems

The trajectory is unmistakable: federal policy is converging on TEFCA as the national standard for health data exchange. Organizations that invest in TEFCA connectivity now are building on the platform that regulators are actively mandating. Organizations that delay will face increasing compliance pressure and competitive disadvantage as their peers connect.

The competitive angle matters too. In a market where patients increasingly expect their health data to follow them across providers, payers, and apps, organizations connected to TEFCA can offer seamless data access as a differentiator. A health system that can pull a new patient's complete record from any TEFCA-connected organization within seconds provides a fundamentally better clinical experience than one that asks patients to fill out paper forms or fax records from their previous provider. For health IT vendors, TEFCA connectivity is becoming a checkbox requirement in RFPs from health systems and payers evaluating new products.

As we explored in our analysis of India's 834 million digital health IDs and America's TEFCA, the US is not alone in building national health data infrastructure — but TEFCA's approach of federating existing networks rather than building a single centralized system is uniquely American and uniquely well-suited to the US healthcare market's complexity.

Frequently Asked Questions

Is TEFCA participation mandatory?

Not yet, but the regulatory direction is clear. CMS and ASTP are steadily tightening requirements around health data exchange, information blocking enforcement, and interoperability certification. While no current rule explicitly mandates TEFCA participation, the Q1 2026 CMS interoperability deadlines, information blocking penalties of up to $1M per violation, and the convergence of federal standards with TEFCA's technical requirements make non-participation increasingly difficult to sustain — both from a compliance and a competitive standpoint.

How much does it cost to connect to TEFCA?

Costs vary significantly based on your connection path. Subparticipants (the most common path for developers and smaller organizations) can expect $25,000-$150,000 in initial implementation costs and $500-$5,000/month in ongoing connectivity fees. Participants face $100,000-$500,000+ in initial costs. These should be compared against the alternative: building and maintaining individual connections to each exchange partner, each with its own legal agreement and technical requirements.

Can I use TEFCA to access patient records for AI and analytics?

TEFCA's exchange purposes include Healthcare Operations (HCOPS), which covers quality assessment, business planning, and population health management. However, using TEFCA-exchanged data for AI training, analytics, or secondary purposes requires careful consideration of the specific exchange purpose under which data was obtained, HIPAA requirements for de-identification or authorization, and the terms of the Common Agreement. The HTI-5 proposed rule explicitly expands the definition of "access" and "use" to include automated means, including AI systems — signaling heightened regulatory scrutiny of AI uses of exchanged health data.

What is the difference between a QHIN and an HIE?

A Health Information Exchange (HIE) is a regional or state-level organization that facilitates health data exchange within its geographic area. A Qualified Health Information Network (QHIN) is a nationally designated network under TEFCA that has been certified by the RCE to participate in cross-network exchange. Some organizations serve as both — eHealth Exchange, for example, operates as both a national HIE and a designated QHIN. The key difference is scope and governance: QHINs operate under TEFCA's Common Agreement and can exchange data with all other QHINs nationally, while traditional HIEs are limited to their own network and bilateral agreements.

Do I need to support both C-CDA and FHIR for TEFCA?

Currently, TEFCA's primary exchange modality uses IHE profiles (XCA/XCPD) with C-CDA documents. FHIR-based exchange is being phased in, with QHINs required to implement FAST security protocols for FHIR exchanges as of January 2026. For new implementations, we recommend building FHIR-first and adding C-CDA support as needed. Many QHINs handle C-CDA/FHIR translation at the network level, reducing the burden on individual participants. If you are building a new health IT product in 2026, invest in FHIR R4 with US Core profiles — this positions you for both current TEFCA requirements and the direction the framework is heading.

Getting Started with TEFCA

TEFCA is no longer a future initiative — it is the present reality of US healthcare interoperability. With 500 million records exchanged, 14,214 connected organizations, and federal mandates tightening quarterly, the question is not whether to connect but when and how.

For developers and CTOs evaluating TEFCA connectivity, the path is clearer than ever:

1. Assess your current state — What FHIR capabilities do you already have? Are you connected to any existing networks (CommonWell, Carequality, eHealth Exchange)?
2. Choose your connection path — Subparticipant through an existing QHIN is the fastest path for most organizations
3. Build on standards — FHIR R4, US Core, UDAP, and USCDI v3 are the technical foundation. Invest here and you invest once for both TEFCA and broader certification compliance.
4. Start the conversation with QHINs — Reach out to 2-3 QHINs that align with your use case and start the evaluation process

Need help connecting your healthcare application to TEFCA or building FHIR-based interoperability? Our team has deep experience in US healthcare integration. Talk to us.