TEFCA exchange needs agreement-and-SOP version pairing
The Recognized Coordinating Entity describes the TEFCA Common Agreement as a contract supported by technical infrastructure, governance, and standard operating procedures, with Version 2 adding FHIR-based exchange. Each production exchange still needs the exact agreement, SOP, technical framework, role, purpose, and implementation version that governed it.
Editorial figure by Health Interoperability Review. Source context: TEFCA Common Agreement.
Identify the governing stack for the exchange
The direct answer is that TEFCA should not be represented as one undifferentiated version label. For an exchange, retain the Common Agreement version and effective period, Qualified Health Information Network Technical Framework version, applicable standard operating procedures and implementation dates, exchange purpose, transaction or API pattern, required technical specifications, and any approved change-management or transition terms. Link each document to its official source and the contractual or operational relationship that makes it applicable.
Different instruments answer different questions. The Common Agreement establishes contractual governance, the technical framework defines network requirements, SOPs govern particular processes, and standards or implementation guides define message behavior. A FHIR endpoint version alone does not identify the agreement terms, exchange purpose, participant obligations, authorization pattern, or operating procedure that governed a request. Preserve those layers without merging their statuses or dates.
Carry role and purpose through the participant chain
The record should name the QHIN, Participant, Subparticipant, initiating and responding actors, intermediaries, individual-access service role where relevant, and the contractual path among them. Retain organizational identifiers, endpoint and directory versions, exchange purpose, requester representation, subject and patient-matching evidence, authorization or consent basis where applicable, data requested, minimum-necessary or scope decisions, and the owner responsible for each step.
A participant's general TEFCA connection does not establish that every affiliate, customer, endpoint, purpose, data class, or route is available. It also does not authorize a disclosure or prove that a receiver may use the data for a proposed purpose. Keep network eligibility, technical reachability, request validation, disclosure decision, transport result, receipt, reconciliation, and downstream use as separate evidence states. Qualified privacy, security, legal, clinical, and operational owners retain their decisions.
Version FHIR exchange and exceptions independently
For a FHIR-based exchange, record the base FHIR release, implementation guide and version, profiles, resources, terminology packages, authorization flow, scopes, endpoint capability statement, validation results, and server and client software versions. Then bind those technical facts to the relevant TEFCA instrument and transition period. Common Agreement Version 2's support for FHIR-based exchange does not by itself establish conformance, production availability, semantic completeness, patient-match quality, or workflow acceptance.
Exceptions and incidents also need the document version in force. Preserve the condition, reporter, affected route and parties, exchange purpose, data class, time, applicable SOP, notification and cooperation duties, containment, evidence, decision, resolution, and later review. A generic incident status or failed request cannot explain whether an SOP applied, who received notice, or what contractual obligation remained open.
Test a version transition across one live route
A representative evaluation should send the same bounded request before and after an agreement or SOP transition, change one participant's technical implementation on a different date, use two exchange purposes, trigger an authorization exception, and report a security concern. Confirm that each event resolves to the right role chain and document versions, transition rules are explicit, technical validation does not become disclosure authority, receipts stay tied to the correct request, and incident duties reach the intended parties.
The RCE page supports the attributed statements about the Common Agreement's contractual role, technical and governance model, FHIR-based exchange in Version 2, and accompanying SOP topics. It does not establish a particular entity's current contractual status, route availability, standards conformance, identity match, disclosure authority, privacy compliance, data quality, clinical use, incident response, or outcome. This analysis is not a conformance, privacy, security, clinical, or legal determination.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
Health Interoperability Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.