TEFCA vs FHIR: what each one actually does

TEFCA (Trusted Exchange Framework and Common Agreement) is the legal and trust framework that lets US healthcare organizations exchange records nationwide through Qualified Health Information Networks. FHIR (Fast Healthcare Interoperability Resources) is the HL7 API standard that defines how a single system exposes and consumes clinical data. TEFCA governs who may exchange and under what rules; FHIR governs what the exchange looks like on the wire.

The confusion between the two is not academic. We have watched teams budget a quarter for "TEFCA integration" and spend it building FHIR resource endpoints that no network would ever call, and teams ship a conformant FHIR R4 server and then discover that nationwide record exchange still requires a trust framework, participation agreements, and a QHIN connection they had not scoped. When we built a FHIR R4 platform with TEFCA connectivity, the two workstreams shared almost no code: one produced resource providers and an OAuth surface, the other produced adapters, agreements, and a partner registry.

What FHIR actually covers

FHIR R4 defines a resource model, Patient, Encounter, Observation, Coverage, and roughly 140 more, and a REST API for reading, writing, and searching those resources. It also defines the machinery around them: search parameters, bundles for batching, operations like $everything for chart pulls, subscriptions for change notification, and Bulk Data for population-level export.

What FHIR deliberately does not define is trust. Nothing in the specification says who is allowed to call your endpoint, what legal agreement covers the exchange, or how a hospital in Ohio finds the record of a patient who walked in from Texas. FHIR assumes the two parties have already decided to talk; it standardizes the conversation.

In practice a production FHIR surface also means profiles. Base FHIR is permissive by design, so US exchange runs on constraint sets: US Core pins which fields and terminologies are mandatory, CARIN BB shapes claims data for patient access, the Da Vinci guides cover prior authorization and payer data exchange. A server that claims R4 conformance but ignores the profile layer will validate nothing a real partner sends.

What TEFCA actually covers

TEFCA exists because point-to-point agreements do not scale to a country. Before it, meaningful reach meant joining several exchange networks with different agreements, different technical floors, and different politics. TEFCA's answer is a two-level structure: a small number of designated QHINs (Qualified Health Information Networks) connect to each other under one Common Agreement, and everyone else connects through a QHIN as a participant or subparticipant.

The framework covers the parts FHIR leaves out. The Common Agreement defines the legal terms every participant inherits. Exchange purposes define why you may query: treatment, payment, individual access, public health. The RCE (Recognized Coordinating Entity) polices designation and conformance. And the technical floor defines the minimum exchange functions a QHIN must support: patient discovery, record query, message delivery.

Note what that floor was built on: IHE document exchange, the XCA and XCPD family, not FHIR. Nationwide exchange predates FHIR maturity, and the installed base is document-shaped. TEFCA's FHIR roadmap is moving the framework toward native FHIR exchange, and newer Common Agreement versions formalize it, but a team scoping TEFCA work today should expect both worlds: document query for reach, FHIR for the direction of travel.

TEFCA vs FHIR side by side

The shorthand that survives contact with real projects: FHIR is how one endpoint speaks. TEFCA is who is allowed to ask, and through which network.

Where the two meet in a real build

They meet in the adapter layer, and keeping them there is the difference between a platform and a hairball. On the platform we built, TEFCA operations like patient discovery and document query live behind a typed adapter contract per network partner. Epic Nexus, CommonWell, and eHealth Exchange handshakes coexist behind that one contract; each partner's quirks, and every network has them, stay inside its adapter instead of leaking into business logic. Onboarding a new partner became a row in a trusted-partner registry, not a code change.

The same separation shows up in security. The FHIR side authenticates apps: SMART on FHIR v2.1 with PKCE, scopes enforced per endpoint from token claims. The TEFCA side authenticates organizations: certificates, signed agreements, exchange-purpose assertions. Different problems, different machinery, and an audit trail that has to cover both, every cross-network read traceable to the authority that permitted it. That trail is also what an info-blocking review will actually examine.

One more meeting point deserves mention: consent. TEFCA's individual-access purpose and FHIR's Consent resource address the same human question from two directions. A platform that scopes every read and write to the Consent that authorized it passes review; a platform that treats consent as paperwork discovers gaps it cannot close incrementally.

What you build for each

For FHIR: resource providers against the profiles your partners actually use, a terminology service so ValueSet expansion and code validation do not drift across consumers, an OAuth surface conformant enough that third-party apps self-configure from your well-known endpoints, and Bulk Data jobs that survive multi-million-resource pulls. This is API engineering with a compliance gradient, the kind of build we describe in our interoperability platform case.

For TEFCA: a decision first, then adapters. The decision is your participation mode, direct QHIN participant or subparticipant through an intermediary, and it is a business decision with technical consequences, not the reverse. Then the engineering: an adapter per network behavior, a registry that makes partners configuration instead of code, and the audit chain that proves every exchange happened under a valid purpose.

If your consumers are internal teams rather than national networks, the same separation of contract from source quirks applies one level down; that is the shape of our clinical data aggregation hub. And if the deliverable is moving actual files under audit rather than resources under OAuth, the trust problem reappears in miniature: scoped tokens, virus scanning, retention rules, the pattern of our HIPAA audited file proxy.

Neither standard is optional for a serious US health data platform anymore. But they are not competitors and never were: one is the road network, the other is the vehicle specification. Budget them as separate workstreams, wire them together at the adapter layer, and audit everything that crosses the boundary.