TEFCA explained for product teams: how QHINs, exchange purposes, and USCDI v3 fit together, and what to build before connecting to a partner.
TEFCA is the US nationwide exchange framework published by ONC in January 2022 and operated with the Sequoia Project as Recognized Coordinating Entity, rather than as a single database or API. For product teams seeking TEFCA explained in engineering terms, the roadmap has two tracks: establish an authorized exchange path and make the returned data usable.
The scale makes that distinction important. ONC reports that about 10 million documents were exchanged across TEFCA before 2025 and that 464 million had been exchanged by the end of 2025, in its TEFCA growth history. Your product still owns the work between receiving a response and safely using its contents.
ONC published the framework following a congressional mandate for a common nationwide exchange approach, according to its TEFCA policy overview. The engineering problem is that a product can still encounter separate network contracts, interfaces, and data representations.
The roadmap verdict is to separate network participation from content readiness. Establish the applicable USCDI baseline, then budget independently for identity, authorization, mapping, and reconciliation.
This article is general information, not legal or regulatory advice.
| Piece | Status | What it sets | Engineering job |
|---|---|---|---|
| Trusted Exchange Framework | Federally published principles | Trust and interoperability principles | Map product flows to permitted exchange |
| Common Agreement | Legal contract for QHIN-to-QHIN exchange | Baseline legal and governance duties | Implement applicable flow-down obligations through the connection agreement |
| Technical requirements | Technical specifications under the framework | Consistent connectivity and exchange practices | Implement the authentication, lookup, document exchange, and FHIR patterns applicable to the chosen path |
The Trusted Exchange Framework establishes high-level principles. Product and compliance leads should translate those principles into supported workflows and explicit exclusions.
The Common Agreement governs exchange between networks. Legal and compliance own contractual interpretation, while engineering must produce evidence for the obligations assigned to the application.
The technical requirements establish exchange practices. Engineering owns implementation against the selected partner's documented interface, including error handling and conformance tests.
The Sequoia Project's RCE site is the operational reference for TEFCA governance. QHINs form the backbone, with hospitals, health systems, health information exchanges, public health agencies, payers, and other organizations connecting through participating networks.
For interoperability engineering, keep contractual dependencies separate from application deliverables, and plan them as distinct workstreams rather than grouping everything under a single integration milestone.
Before estimating delivery, mark the unresolved gap as principles, contract flow-down, or connectivity. Assign an owner to each, because an accepted agreement doesn't prove a working interface.
TEFCA exchange is purpose-bound. Confirm the live purpose definitions and applicable operating procedures with the RCE before locking the roadmap, rather than treating an old purpose list as a permanent implementation contract.
Use the following examples as design scenarios, not automatic permission to launch the corresponding feature.
| Purpose | Product example | Production failure |
|---|---|---|
| Treatment | Clinician query during treatment | A treatment query is reused for a commercial feature |
| Payment | Payer request tied to payment | The application can't connect the request to its payment workflow |
| Health care operations | Care-coordination quality workflow | An unrelated analytics job inherits the same access |
| Public health | Public health report | A feed sends more than the purpose allows |
| Government benefits determination | Benefits-determination request | The requester's authority isn't established |
| Individual access services | App acting for the individual | The app can't prove it acts for the person |
The purpose influences who can initiate a request, what supporting evidence is needed, and what the selected exchange path supports. Don't infer that support for one purpose means the partner supports every purpose through the same endpoint or onboarding process.
Treat purpose-to-consent mapping as engineering design constrained by the Common Agreement, applicable operating procedures, and HIPAA. Compliance determines the legal basis and required evidence; engineering implements the decision and preserves its inputs.
Represent the purpose explicitly in the request context. Associate it with the requesting organization, authenticated actor, authorization evidence, and downstream use.
Test rejection paths as carefully as successful queries. A treatment request reused by a commercial feature, an individual-access request without adequate identity evidence, and an oversized public health response should trigger distinct failures, not a generic authorization error.
A Qualified Health Information Network connects its Participants and Subparticipants and interconnects with other QHINs under the Common Agreement. The RCE FAQs explain that a prospective QHIN must be a US entity, complete application, onboarding, and designation, and sign the agreement.
The connection hierarchy helps identify where contractual and technical responsibilities sit.
A startup can connect directly to a QHIN or through a TEFCA-connected network or technology provider. Becoming a QHIN introduces network-level responsibilities that most application roadmaps don't need.
| Boundary | Owner to establish | Evidence to request or produce |
|---|---|---|
| QHIN-to-QHIN exchange | QHIN | Applicable conformance and network obligations |
| Participant onboarding | Participant and customer | Executed agreements and approved configuration |
| Application identity and access | Product engineering | Credential lifecycle, scope configuration, rejection tests |
| Application audit trail | Product engineering and security | Traceable requests, responses, and access events |
| Subcontractor obligations | Legal, compliance, and security | Flow-down clauses and incident responsibilities |
A possible path is application → Subparticipant → Participant → QHIN → responding QHIN. The actual contract and interface should establish which party performs directory lookup, patient discovery, authentication, purpose assertion, and response filtering.
Ask for concrete onboarding artifacts: interface specifications, representative payloads, error definitions, test identities, and incident contacts. A successful connection test won't establish that authorization failures or ambiguous patient matches are handled correctly.
Also settle security and breach-duty flow-down before production. The product team needs to know who investigates an event, who preserves evidence, and who communicates with the customer when a subcontractor is involved.
USCDI defines standardized data classes and elements used in certified health IT. It sets content expectations; the exchange interface and implementation guide determine how an application obtains and represents that content.
For a product using FHIR R4, maintain an element-level mapping rather than a checklist that says “FHIR supported.” For every element the product consumes, record the resource, field, terminology, source, and behavior when data is missing. This mapping separates the content a workflow needs from what an upstream system can provide.
Certification policy establishes the required baseline. The Standards Version Advancement Process, or SVAP, provides a voluntary route to approved newer versions. Product should identify the customer workflow that needs additional elements before engineering changes an integration.
Early adoption has practical costs. Teams may need to review resource profiles and element mappings, update terminology handling and validation fixtures, distinguish unavailable information from empty responses or parser failures, and regression-test against the partner's supported environment.
A newer content version cannot make an upstream EHR return information it does not hold or expose. Request representative responses before committing to features that depend on additional data.
ONC finalized the HTI-5 rule in October 2026. According to the HTI-5 final rule overview, it removes 14 certification criteria, revises seven, and scales back Real World Testing requirements, including those tied to SVAP. Review the final rule against the criteria your customers certify to before changing committed delivery.
USCDI v3 has been the only required version for the applicable certified EHR API criterion since January 1, 2026, under the HTI-1 final rule. This requirement applies to the relevant health IT certification criterion. It does not automatically make every connected startup a certified EHR developer.
| Version | Status | Roadmap action |
|---|---|---|
| USCDI v3 | Required baseline under HTI-1 for the applicable criterion | Baseline the data model and FHIR R4 mapping |
| USCDI v4 to v6 | Approved for voluntary certification through SVAP; USCDI v6 was approved in the 2026 cycle | Build for a named customer need, behind a feature flag |
| HTI-5 final rule | Published October 2026; most changes take effect December 28, 2026 | Check its certification and SVAP changes against the products your customers use |
Translate the baseline into an element inventory. Product owns which elements the workflow needs. Engineering owns their mappings, validation, and tests. Compliance owns applicable certification evidence or the customer attestation file.
For each demographic or clinical element, record its expected resource representation and coded vocabulary. If an EHR omits an element, document the gap rather than filling it with a guessed value.
Keep optional version support behind a feature flag tied to partner capability. This lets engineering test expanded mappings without changing the contract for every customer.
The release evidence should cover positive payloads, missing-data cases, invalid codes, and source-specific exceptions. These checks show whether the application maps the expected content and handles gaps predictably.
Hypothetical example: a patient-facing app connects as a Subparticipant through a Participant already connected to a QHIN. Assume the chosen partner supports the individual-access workflow and the interfaces used below.
The illustration shows the connectivity path, while the application remains responsible for its own data handling.
The app authenticates the person and records individual access as the request purpose.
The Participant submits the query through its QHIN, carrying the purpose assertion and required context.
Responding QHINs use the supported discovery process to locate organizations that may hold records.
Responders return documents or supported FHIR R4 resources within the authorized exchange.
The app evaluates identity evidence across sources and quarantines weak matches instead of merging them automatically.
The application maps supported content to its USCDI baseline, retains source provenance, and normalizes codes without discarding original values.
The app writes an audit record identifying the purpose, source, processing outcome, and information shown.
The dangerous failures are a match that merges different people, authorization evidence that doesn't support the request, and a document that the parser can't reliably convert. Each needs a distinct state and an operational owner.
For a downstream workflow such as a clinical assistant, keep unverified or unparsed content outside the trusted structured-data path. Don't let a retrieval success become an implicit assertion that every extracted fact is correct.
Align security evidence with the applicable HIPAA technical safeguards, including access control, audit controls, integrity, and transmission security. The customer and vendor should agree who configures each control and which test or retained record demonstrates that it works.
A connection alone does not make exchanged records usable. Build the workflow around explicit contracts: compliance owns the authorization decision, engineering owns identity resolution and data handling, and security owners define the control evidence they retain.
Choose one exchange purpose and define how the product will verify that a request meets it. Then select a connection partner and translate its contractual duties into engineering acceptance criteria. Keep the content baseline stable until a named workflow requires an upgrade.
Before adding sources, specify how the application handles patient matching, duplicates, and provenance. For each security control, assign an owner and define how configuration and testing will be evidenced. Start with a proof of concept using representative partner payloads, then expand only after the workflow passes its acceptance tests.
For the security side of the build, our guide to HIPAA compliance for software development covers the safeguards most teams need to evidence.
Ekipa AI's implementation support works within the client's development processes, alongside internal developers, product managers, and regulatory stakeholders, with SaMD-aligned documentation, validation readiness, and traceability where applicable.
TEFCA sits alongside the APIs your product already uses. Our guides to SMART on FHIR, bulk FHIR export, and EHR integration and interoperability cover the other exchange paths a product team is likely to need.
TEFCA gives product teams a nationwide, purpose-bound path to exchange health records through QHINs, and USCDI defines the data content they can expect. Neither makes exchanged data usable on its own. Pick one exchange purpose, choose a connection partner, map USCDI v3 elements to your FHIR resources, and assign owners for authorization, patient matching, provenance, and security evidence before you expand. To plan and build a TEFCA-ready integration, explore Ekipa's HealthTech engineering and implementation support, or book a consultation.
TEFCA, the Trusted Exchange Framework and Common Agreement, is a nationwide framework for exchanging health information in the US. Qualified Health Information Networks (QHINs) connect to each other under a common legal agreement and technical requirements, and organizations connect through them.
A Qualified Health Information Network is a network designated to exchange data with other QHINs under the Common Agreement. Hospitals, health information exchanges, payers, and technology companies connect to TEFCA as Participants or Subparticipants of a QHIN.
No. Most product teams connect through an existing QHIN, a Participant, or a technology partner. Becoming a QHIN brings network-level obligations that most applications do not need.
TEFCA governs who can exchange data, for which purposes, and through which networks. USCDI defines the standardized data classes and elements that certified health IT supports. A product needs both: an authorized exchange path and a mapping of the data it receives.
Choose a purpose tied to one defined user workflow, then have compliance approve the authorization decision and the evidence the product must retain. Keep the pilot narrow enough to test whether partner payloads support that workflow.
Keep uncertain records out of the trusted structured-data path and assign an operational owner to review them. Treat identity uncertainty as a distinct state, not as permission to merge records automatically.
Bulk FHIR Export explained for data engineers: $export levels, async NDJSON downloads, SMART Backend Services auth and the ONC 170.315(g)(10) requirement.
CDS Hooks explained: how this HL7 standard calls external decision support from EHR workflows, with hooks, cards, prefetch, and a worked example.
FHIR server comparison of HAPI FHIR, AWS HealthLake, Azure and Google Cloud: version, SMART, bulk export, HL7 v2, HIPAA and lock-in.
Connect with our team to explore how AI expertise can transform your business.