What Is a QHIN? TEFCA’s Backbone for Nationwide Exchange

Healthcare data exchange in the U.S. has been fragmented for decades, with providers, payers, and app developers navigating a patchwork of networks that rarely talk to each other. TEFCA, the Trusted Exchange Framework and Common Agreement, was designed to fix that. At its core sits a specific type of organization responsible for making nationwide health data exchange actually work. So, what is a QHIN, and why does it matter to anyone building or operating healthcare technology?

A Qualified Health Information Network (QHIN) is a designated entity that serves as a gateway for cross-network data exchange under TEFCA. Think of it as a trusted on-ramp to a national highway system for health information. For organizations that connect applications to EHRs, exactly the kind of work that SoFaaS simplifies through managed SMART on FHIR integration, understanding QHINs is essential context. These networks shape how patient data moves between systems at scale.

This article breaks down what QHINs are, how they function within TEFCA, which organizations hold QHIN designation today, and what all of this means for healthcare developers and technology leaders planning their interoperability strategy going forward.

What a QHIN is and what it is not

A QHIN, short for Qualified Health Information Network, is a nationally designated organization approved by the Recognized Coordinating Entity (RCE) to operate as a trusted exchange node under TEFCA. If you're asking what is a QHIN at a functional level, the answer is straightforward: it's an organization that has signed the Common Agreement, meets rigorous technical and privacy standards, and is authorized to route health information queries across participating networks on your behalf.

A QHIN is not just any health information network. It carries a specific federal designation that comes with binding legal obligations and technical requirements under the Common Agreement.

What a QHIN actually does

A QHIN acts as the central routing infrastructure between different health information networks, providers, payers, and app developers under TEFCA. When a clinician needs patient records from a facility on a separate network, that query travels through a QHIN to reach the right destination. Your organization doesn't need to build direct connections to every network; the QHIN handles that routing layer for you.

These organizations also enforce the rules of the Common Agreement across all participants they onboard, which means they carry direct responsibility for compliance and maintain consistent security standards down the chain.

What a QHIN is not

A QHIN is not an EHR system, a health app, or a general health information exchange (HIE). Standard HIEs operate regionally and typically lack the cross-network reach that TEFCA provides. Your existing regional HIE may be a valuable resource, but it does not hold QHIN status unless it has gone through the RCE designation process. QHINs are also not payer portals or provider-owned data platforms. They function specifically as network-level intermediaries, enabling exchange that would otherwise require separate bilateral agreements with dozens of individual organizations.

How TEFCA and QHINs fit together

TEFCA establishes the national framework for health data exchange, but it is not itself a network. It is a set of rules, principles, and legal agreements that define how exchange must happen. QHINs are the organizations that bring those rules to life by operating the actual infrastructure. Without QHINs, TEFCA would be a policy document with no operational backbone.

TEFCA as the rulebook

The Office of the National Coordinator for Health Information Technology (ONC) developed TEFCA to create a single, standardized on-ramp for nationwide interoperability. The Common Agreement, which every QHIN must sign, specifies the technical requirements, privacy protections, and security obligations all participants must follow. This agreement is what makes cross-network exchange legally enforceable rather than voluntary.

TEFCA without QHINs is like a highway code without roads: it describes how traffic should flow, but nothing actually moves.

QHINs as the enforcement layer

When you ask what is a QHIN in the context of TEFCA, the clearest answer is that QHINs are TEFCA's operational layer. They onboard participants, enforce compliance with the Common Agreement, and execute the actual data routing. Your organization connects to a QHIN, and that QHIN carries full responsibility for ensuring exchange meets TEFCA standards.

How QHIN exchange works in practice

When you understand what is a QHIN at a conceptual level, the next step is seeing how data actually moves through this infrastructure. Exchange under TEFCA follows a structured query-and-response model where your organization sends a request through your QHIN, and that QHIN routes the query to the appropriate destination network.

