25.32 — TEFCA, QHINs and the National Network

A patient walks into an urgent care clinic in a city she is visiting. The clinician needs her records, and her care until now has been at a health system two thousand miles away that this clinic has never heard of and has no contract with.

Chapter 25.31 gave the standards for moving records between two systems that already know each other. This chapter is about the harder question: how do you find the records of a person whose history is scattered across organisations you have no relationship with, and on what legal basis do you get them?

The American answer is TEFCA, and it is worth understanding properly because it is the framework the whole country's exchange is being consolidated onto.

What TEFCA actually is

TEFCA stands for the Trusted Exchange Framework and Common Agreement, and the name contains the two halves.

The Trusted Exchange Framework is a set of principles — standardisation, openness, security, privacy, access, and equity — describing how exchange should work.

The Common Agreement is the actual legal document. It is a single contract that every participating network signs, which means that instead of thousands of bilateral agreements between organisations, everyone signs the same terms once and can then exchange with everyone else.

That is the real innovation, and it is a legal one rather than a technical one. The historical barrier to nationwide exchange was never mainly protocol; it was that every pair of organisations needed to negotiate a data sharing agreement, and the number of pairs grows as the square of the number of participants.

The authority for it comes from the 21st Century Cures Act, which directed the federal health IT office to develop such a framework.

The RCE and the QHINs

The government does not operate the network. It designated a Recognized Coordinating Entity — the RCE — to develop, implement and maintain the Common Agreement and to run the process for designating and monitoring networks. That role is held by The Sequoia Project.

A QHIN — a Qualified Health Information Network — is a network that has been designated under this framework and connects directly to the other QHINs. The QHINs form the top layer, and everyone else connects through one of them.

The structure has three tiers and the vocabulary is used precisely in contracts. QHINs exchange with each other. Participants connect to a QHIN — typically health systems, health information exchanges, payers or vendors. Subparticipants connect through a Participant — typically individual practices, clinics or applications.

As of mid-2026 there were eleven designated QHINs: CommonWell Health Alliance, eClinicalWorks PrismaNet, eHealth Exchange, Epic Nexus, Health Gorilla, Kno2, KONZA, MedAllies, Netsmart, Oracle Health Information Network, and Surescripts. Applications are accepted on a rolling basis, so the list changes; the authoritative current roster is published by the RCE, and checking it is a two-minute task worth doing before any client conversation on this subject.

Notice what those organisations are. Some are the pre-existing national exchange networks. Some are the electronic health record vendors themselves. Some are companies whose entire business is health data connectivity. TEFCA did not replace the existing networks; it gave them a common legal and technical framework to interoperate under, which is why adoption moved faster than sceptics expected.

Exchange purposes: the part that actually governs your project

The Common Agreement does not permit exchange for any reason a participant likes. It defines exchange purposes, and every request carries the purpose it is being made for.

Treatment — a clinician needs the record to care for the patient. The largest volume by far.

Payment — a payer needs records to adjudicate a claim or determine coverage.

Health care operations — quality assessment, care coordination, and similar activities within defined limits.

Public health — reporting and response by public health authorities.

Government benefits determination — for example, disability determination.

And individual access services — a person requesting their own records, which is the purpose that lets consumer applications retrieve a patient's own data from across the country.

The consequence for design is direct. Your system must assert a purpose, must be entitled to assert it, and must be able to prove afterwards what it asserted and why. Purpose is not metadata; it is the legal basis for the disclosure, and misuse of a purpose is a serious contractual and regulatory matter.

How a query actually works

Follow the urgent care clinic's request through the network, because the sequence explains why certain design decisions were made.

The clinic's system asks its Participant, which asks its QHIN, to find records for this patient.

A patient discovery request goes out carrying demographics — name, date of birth, sex, address — because there is no national identifier (Chapter 25.31).

Other QHINs match against their own participants' records and respond with what they hold. Matching thresholds are deliberately conservative, because a false match discloses one person's record to another's clinician.

The clinic's system then requests the documents it wants, and receives them.

The technical layer for this document exchange is built on the established profiles used by the earlier national networks, with FHIR-based exchange being added in stages. The direction is clear and it is worth stating carefully: the framework began with document-level exchange because that is what everyone already implemented, and is progressively adding resource-level FHIR exchange brokered through the QHINs. So a project planning around TEFCA needs to know which capability is available in the stage its QHIN currently supports, rather than assuming FHIR everywhere.

Where TEFCA fits with everything else

Three relationships confuse people, and each is straightforward once stated.

TEFCA and FHIR are not alternatives. FHIR is a data standard; TEFCA is a governance and trust framework that says who may ask whom for what, under what agreement. You can implement FHIR without TEFCA — most current integrations do — and TEFCA increasingly uses FHIR as its transport.

TEFCA and the existing networks are not alternatives either. The regional and national exchanges continue to operate; several became QHINs or connect through one.

And TEFCA does not replace direct integrations. A hospital and its reference laboratory will keep their dedicated interface, because a national query network is the wrong tool for a high-volume operational feed.

What it is genuinely good for, and what it is not

Being able to state this clearly is worth a great deal in a client conversation, because vendors describe TEFCA as the answer to everything.

It is good for finding records for a patient whose history is elsewhere, in an unplanned situation. The urgent care case, the emergency department, the specialist seeing a new referral.

It is good for individual access — an application retrieving a person's own records from many organisations without that person having to request each one.

It is good for reducing legal overhead, which is the point of a single agreement.

It is not a substitute for a designed integration where you know both ends and need volume, low latency and specific content.

It does not solve the reconciliation problem. You still receive documents from six organisations with overlapping, contradictory medication lists, and merging them into something a clinician can act on remains the hard and valuable part.

And it does not solve data quality. What comes back is what those organisations recorded, with their coding habits and their gaps.

Practical questions to ask on any TEFCA project

These five questions will keep a project honest.

Which QHIN, and which exchange capabilities does it support today? Document exchange, FHIR, or both, and for which purposes.

Are we a Participant or a Subparticipant, and through whom? This determines your obligations, your onboarding path and who is contractually responsible for what.

Which exchange purposes are we entitled to assert, and how is that enforced in code rather than in a policy document?

How do we handle patient matching, and what happens on an ambiguous match? The answer must be a defined process, not an exception thrown into a log.

And what is our audit story? Every request made, every purpose asserted, every response received, retained and reviewable — the same evidence requirement that has appeared in every chapter of this Part, arriving here from a contract rather than from a regulation.

Next: Chapter 25.33, the rules that decide what any of this data may be used for — HIPAA, protected health information, and what an engineer may and may not do with it.