06 Oct
An EHR platform connected to a QHIN network a while back, mostly to query other organizations for read access when a patient showed up with an unfamiliar history. Answering someone else’s query was theoretical. As of August 2026, for a lot of connected EHR vendors, it isn’t theoretical anymore, and the EHR’s ability to actually produce a usable response is about to get tested whether the product team planned for it or not. The engineering roadmap that never budgeted time for this is the one about to find out the hard way.
What changed for an EHR connected to a QHIN network on August 3, 2026?
The Sequoia Project, which operates as TEFCA’s Recognized Coordinating Entity, confirms that the IAS Exchange Purpose Implementation SOP version 3.0 became effective on August 3, 2026, widening the set of organizations obligated to respond to treatment-purpose queries under TEFCA. An EHR vendor whose platform connects through a QHIN as a Participant or Subparticipant inherits that response obligation directly, and the SOP update enforces it more consistently than before, regardless of whether the EHR’s engineering team ever built a response workflow with real traffic in mind.
ONC has framed this shift plainly: as QHINs operationalized what the agency calls TEFCA Required Treatment under the Treatment Exchange Purpose, additional vetting became necessary to hold connected organizations to the obligation the Common Agreement already described. The obligation isn’t new. What’s new is how reliably an EHR vendor’s actual response capability gets tested against it.
Does this apply to your EHR even if you never actively pursued TEFCA participation?
Possibly, and this is the question worth running down internally before a query arrives and forces the answer. An EHR platform doesn’t have to be a QHIN itself to be caught by this. Any Participant or Subparticipant connection, including ones set up years ago through a health information exchange partnership or a customer’s own network connection, inherits the response obligation the Common Agreement and Terms of Participation define. A product or compliance team that hasn’t revisited the EHR’s TEFCA connections recently may not know which of its deployments are actually in scope.
What does 'respond to a treatment query' actually require an EHR to produce?
In practice, a treatment-purpose response still typically travels as a C-CDA document, since that remains the standard most exchange partners expect for this kind of query, even as facilitated FHIR exchange expands. That means the response obligation isn’t just a network configuration question. It’s a question about whether the EHR can actually generate a complete, well-structured document on demand, not just a document that technically validates.
An EHR that has never had its response documents tested against a real treatment query is in an uncertain position the first time a real one arrives. The obligation to respond and the ability to respond usefully are two separate things, and only one of them shows up in a network configuration check. A product team that has only ever validated the connection, not the document, is missing the half that actually determines whether the response is useful to whoever requested it.
Why does the USCDI conformance floor make this a moving target for your EHR?
The bar an EHR’s response document has to clear doesn’t stay fixed. ONC’s HTI-1 Final Rule adopted USCDI Version 3 as the certification baseline effective January 1, 2026, meaning certified EHR modules already need to support USCDI v3 data elements using FHIR US Core 6.1.0 and the C-CDA Companion Guide Release 4.1. An EHR’s response documents built against an older baseline may already be falling short of what a receiving organization expects, independent of the TEFCA obligation question entirely.
| What your EHR’s network status tells you | What it doesn’t tell you |
|---|---|
| Whether the EHR is connected through a QHIN as a Participant or Subparticipant | Whether the EHR’s response document actually meets current USCDI v3 and C-CDA baseline requirements |
| Whether the connection falls within the scope widened by the August 2026 SOP | Whether the EHR’s structured entries carry the clinical detail a receiving system expects, or lean on narrative text instead |
| Whether the EHR is contractually obligated to respond | Whether the EHR has ever actually been tested against a real treatment-purpose query |
What happens to an EHR that can't produce a usable response?
Nothing about TEFCA’s enforcement mechanism forces an EHR to generate a perfect response overnight, but a pattern of thin or incomplete responses doesn’t stay invisible either. Receiving organizations and QHINs both have visibility into response quality over time, and an EHR vendor with a reputation for technically-on-time but clinically incomplete responses risks that becoming a factor in how customers and network partners evaluate the platform going forward, separate from any formal compliance action.
For an EHR vendor selling into health systems that care about their own TEFCA standing, this compounds quickly. A hospital or health system choosing between EHR platforms increasingly treats network response quality as part of the evaluation, the same way FHIR API support became a baseline expectation rather than a differentiator. An EHR that can point to a tested, scored response document is answering that evaluation question before it’s asked instead of discovering the gap during a customer’s own due diligence, at a point in the sales cycle where discovering it costs far more.
How do you test whether your EHR can actually answer a treatment query today?
The only reliable way to know is to generate a sample response document, the way the EHR would for a real treatment query, using synthetic or de-identified patient data, and check it directly rather than assuming the network connection means the document behind it is ready.
- Confirm the EHR’s QHIN, Participant, or Subparticipant status and whether it falls within the scope widened by the August 2026 SOP.
- Generate a sample C-CDA document the EHR would produce in response to a treatment query, using synthetic or de-identified data.
- Check that document against current USCDI v3 and C-CDA Companion Guide R4.1 expectations, not whatever baseline the EHR was originally built against.
- Flag any section where the EHR’s output leans on narrative text with thin structured entries, since that weakens a response even when it’s technically delivered on time, and note it as a specific finding.
Hgear’s free C-CDA Scorecard grades a C-CDA document against expected structure and completeness, flagging exactly which sections are thin or narrative-only. Running a sample of what the EHR would actually generate through it, using synthetic or de-identified data, turns an assumption about response-readiness into a documented answer, before a real query tests it instead. That documented answer is also something a product or compliance team can point to directly, rather than a general assurance that the platform is probably fine.
Want to know if your EHR can actually answer a treatment query?
Hgear’s free C-CDA Scorecard is built for exactly this kind of check. Run a sample document your EHR would generate in response to a treatment query, using synthetic or de-identified data, and see where it actually stands.
FAQs
Under TEFCA's Common Agreement and Terms of Participation, an EHR platform connected through a QHIN as a Participant or Subparticipant can be contractually obligated to respond to in-scope treatment-purpose queries. The Sequoia Project, TEFCA's Recognized Coordinating Entity, confirmed that an updated Exchange Purpose Implementation SOP widening this scope took effect on August 3, 2026.
Start by confirming the EHR's status as a QHIN, Participant, or Subparticipant, and whether that connection falls within the treatment-purpose response scope described in the current Exchange Purpose Implementation SOP published by the Sequoia Project.
Most treatment-purpose responses under TEFCA still travel as C-CDA documents rather than discrete FHIR resources. Facilitated FHIR exchange is expanding under TEFCA's roadmap, but C-CDA document quality remains the practical thing an EHR vendor needs to verify today.
ONC's HTI-1 Final Rule set USCDI Version 3 as the certification baseline effective January 1, 2026, using FHIR US Core 6.1.0 and the C-CDA Companion Guide Release 4.1. An EHR's response documents should be checked against this current baseline rather than whatever standard the platform was originally built against.
Yes. Hgear's free C-CDA Scorecard is built to be run against synthetic or de-identified sample documents, so an EHR vendor can check response readiness without any real patient data entering the evaluation.
No. Being contractually obligated under TEFCA's Common Agreement is a network status question. Being response-ready is a document quality question, specifically whether the EHR's C-CDA output carries complete, current structured entries rather than relying on narrative text a receiving system may not fully process.
ISO 27001:2022 Certified
Aigilx health specializes in developing Interoperability solutions to create a healthcare ecosystem and aids in the delivery of efficient, patient-centric and population-focused healthcare.
