TEFCA entry can run through a QHIN, Participant, or Subparticipant

TEFCA is a hierarchy of participation, not one flat directory

The direct answer in the Recognized Coordinating Entity's participation overview is that TEFCA follows a network-of-networks structure. A health information network can seek designation as a Qualified Health Information Network, while other organizations and individuals can use TEFCA exchange through a QHIN, Participant, or Subparticipant. That architecture allows multiple entry points without making every connected organization the same type of actor.

A maintained directory should therefore identify the legal entity, participation role, upstream relationship, effective and termination dates, covered services, endpoints, identifiers, and authoritative source. A badge that says TEFCA connected can obscure whether the organization is a QHIN, direct Participant, downstream Subparticipant, software customer, or individual user—and which contractual and technical relationship actually carries the exchange.

Participant status is anchored in a QHIN contract

The RCE says Participants may include persons or entities that entered into a contract to participate in a QHIN. Examples include a health information network, health system, health IT developer, payer, or federal agency. The label describes a relationship within the TEFCA framework; organization type alone does not establish it. The same type of entity may enter through a different layer in another network structure.

Implementation records should connect the Participant, QHIN, contract or flow-down terms, onboarding status, exchange purposes, service scope, identity and security configuration, production date, and any suspension or termination. Marketing language and directory discovery can help orient a review, but current participation and authority should be reconciled to the governing relationship and designated-QHIN information before operational decisions rely on it.

Subparticipants inherit a path through a Participant

The RCE describes Subparticipants as persons or entities that use a Participant's services to send and receive electronic health information. It gives the example of a QHIN composed of health information exchanges: the exchange can be the Participant and its users can be Subparticipants. It also describes a health IT developer as a direct Participant whose provider-practice customers may sit downstream.

That makes the chain a material part of troubleshooting and governance. A message failure, policy question, identity issue, directory error, or termination can involve the Subparticipant, Participant, QHIN, or more than one layer. Systems should preserve the path used for each exchange and the responsible support and escalation contacts instead of assuming that the application endpoint is also the contractual counterparty or network authority.

Individual Users remain a distinct role

The participation overview says an Individual User is the actual person who is the subject of the electronic health information, such as a patient, member, or representative. The individual may have a direct relationship with a QHIN, Participant, or Subparticipant depending on the network structure, but is not considered a Participant or Subparticipant. That distinction matters for identity, authorization, access, notices, and support.

The operational record should identify the user relationship and the organization performing each function without converting an individual-access event into organizational participation. TEFCA role, exchange purpose, applicable law, Common Agreement obligations, technical framework, security, consent or authorization where relevant, and local policy remain separate questions. This article reports the RCE's public hierarchy; it does not establish live connectivity, permitted exchange, or legal authority for a specific request.

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.