25 Sep
A readiness audit built a year ago probably checks the things that mattered then: FHIR API support, HL7 v2 or C-CDA export quality, maybe a Da Vinci implementation guide or two. What it likely doesn’t check is whether the client is now on the hook to respond to a TEFCA treatment query it could have quietly ignored before August 2026. That gap in the audit doesn’t announce itself. The client finds out the hard way, when a query comes in and nobody on their side knows whether they’re required to answer it.
What changed in TEFCA 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. This isn’t a new law or a new final rule. It’s an operational update to how an existing framework enforces an obligation that was already written into the Common Agreement, applied now to a broader set of Participants and Subparticipants than before.
ONC has been explicit about why this kind of tightening keeps happening. As the agency put it in a recent post on what makes TEFCA different, additional vetting became necessary as QHINs operationalized what the agency calls TEFCA Required Treatment under the Treatment Exchange Purpose. In other words, the obligation to respond has existed on paper for a while. What August’s SOP changed is how consistently it gets enforced against organizations that connect through a QHIN, directly or as a Subparticipant.
Which of your clients are now covered by an obligation they didn't have before?
This is the question worth running down for every active engagement, not just the ones with an interoperability project already in scope. A client doesn’t have to be a QHIN itself to be caught by this. Any Participant or Subparticipant connected through a QHIN network, which by now includes a wide range of hospitals, health systems, and increasingly ambulatory and specialty practices, inherits the response obligation the Common Agreement and Terms of Participation define for treatment-purpose requests.
A client who joined a QHIN network eighteen months ago for read access, expecting mostly to query other organizations rather than answer their own queries, may not have revisited what they signed up to provide in return. That’s a natural audit finding, and it’s one most existing readiness checklists were not built to catch, because the checklist predates the enforcement tightening that makes it matter. Even clients who never actively pursued QHIN participation can be pulled in indirectly, through an EHR vendor’s own network connections or a health information exchange partnership signed years before TEFCA’s Common Agreement existed in its current form.
Why does the distinction between permitted, expected, and obligated matter for your audit?
Three separate layers govern whether a client actually has to answer a treatment query, and conflating them is an easy way to miss a real gap. The HIPAA Privacy Rule permits sharing for treatment purposes but does not by itself require a response. Information blocking regulations shift that posture from permitted to expected, treating an unjustified refusal to share as a compliance problem. TEFCA’s Common Agreement and Terms of Participation go a step further for anyone connected through the network: for in-scope requests, sharing isn’t just expected, it’s a contractual obligation with real consequences for noncompliance.
| Layer | What it says about sharing | What it means for your client |
|---|---|---|
| HIPAA Privacy Rule | Permits treatment-purpose sharing | Not itself grounds to refuse or a mandate to respond |
| Information blocking regulations | Sets a general expectation to share | Unjustified refusal risks an information blocking finding |
| TEFCA Common Agreement / Terms of Participation | Obligates in-scope treatment responses for connected organizations | A contractual response obligation, now vetted more consistently after August 2026 |
What should a TEFCA response-obligation check actually test?
Confirming a client is technically obligated to respond only answers half the question. The other half is whether they actually can, in a form that would satisfy the request. That’s a document quality question as much as a policy one, since most treatment-purpose responses still travel as C-CDA documents rather than discrete FHIR resources.
- Confirm the client’s QHIN, Participant, or Subparticipant status and whether it falls within the scope widened by the August 2026 SOP.
- Pull a sample of the C-CDA document the client’s system would actually generate in response to a treatment query, using synthetic or de-identified patient data.
- Check that document for the sections a treatment response is expected to carry: problems, medications, allergies, and results, at minimum.
- Flag any section where the generated document leans on narrative text with thin or absent structured entries, since that weakens the response even when it’s technically delivered.
- Document the finding in plain terms for the client: covered or not covered, and response-ready or not, as two separate answers.
How do you add this to an audit without slowing the engagement down?
The obligation check itself is a quick scope-and-status question, and it belongs early in the engagement alongside the other compliance-posture items. The document-quality piece is the part that used to require either manual review of a sample export or a vendor conversation that ate a week of the timeline. It doesn’t have to anymore.
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, by file path, in minutes. Running a client’s synthetic or de-identified sample export through the Scorecard turns the document-quality half of this check into a repeatable step in a playbook rather than a one-off manual review, and it produces a concrete artifact worth including in the audit deliverable itself.
How do you position this as a billable part of the engagement?
A finding this concrete is easier to scope than most compliance additions, because it produces two distinct deliverables a client can act on separately: a status determination, covered or not covered under the widened SOP, and a readiness score for the document their system actually generates. Neither requires new tooling on the client’s side or a lengthy discovery phase, which makes it a reasonable fixed-fee add-on to an existing readiness audit rather than a separate statement of work.
For engagements already underway, this reads naturally as a scope addendum rather than a renegotiation: a defined check, with a defined output, tied to a dated regulatory change the client can independently verify happened. For new engagements, it belongs in the standard audit template going forward, since the August 2026 enforcement tightening isn’t a one-time event to note and move past. The obligation itself was already there. What changed is how often it gets tested, and a client’s exposure doesn’t reset once this audit cycle ends.
Want a repeatable way to grade a client's response-readiness?
Hgear’s free C-CDA Scorecard is built for exactly this kind of check inside a readiness audit. Run a synthetic or de-identified sample export through it and add a concrete, documented finding to the engagement instead of a guess.
FAQs
Under TEFCA's Common Agreement and Terms of Participation, organizations 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.
HIPAA's Privacy Rule permits treatment-purpose sharing without requiring it. Information blocking regulations create a general expectation to share by treating unjustified refusal as a compliance risk. TEFCA's Common Agreement goes further for connected organizations, creating a direct contractual obligation to respond to certain treatment requests.
Start by confirming the client's status as a QHIN, Participant, or Subparticipant, and whether their connection falls within the treatment-purpose response scope described in the current Exchange Purpose Implementation SOP published by the Sequoia Project as TEFCA's Recognized Coordinating Entity.
Most treatment-purpose responses under TEFCA still travel as C-CDA documents rather than discrete FHIR resources, since C-CDA remains the standard tied to certified health IT's data export requirements. Facilitated FHIR exchange is expanding under TEFCA's roadmap, but C-CDA quality remains the practical thing to check today.
Yes. Hgear's free C-CDA Scorecard is built to be run against synthetic or de-identified sample C-CDA documents, so a consultant can grade a client's document structure and completeness without any real patient data entering the engagement.
Being contractually obligated under TEFCA's Common Agreement is a status question. Being response-ready is a document quality question: whether the C-CDA the client's system actually generates carries complete structured entries for the sections a treatment response needs, rather than leaning 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.
