TEFCA Data Exchange Requires Lineage Across Every FHIR Endpoint

The Trusted Exchange Framework and Common Agreement, TEFCA, is expanding Qualified Health Information Network participation through 2026, and ONC's push is working: more health systems are exchanging patient records through FHIR based APIs instead of one off interface files. For a hospital system or health plan, that means protected health information increasingly leaves the electronic health record through a QHIN connection built on FHIR R4, not just through the batch extracts a data team already knows how to watch. Most data catalogs can show which tables inside the EHR or data warehouse hold a given patient field. Far fewer can show what the interface engine code does to that field on its way out to a QHIN, or confirm that the record a partner organization received matches the one the EHR actually produced. Proving that match is not a cataloging problem. It requires tracing the integration code itself, the mapping scripts and FHIR facing services that sit between the EHR and the exchange network, which is where TEFCA's accounting of disclosures requirement actually gets tested.

What TEFCA Requires for FHIR Based Exchange

TEFCA runs on a Common Agreement that every Qualified Health Information Network and its Participants and Subparticipants sign, and ASTP's 2026 guidance keeps pushing exchange toward FHIR R4 as the default API format rather than older point to point interfaces. A Participant has to be able to account for who requested a given patient's data and what was actually disclosed, not just confirm that a request was technically fulfilled. That accounting assumes the organization can trace a specific field, say a diagnosis code or a lab result, from the system that originated it through every transformation it passed through before it reached the requesting QHIN. Most health systems can answer where that field lives today. Far fewer can answer what code touched it between the EHR and the FHIR endpoint that sent it out the door.

Why the Interface Engine Is the Actual Blind Spot

Between an EHR and a QHIN sits an integration layer that most governance tooling never looks at directly: HL7 v2 to FHIR interface engines, custom mapping scripts, and the Java or Python services that enrich a record before it leaves the organization's boundary. A catalog tool can show that a patient table exists and that a FHIR endpoint publishes data. It cannot show that a mapping script silently dropped a qualifier on a lab result, or that a code value was translated incorrectly between an internal terminology and the standard FHIR CodeSystem a partner expects. That gap matters because TEFCA exchange is bidirectional. A health system is both sending records out through its own integration code and receiving records from partners, and a quality or compliance issue can originate on either side of that boundary.

What Is a QHIN?

A Qualified Health Information Network, or QHIN, is an organization that has signed TEFCA's Common Agreement and connects health systems, health plans, and other Participants so they can exchange patient data under one shared set of exchange rules rather than negotiating bilateral interfaces with every partner. A QHIN's own technical infrastructure, and the FHIR based APIs it requires Participants to support, is what makes a single connection usable for exchanging records with every other organization on the network instead of just one.

What Good Looks Like

Foundational analyzes source code directly, including the interface engines, mapping scripts, and FHIR facing services that move protected health information between an EHR and a QHIN connection, not only the warehouse tables those systems eventually land in. That is the broader scope a healthcare data exchange problem actually needs: established integration layers and custom application code, not just the pipelines a typical catalog tool was built to watch. As a data and AI governance platform, Foundational builds a live, code derived map of how a field travels from the originating system through every transformation to the FHIR endpoint that discloses it, so a data engineering team can answer what happened to a specific field on a specific exchange without reconstructing the interface logic by hand.

Ramp uses this approach to hold lineage accuracy steady as its engineering organization scales. Kevin Chao, its Analytics Engineering Lead, has seen build success rates improve from 85 percent to 95 percent while governing more than 40 engineers and 100 or more pull requests a week, the kind of throughput a TEFCA integration layer sees once a health system connects to multiple QHINs rather than one.

Frequently Asked Questions

Does TEFCA require a specific lineage or audit trail technology?
No. The Common Agreement sets the exchange and accounting of disclosures requirements, not the technical method a Participant uses to meet them. Most organizations currently meet that bar with manual logs and point in time reviews of their integration code, which holds up until a disclosure question requires tracing a field back through several transformation steps quickly.

What is the difference between HL7 v2 and FHIR for TEFCA exchange?
HL7 v2 is the older, message based standard most EHRs still use internally for things like admission and lab result feeds. FHIR is the API based standard TEFCA and ASTP are pushing Participants toward for exchange with QHINs. Most health systems run interface engines that translate between the two, which is exactly where a field can drift from what the EHR originally recorded.

Can a data catalog satisfy TEFCA's accounting of disclosures requirement on its own?
Not reliably. A catalog documents where data sits and often where it moved according to observed query activity, but it was not built to trace the specific mapping and transformation logic inside an interface engine. Meeting an accounting of disclosures request accurately depends on tracing the code that moved and changed the field, not just the tables it touched along the way.

Why does this matter more as QHIN participation grows?
Every additional QHIN connection is another FHIR endpoint, another set of mapping rules, and another place a field can be transformed differently than it was for a different partner. A health system that can trace lineage through its own integration code scales that complexity without losing the ability to answer a disclosure or audit question for any single connection.

Where to Go From Here

TEFCA is pushing health data exchange past the EHR and into a web of FHIR endpoints and integration code that most governance tooling was never built to see. See how a data catalog differs from a true lineage tool when it comes to tracing fields through that kind of integration layer, or read what deterministic lineage means when the source is source code rather than query logs. To see your own FHIR and interface engine code mapped this way, request a demo.