Your product needs records from providers you have no contract with, and point-to-point interfaces do not scale to the whole country. Agnotic Technologies builds your connection to TEFCA through a Qualified Health Information Network: query, retrieve, consent, directory entries and the audit trail, delivered as a fixed first release.
Trusted by global innovators
TEFCA, the Trusted Exchange Framework and Common Agreement, is the US framework for nationwide health information exchange through Qualified Health Information Networks (QHINs). A provider, payer or health tech product connects as a Participant or Subparticipant of a QHIN. Agnotic Technologies builds that connection for you: the query and retrieve interfaces, consent handling, directory entries and the audit trail.
The 21st Century Cures Act asked ONC (ASTP) to develop the framework. ONC chose The Sequoia Project as the Recognized Coordinating Entity (RCE), which runs QHIN onboarding and publishes the Common Agreement and its standard operating procedures.
For a software team, TEFCA is less a product than a set of obligations. You join through a QHIN, you state an Exchange Purpose on every request, and you must respond to the requests that the Common Agreement says you must respond to.
Exchange Purposes
Every request under TEFCA names its purpose, and the purpose decides who must respond and what consent is needed. The Common Agreement defines these Exchange Purposes today, and the RCE can add more.
The parties
A QHIN is a network that completed the RCE's onboarding and signed the Common Agreement. QHINs connect to each other, so a request from one QHIN reaches patients held by any other.
A Participant signs an agreement with a QHIN to exchange through it. A Subparticipant connects through a Participant. Health systems, HIEs, payers and health tech vendors can sit at either level, and the contract terms flow down from the Common Agreement.
Decision table
There are three practical ways to reach TEFCA exchange. The right one depends on your volume, your contracts and how much of the network plumbing you want to own.
| Path | Who it suits | What we build | Trade-off |
|---|---|---|---|
| Participant of a QHIN | Health systems, HIEs, payers and vendors with many customers | IHE XCPD and XCA or FHIR interfaces to the QHIN, directory entries, consent and audit | Most control and the most obligations to respond |
| Subparticipant through a Participant | Startups and single products that serve a Participant's customers | Integration with the Participant's gateway, purpose tagging, record reconciliation | Faster to start, dependent on the Participant's terms |
| QHIN API platform | Teams that want records as an API call, not a network project | Client against the QHIN's API, patient matching, consent flows, retrieval into your data model | Simplest build, platform fees and limits apply |
Some QHINs offer their network as a developer API. Our Health Gorilla QHIN integration page covers that route in detail.
Your product asks its QHIN for a patient's records for a stated Exchange Purpose. The QHIN finds the patient across other QHINs, Participants return documents or FHIR resources, and every step is logged.
Reference architecture
Three layers: the exchange interfaces, the operational controls the Common Agreement expects, and the part that makes retrieved records usable in your product.
Onboarding with a QHIN and engineering run as parallel tracks, so the connection is live when the paperwork is.
We confirm your Exchange Purposes, whether you will respond to requests, which path fits and what a fixed first release contains.
Participant or Subparticipant agreements, certificates and directory entries, with our build running against the QHIN's test environment and synthetic patients.
Query and retrieve for one purpose, document parsing into your model, consent and audit, then conformance testing with the QHIN.
Go-live with monitoring of query volumes, failures and response times, a runbook for incidents, and a plan for Common Agreement and SOP updates.
Failure points
The network works. Projects stall on contracts, identity and the volume of records that come back.
Challenge
Treating TEFCA as an API subscription
Agnotic approach
We map your obligations under the Common Agreement first, including the requests you must respond to, so legal and engineering scope the same thing.
Challenge
Too many documents, no usable record
Agnotic approach
Retrieved C-CDAs are parsed, de-duplicated and reconciled into one patient view with provenance, instead of a list of PDFs.
Challenge
Patient matching errors across networks
Agnotic approach
Demographic matching with configurable thresholds, a review queue for uncertain matches and no silent merges.
Challenge
Wrong or missing Exchange Purpose
Agnotic approach
Purpose is a required field in the integration layer, carried in the request assertion and checked on every inbound request.
Challenge
Individual Access Services without identity proofing
Agnotic approach
Identity verification and consent capture are built into the individual access flow before any query is sent.
Challenge
No plan for SOP and version changes
Agnotic approach
The RCE updates SOPs and the Common Agreement. We keep the exchange layer separate from your product so updates do not mean a rewrite.
Scope drivers
No two TEFCA projects cost the same. These are the factors that move the effort, and we size each one on the scoping call.
Querying for records is one build. Responding to Treatment requests adds endpoints, availability targets and more testing.
Treatment alone is simplest. Individual Access Services adds identity proofing and consent; Payment and Operations add policy checks.
Document exchange over XCPD and XCA is the baseline today. Facilitated FHIR is growing and may be worth building in parallel.
Showing documents is quick. Turning them into reconciled problems, medications and results in your data model is the bulk of the work.
Participant, Subparticipant and QHIN API paths carry different contracts and platform fees, which we help you compare but do not set.
Teams with FHIR and C-CDA handling already in place reuse it. Startups building their first record pipeline need it designed alongside.
Who connects
The same network, used by different parts of healthcare.
Care navigation, second opinion and chronic care products that need outside records for Treatment.
Records from unaffiliated providers at intake, and responding to Treatment requests from others.
Payment and Health Care Operations exchange with providers without point-to-point contracts.
Individual Access Services so people can pull their own records into one place.
Connecting an existing exchange to the national network as a Participant.
Public Health queries and reporting through a QHIN.
HIPAA still applies to every party, and the Common Agreement adds its own privacy, security and consent requirements on top. We treat them as engineering decisions.
Agnotic signs a BAA before any PHI is shared, and we build and test against synthetic patients in the QHIN's test environment.
Consent is captured and stored with the request it authorises, and individual access flows verify identity before a query is sent.
The Exchange Purpose decides what is requested and what is returned, and the integration layer enforces it on both sides.
Every query and document access is logged with purpose and user, and the incident process reaches the QHIN inside the agreed timeframes.
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, strict access controls, and traceable audit logs.
General Data Protection Regulation
Implement lawful consent flows, data minimization, retention controls, and secure processing for sensitive health data.
Fast Healthcare Interoperability Resources
Enable standardized health data exchange across apps, care teams, and systems through standards-based FHIR APIs.
Health Level Seven International
Support enterprise-grade interoperability with HL7-based integrations for records, events, and clinical messaging workflows.
Health Information Trust Alliance
Align security programs to healthcare-specific control and risk management practices trusted by providers and ecosystem partners.
Health Information Technology for Economic and Clinical Health Act
Design with breach notification readiness, digital record safeguards, and operational controls that support regulated care programs.
FDA Software as a Medical Device
Plan software quality, traceability, and documentation pathways for products that may require SaMD review and submission.
Medical Device Regulation (European Union)
Prepare EU market-ready processes for risk classification, evidence tracking, and lifecycle governance under MDR expectations.
Substance Abuse and Mental Health Services Administration
Apply confidentiality controls and consent-aware sharing models for behavioral and mental health data experiences.
Standards in scope
Short facts we design around, each linked to its primary source.
The Trusted Exchange Framework is a set of non-binding principles for health information exchange, and the Common Agreement is the legal contract that Qualified Health Information Networks sign to exchange data under TEFCA. Both were called for by the 21st Century Cures Act of 2016.
Source: Recognized Coordinating Entity, Common AgreementONC chose The Sequoia Project as the Recognized Coordinating Entity (RCE) that supports the implementation of the Trusted Exchange Framework and Common Agreement.
Source: The Sequoia Project, RCEQHINs are the central connection points of TEFCA and together form its network of networks; every TEFCA request must state the Exchange Purpose it is made for.
Source: The Sequoia Project (RCE), TEFCA and RCE resourcesUnder the TEFCA manner exception, an actor that fulfils a request for electronic health information only through TEFCA is not information blocking, provided both the actor and the requestor are part of TEFCA and the requestor can exchange that way.
Source: 45 CFR 171.403 (eCFR)HL7 FHIR is a standard published by HL7 International for exchanging health data through RESTful APIs built on defined resources such as Patient, Observation and MedicationRequest.
Source: HL7 International (hl7.org/fhir)
