TEFCA and information blocking

TEFCA - the Trusted Exchange Framework and Common Agreement - is the US nationwide health information exchange framework, administered by The Sequoia Project on behalf of ASTP/ONC. Organizations do not connect to TEFCA directly - they connect through a QHIN, a Qualified Health Information Network, and the QHINs exchange with each other.

The designated QHINs as of 2026 include eHealth Exchange, Epic Nexus, CommonWell, Health Gorilla, MedAllies, KONZA, Surescripts, eClinicalWorks and Oracle Health.

QHINs are moving toward FHIR-based exchange under the FHIR R4 API standards referenced at 45 CFR 170.215, alongside the document-based exchange that networks started with. For an integration team this means the FHIR-facing capabilities below are what TEFCA readiness looks like in practice.

The information blocking rule, from the 21st Century Cures Act, prohibits practices likely to interfere with the access, exchange or use of electronic health information, unless an exception applies.

For health IT developers of certified health IT, health information networks and health information exchanges, the HHS-OIG final rule - finalized July 3, 2023, effective September 1, 2023, codified at 42 CFR Part 1003 Subpart N - authorizes civil monetary penalties of up to $1 million per violation.

For providers, the HHS final rule of June 24, 2024, effective July 31, 2024, imposes disincentives instead - for example, a hospital that loses "meaningful EHR user" status under the Medicare Promoting Interoperability Program faces a 75% reduction of its market basket increase. The rule text is published in the eCFR at 45 CFR Part 171, and the HTI-2 rulemaking finalized the TEFCA Manner Exception in December 2024.

Whatever the network topology above you, the technical requirements on the integration layer reduce to a short list:

The outbound side is an outgoing FHIR connection, the inbound side is a REST channel whose service returns a FHIR-shaped response assembled from your systems. Zato is the client and integration layer in front of your systems here - it is not a QHIN and not a FHIR server.

# -*- coding: utf-8 -*-

# Zato
from zato.server.service import Service

class ReturnPatientData(Service):
    """ Exposed through a REST channel, answers FHIR-shaped queries.
    """
    name = 'demo.tefca.return-patient-data'

    def handle(self) -> 'None':

        # The identifier the caller is asking about
        mrn = self.request.payload['identifier']

        # Read the data from the FHIR store behind us ..
        client = self.fhir['FHIR.Internal']

        patient = client.resources('Patient').search(
            identifier = f'urn:mrn|{mrn}',
        ).first()

        # .. audit what was asked and what is returned ..
        self.logger.info('Query for %s, returning %s', mrn, patient['id'])

        # .. and answer with a FHIR-shaped payload.
        self.response.payload = patient.serialize()

Not every refusal to share is information blocking - the rule defines exceptions, and two groups matter most for engineers. The first covers not fulfilling a request - privacy, security, preventing harm, infeasibility. The second covers how a request is fulfilled - the Manner Exception and, since HTI-2, the TEFCA Manner Exception, which lets participants satisfy requests via TEFCA exchange when both sides are part of it.

The engineering consequence is that "our interface cannot do that" is not a defensible answer - the integration layer must make fulfilling requests technically routine, so that any refusal is a documented policy decision under an exception, not a technical limitation.