TEFCA and Data Architecture: What Health Systems Need to Build Now

Introduction

The Trusted Exchange Framework and Common Agreement — TEFCA — is no longer a future-state initiative. As of 2024–2025, five Qualified Health Information Networks (QHINs) are live and processing real clinical data exchanges. Health systems and payers that have been watching from the sidelines are now making architectural decisions that will determine whether they participate productively or reactively.

TEFCA's promise is simple: a single, interoperable network for healthcare data exchange that replaces the fragmented state HIE and bilateral exchange agreements that have defined (and limited) health data exchange for the last 20 years. The architectural requirements to participate are specific and non-trivial.

---

The TEFCA Ecosystem

The Five QHINs (as of 2026)

Your organization does not connect directly to TEFCA — you connect to a QHIN, which connects to the TEFCA network. The QHIN handles the network-level routing and identity federation.

---

What TEFCA Participation Requires

1. FHIR R4 Endpoints

TEFCA's Individual Treatment (ITI) exchange uses [FHIR](/terms/FHIR) R4. Your organization must expose FHIR endpoints that support:

• Patient $match: Identity matching for record retrieval across organizations
• Bulk data access ($export): For Treatment, Payment, and Operations (TPO) exchange
• Document Query and Retrieve: For CCD/CDA document exchange (legacy compatibility)

The minimum FHIR capability for TEFCA participation:

{
  "resourceType": "CapabilityStatement",
  "status": "active",
  "kind": "instance",
  "fhirVersion": "4.0.1",
  "rest": [{
    "mode": "server",
    "security": {
      "service": [{"coding": [{"code": "SMART-on-FHIR"}]}]
    },
    "resource": [
      {"type": "Patient", "interaction": [{"code": "read"}, {"code": "search-type"}]},
      {"type": "Encounter", "interaction": [{"code": "read"}, {"code": "search-type"}]},
      {"type": "Condition", "interaction": [{"code": "read"}, {"code": "search-type"}]},
      {"type": "Observation", "interaction": [{"code": "read"}, {"code": "search-type"}]},
      {"type": "DocumentReference", "interaction": [{"code": "read"}, {"code": "search-type"}]}
    ],
    "operation": [
      {"name": "match", "definition": "http://hl7.org/fhir/OperationDefinition/Patient-match"},
      {"name": "export", "definition": "http://hl7.org/fhir/uv/bulkdata/OperationDefinition/export"}
    ]
  }]
}

---

2. Identity Matching ($match)

The $match operation is the most architecturally demanding TEFCA requirement. It enables a provider at another organization to retrieve records for a patient by matching demographic attributes — without a universal patient identifier.

The ONC TEFCA Identity Matching Implementation Guide requires:

• Support for weighted demographic matching (name, DOB, sex, address, phone, SSN last 4)
• Confidence score output with each match result
• Handling of partial matches (score < 100%) separately from definitive matches
• Referential integrity guarantees (you will not return the wrong patient's records)

Your MPI (Master Patient Index) is the foundation of your $match implementation. If your MPI has a >2% false negative rate on patient matching, your TEFCA participation will produce incorrect clinical data exchange — with real patient safety implications.

{
  "resourceType": "Parameters",
  "parameter": [{
    "name": "resource",
    "resource": {
      "resourceType": "Patient",
      "name": [{"family": "Johnson", "given": ["Robert", "D"]}],
      "birthDate": "1965-08-14",
      "gender": "male",
      "address": [{"postalCode": "60614"}]
    }
  }, {
    "name": "onlyCertainMatches",
    "valueBoolean": false
  }, {
    "name": "count",
    "valueInteger": 5
  }]
}

---

3. Consent and Authorization

TEFCA allows data exchange under HIPAA TPO (Treatment, Payment, Operations) purposes without explicit patient consent — the same legal basis as existing HIE exchange. However:

• Individual Access Services (IAS) exchanges — where a patient requests their own data — require proof of identity and explicit authorization.
• Some states have stricter consent requirements than HIPAA (California CMIA, Washington My Health MY Data Act) that supersede TEFCA defaults.

Your architecture needs a consent and authorization layer that can:

• Record the legal basis for each exchange (TPO vs. IAS)
• Enforce state-specific restrictions as override rules
• Log every exchange event for audit purposes

---

4. Audit Logging Requirements

TEFCA requires comprehensive audit logs for every data exchange:

CREATE TABLE governance.tefca_exchange_log (
  exchange_id           VARCHAR(36)   NOT NULL,
  exchange_ts           TIMESTAMP     NOT NULL,
  requesting_qhin       VARCHAR(100)  NOT NULL,
  requesting_org_id     VARCHAR(100),
  requesting_user_id    VARCHAR(100),
  exchange_purpose      VARCHAR(20)   NOT NULL,  -- TREATMENT, PAYMENT, OPERATIONS, IAS
  patient_match_score   DECIMAL(5,4),
  resources_returned    JSONB,                   -- list of resource types and counts
  response_status       VARCHAR(20),             -- SUCCESS, NO_MATCH, PARTIAL, ERROR
  phi_disclosed         BOOLEAN,
  legal_basis           VARCHAR(50),             -- HIPAA_TPO, PATIENT_AUTHORIZATION
  PRIMARY KEY (exchange_id)
);

---

Practical Steps to Prepare

Step 1: Assess your FHIR readiness. Do you have a production FHIR R4 server? Is it US Core-compliant? Can it handle $export for population-scale requests? Most health systems have a FHIR server for CMS interoperability rule compliance — TEFCA builds on that foundation.

Step 2: Evaluate your MPI quality. Run a match quality assessment before TEFCA go-live. False positives (wrong patient linked) in TEFCA exchange are a patient safety issue, not just a data quality issue.

Step 3: Choose your QHIN. Evaluate based on your current EHR vendor relationships, your existing HIE participation, and your primary exchange use case (treatment vs. payment vs. operations).

Step 4: Build the consent and audit infrastructure. Even for TPO-purpose exchange, audit logging is required. Build the exchange log table and pipeline before connecting to a QHIN.

Step 5: Validate your FHIR endpoints against TEFCA conformance requirements. The TEFCA conformance testing framework is available through the ONC test tool. Run it before submitting your QHIN connection application.

---

Key Takeaways

• TEFCA is operational. The window for "we are evaluating participation" is closing — QHINs are live and expected participation timelines are being enforced.
• The $match operation is the highest-risk TEFCA requirement. Your MPI quality determines whether TEFCA produces correct or harmful data exchange.
• Consent and state-level privacy law overrides must be modeled explicitly — HIPAA TPO is the floor, not the ceiling, in high-privacy states.
• Every TEFCA exchange must be audit-logged with purpose, legal basis, and resources disclosed.
• Validate your HL7/FHIR message structure against TEFCA conformance requirements using the HL7 Parser before connecting to a QHIN.