The query and response cycle

Your organization connects to a QHIN as a Participant or Sub-participant. When you request patient data, your QHIN validates the request against the Common Agreement rules, then forwards it across the network to locate and retrieve the relevant records. The responding QHIN on the other end delivers the data back through the same channel, and you receive a consolidated response without managing individual connections yourself.

This routing model means your single QHIN connection gives you reach across every other QHIN in the network, not just the systems your organization already knows.

What triggers an exchange

Exchange happens across several defined use cases under TEFCA. Your QHIN enforces specific authorization requirements tied to each use case before any data moves, keeping every transaction within legal and policy boundaries.

The main defined exchange purposes include:

• Treatment: sharing records to support direct patient care
• Payment: enabling billing and claims processing
• Health Care Operations: supporting administrative and quality functions
• Individual Access Services: giving patients access to their own data

QHIN roles, rules, and common use cases

Once you understand what is a QHIN conceptually, it helps to look at the specific roles participants play and the rules that govern every transaction on the network.

QHIN participant roles

QHINs onboard three types of participants: Participants, Sub-participants, and individuals. Participants connect directly to the QHIN and hold their own signed agreement with it. Sub-participants connect through a Participant, meaning your organization can access QHIN exchange without signing directly with the QHIN itself.

This tiered structure gives smaller organizations a practical path into TEFCA exchange without carrying the full compliance burden of a direct QHIN relationship.

Rules every QHIN enforces

Every QHIN must enforce the Common Agreement's privacy and security requirements on every participant it onboards. This includes purpose-of-use validation for every query, meaning your system must declare a defined exchange purpose before any data moves. QHINs also maintain audit logs, enforce minimum necessary data standards, and manage dispute resolution between participants.

Practical use cases

The most common exchange scenarios include care coordination between unaffiliated providers and patient record retrieval at the point of care. Other high-value use cases are:

• Payer access: supporting billing and claims processing
• Health care operations: enabling quality reporting and administrative functions
• Individual Access Services: giving patients direct, portable access to their own records

Designated QHINs and how to connect

Understanding what is a QHIN becomes more actionable once you know which organizations currently hold designation. Several entities have completed the RCE qualification process and are actively routing exchange traffic across the TEFCA network today.

The Sequoia Project, which serves as the RCE, maintains the official list of designated QHINs and publishes updates as new organizations complete the qualification process.

Current designated QHINs

As of early 2026, designated QHINs include eHealth Exchange, Carequality, CommonWell Health Alliance, KONZA, Health Gorilla, and Epic. Each operates its own participant community, so your choice of QHIN affects which networks you can reach and what onboarding requirements you face. Some QHINs focus on provider-heavy networks, while others serve a broader mix of payers, app developers, and health systems.

How to connect as a participant

Your path into TEFCA depends on your organization's size and technical resources. Connecting directly as a Participant means signing an agreement with a QHIN and meeting its technical requirements independently. Joining as a Sub-participant through an existing Participant reduces the compliance overhead and is often the faster route for smaller development teams. Either way, you start by contacting a designated QHIN, reviewing their onboarding documentation, and confirming your intended exchange use cases before any technical work begins.

What to do next

Now that you understand what is a QHIN and how these networks operate under TEFCA, the practical question is where your organization fits. If you're building a healthcare application, your immediate priority is identifying which QHIN aligns with your use cases and starting the onboarding conversation. Reviewing the Sequoia Project's current designee list and comparing each QHIN's participant community against your target data partners is a solid first step.

Connecting to a QHIN often surfaces a second challenge: your application still needs to read and write patient data from EHR systems in a compliant, scalable way. That's where SMART on FHIR integration becomes critical, and managing it in-house pulls your team away from building the product itself. SoFaaS handles that layer for you, with pre-built EHR connectors, automated compliance, and a unified API your developers can work with immediately. Start your SMART on FHIR integration and cut months off your development timeline.