Health information exchange has been a federal policy priority since the HITECH Act of 2009. After more than 15 years, the infrastructure for exchanging clinical information across organisational boundaries is still fragmented. Providers operate in multiple networks simultaneously — CommonWell, Carequality, DirectTrust — each with different query models, governance structures, and data standards. TEFCA, the Trusted Exchange Framework and Common Agreement, is designed to unify these networks into a single framework with a single on-ramp. Understanding what TEFCA requires and where it changes the architecture is now a foundational question for any health system planning its interoperability strategy.
The Current HIE Landscape: CommonWell, Carequality, and DirectTrust
CommonWell Health Alliance operates a record locator service and patient matching infrastructure that allows EHR vendors to query for patient records across participating organisations. Carequality operates a governance framework and a network of networks that enables document exchange using IHE transaction profiles. Together they cover the majority of US hospital beds and a large share of ambulatory practices.
A bridge agreement between CommonWell and Carequality allows record queries to traverse both networks. A clinician using an EHR connected to CommonWell can retrieve records from an organisation that participates only in Carequality. This interoperability is real but limited: it supports document retrieval via IHE XCA but does not support structured data queries using FHIR R4.
DirectTrust provides governance for the Direct Secure Messaging protocol — an email-like transport for clinical documents between providers. Direct is the technology underlying Meaningful Use Transitions of Care requirements. It is widely deployed but architecturally limited: asynchronous, point-to-point, and without query-retrieve semantics.
TEFCA: Architecture and QHIN Requirements
TEFCA establishes a governance layer above existing networks. Qualified Health Information Networks are the entities that connect directly to TEFCA and provide access to healthcare organisations that connect through them. ONC has designated the first QHINs, including Carequality, CommonWell, and eHealth Exchange.
QHIN technical requirements include FHIR R4 API support conformant with the US Core Implementation Guide, support for five defined exchange purposes (treatment, payment, healthcare operations, individual access, and public health), and identity proofing and security requirements based on NIST 800-63. QHINs must support the TEFCA-defined set of FHIR queries: patient demographics, clinical documents, diagnostic results, medication lists, and immunisation records.
Health systems that connect to TEFCA through a QHIN gain access to the full TEFCA network through a single connection. This significantly reduces the bilateral connection burden that health systems currently manage to achieve broad network connectivity.
Patient Matching: The Persistent Challenge
Accurate patient matching — correctly identifying that two records in different systems belong to the same patient — is the foundational technical challenge of health information exchange. The US healthcare system does not have a national patient identifier. Patient matching relies on demographic data: name, date of birth, address, gender, and identifiers such as Social Security number when available.
Probabilistic matching algorithms trade false positive matches (incorrectly merging records for different patients) against false negative matches (failing to find existing records for the same patient). Both error types create clinical risk. TEFCA mandates a minimum matching algorithm standard, but implementation quality varies significantly across participants. Health systems must validate their patient matching performance before relying on TEFCA-retrieved data for clinical decision-making.
FHIR R4 Query Conformance for TEFCA Participation
Health systems connecting to TEFCA must expose FHIR R4 endpoints that conform to US Core IG profiles. The US Core IG defines must-support elements for each FHIR resource type. Must-support means that the system must be capable of populating these elements when the data exists and must be capable of processing them when received.
Most major EHR platforms provide FHIR R4 APIs that are US Core conformant for standard resource types. The conformance gaps typically appear in non-standard data types specific to the health system — locally-developed order types, custom documentation templates, and specialty-specific data elements not covered by US Core profiles. Health systems must identify and address these gaps before claiming US Core conformance for TEFCA purposes.
The Algorithm Approach: HIE Architecture for TEFCA Readiness
The Algorithm assesses health system interoperability architectures against TEFCA QHIN technical requirements, identifies conformance gaps in existing FHIR implementations, and designs the integration architecture for TEFCA participation. We address patient matching performance through algorithm evaluation and configuration optimisation, and build the operational monitoring capability that detects matching errors at scale. For health systems that have relied heavily on DirectTrust for care coordination, we design the migration path to FHIR Subscription-based event notification that TEFCA enables.
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.