TEFCA Go-Live: Everything You Need to Know as ONC Prepares for a New Era of Health Information Exchange

On January 18th, the Office of the National Coordinator for Health Information Technology (ONC) and the Recognized Coordinating Entity, the Sequoia Project (“RCE”), pushed TEFCA forward in a major way with the release of the initial Common Agreement, QHIN Technical Framework (QTF), a subset of the initial Standard Operating Procedures, and a three-year roadmap for incorporating FHIR into TEFCA.

After many years of work, ONC and the RCE have set the stage for TEFCA (“Trusted Exchange Framework and Common Agreement”) to fully go live in Q3 or Q4 of 2022. It is important to note, for clarification, that this go-live TEFCA release announcement made by ONC relates to version 1 of all the key TEFCA documents. Essentially, version 1 of the Common Agreement and QTF set the stage for participation in TEFCA, providing interested parties with a fuller understanding of the requirements. There are still a number of steps that need to happen before TEFCA will actually be live and data exchange start over the network. For instance, the RCE will have to open applications for QHINs, review the applications and designate QHINs, and then conduct onboarding testing. There are also additional Standard Operating Procedures (SOPs) that need to be finalized by the RCE before further steps go live.

In this blog, we provide helpful resources and a summary of key points of the Common Agreement, QHIN Technical Framework, and FHIR Roadmap.

Timely TEFCA Resources

• Full set of documents
• ONC blog post
• RCE summary deck
• Upcoming RCE webinars

Quick High Points of the Common Agreement:

• Purpose: The Common Agreement defines the baseline legal and technical requirements for secure information sharing on a nationwide scale.
• Timeline: QHIN applications will begin in Q2 with the network actually launching in Q3 or Q4 of 2022.
• Initial Responses only Required for Treatment and Patient Access: Responses are only required for Treatment and Patient Access, a significant change back from the previous version that required responses for full TPO, public health, patient access and benefits determination. It is the intent to make other Exchange Purposes required once the RCE has developed implementation guides. This was likely done in response to significant stakeholder push back and concerns that providers would state they could not respond due to an inability to support the HIPAA Minimum Necessary standard for Health Care Operations and Payment purposes.
• Permitted Uses of Data: Once data has been received over TEFCA for an Exchange Purposes, the recipient generally can reuse or redisclose the information in any manner not prohibited by Applicable Law and that is consistent with their Privacy and Security Notice.
• Fees: The Common Agreement prohibits QHINs charging one another fees with respect to exchange under the Common Agreement. QHINs are allowed to charge fees to their Participants.
• QHIN Eligibility: Generally the high bar remains high to become a QHIN and messaging continues to be focused on their being a limited set of QHINs.

A More Detailed Summary of the Common Agreement:

The Common Agreement defines the baseline legal and technical requirements for secure information sharing on a nationwide scale. Today the Sequoia Project, ONC’s RCE, released version 1 of the Common Agreement, which will govern the initial launch of TEFCA, the QTF, which outlines the technical requirements for exchange, and a variety of Standard Operating Procedures. In addition, the RCE released a roadmap for how FHIR will be incorporated into the Common Agreement in the next three years.

The RCE included the following timeline for operationalizing the network created by the Common Agreement. QHIN applications will begin in Q2 with the network actually launching in Q3 or Q4 of 2022:

Remember that the Common Agreement is signed by the RCE and each QHIN. Similar to the DURSA only QHINs (or participants in DURSA speak) sign the agreement, however QHINs have obligations to flow certain provisions down to their Participants and Participants to their Subparticipants etc. The required flow-down provisions address cooperation and nondiscrimination; confidentiality; utilization of the RCE Directory Service; Uses, Disclosures, and responses; Individual Access Services; privacy; security; special legal requirements, TEFCA information outside the U.S., and other general obligations.

Key Points:

• Exchange Purposes with Required Responses Narrowed:
  Exchange Purposes or the purposes for which data can be shared over the TEFCA network are as follows below. Initially responses are only required for Treatment and Individual Access Services. The other Exchange Purposes will require responses in the future once implementation guides have been released. The finalized Government Benefit Determination is narrowed from the prior draft as now only government entities can use this exchange purpose (i.e., life insurance companies are now excluded). Exchange Purposes can be added via an SOP in the future.
  • Treatment (response required);
  • Payment;
  • Health Care Operations;
  • Public Health;
  • Government Benefits Determination; and
  • Individual Access Services(response required)
• Responding to Requests: Initially responses are only required for Treatment and Individual Access Services, others will be phased in overtime. Specific exceptions, when an entity would not have to respond to a request for information that are called out in the Common Agreement include but are not limited to:
  • If the entity is a public health authority
  • If Signatory is a federal agency, to the extent that the requested Disclosure of Required Information is not permitted under Applicable Law (e.g., it is Controlled Unclassified Information as defined at 32 CFR Part 2002 and the party requesting it does not comply with the applicable policies and controls that the federal agency adopted to satisfy its requirements).
  • If the Exchange Purpose is authorized but not required
• Permitted Uses of Data: Once data has been received over TEFCA for an Exchange Purposes, the recipient generally can reuse or redisclose the information in any manner not prohibited by Applicable Law and that is consistent with their Privacy and Security Notice.
• TEFCA Information: Information exchanged under the Common Agreement for one or more Exchange Purposes is called TEFCA Information. TEFCA Information includes both ePHI and non-ePHI (i.e., non-HIPAA covered data is still considered TEFCA Information and thus has the requisite protections outlined in the Common Agreement).
• Governance: The Common Agreement will create a Transitional Council (made up of the initial QHINs) as an interim body for a 12-month period, followed by the permanent Governing Council. In addition, a QHIN Caucus and Participant/Subparticipant Caucus will be established, which will elect members to the Governing Council. Advisory Groups could also be established, as needed, to seek feedback from distinct groups of stakeholders. Among other activities, these deliberative bodies will be engaged in reviewing proposed amendments to the Common Agreement, the QTF, and the SOPs in accordance with the Common Agreement’s specified change management process. ONC approval is required for amendments to the Common Agreement, the SOPs, and the QTF. The governing approach will also provide oversight for resolution of disputes, following the dispute resolution process that will be part of the Common Agreement.
• QHIN Eligibility: The following QHIN eligibility criteria are outlined with further detail coming in in the Onboarding& Designation SOP:
  • Must meet the definition of a U.S. Entity
  • Be able to exchange Required Information, as defined in the Common Agreement
  • Signatory must demonstrate that it has the ability to perform all of the required functions of a QHIN in the manner required by the Common Agreement, the SOPs, the QTF, and all other applicable guidance from the RCE
    • Signatory can demonstrate this by having been in operation and supporting the query functionality as outlined in the QTF, or other functionally comparable exchange method, for at least the twelve (12) calendar months immediately preceding its application to be Designated as a QHIN. However, the RCE will consider other evidence that Signatory may offer to demonstrate compliance with this eligibility criterion as more fully set forth in the applicable SOP.
  • Signatory must demonstrate that it has in place, at the time of its application to be Designated as a QHIN, the organizational infrastructure and legal authority to comply with the obligations of the Common Agreement and a functioning system to govern its health information network. In addition, Signatory must demonstrate it has the resources and infrastructure to support a reliable and trusted network.
• Privacy and Security Requirements:
  • General Requirements: QHINs would be expected to meet and maintain third-party certification to an industry recognized cybersecurity framework and undergo annual security assessments. QHINs also must obtain and maintain cybersecurity insurance coverage (a policy or the ability to self-insure through internal financial resources). QHINs must have a CISO.
  • Non-HIPAA Entities that participate in the Common Agreement will be required to protect TEFCA Information that is individually identifiable in substantially the same manner as HIPAA Covered Entities protect PHI, including having to comply with the HIPAA Security Rule and most provisions of the HIPAA Privacy Rule.
  • Consent: If federal or state law requires that an Individual’s consent be obtained before a health care provider Discloses an Individual’s identifiable information for Treatment, then the Common Agreement does not change that requirement. Such a provider would obtain consent from an Individual before disclosing that Individual’s information to others under the Common Agreement. Furthermore, given the state law, the provider would not be required to respond to TEFCA Information requests if that provider has not obtained the proper consent.
  • Individual Access Services Providers: Are QHINs, Participants, and Subparticipants that offer Individual Access Services to patients. As it is anticipated these IAS Providers may be non-HIPAA Entities additional requirements are put on them to ensure they meet the HIPAA bar (e.g., providing a written privacy and security notice similar to a HIPAA Notice of Privacy Practices) and at times go beyond it. For instance, IAS Providers must get patient consent to access and share their data and provide patients the ability to export and delete their data.
• Fees: The Common Agreement prohibits QHINs charging one another fees with respect to exchange under the Common Agreement. QHINs are allowed to charge fees to their Participants.
• RCE Directory: Similar to Carequality, the RCE will operate a directory that includes relevant end points on the network. Participants and Subparticipants can only be listed in the directory once (i.e., duplicate entries for an organization are prohibited).
• Standard Operating Procedures: Similar to OPPs in eHealth Exchange the RCE has released SOPs on the following topics (with more to come):
  • Advisory Groups
  • Conflicts of Interest
  • Dispute Resolution Process
  • Governing Council QHIN Security of TEFCA Information
  • QHIN Cybersecurity Insurance
  • Transitional Council
• Cooperation and Non-Discrimination:
  • QHINs, Participants, and Subparticipants agree to abide by a number of obligations to support the operation of the network (e.g., work collaboratively with the RCE to address differing interpretations of the Common Agreement, QTF or SOPs).
  • QHINs, Participants, and Subparticipants must allow their member to participate in other QHINs, Participants, or Subparticipants.
  • QHINs, Participants, and Subparticipants not impede the exchange of information as permitted or required under TEFCA limit interoperability with any other QHIN, Participant, Subparticipant, or Individual in a discriminatory manner
    

QHIN Technical Framework

The QHIN Technical Framework (QTF) outlines the functional and technical requirements for exchange between Qualified Health Information Networks (QHINs). QHINs are similar to Implementers in the Carequality framework, acting as the top-level entities that provide connectivity services that allow their members to exchange with members of other QHINs. The technical and functional requirements described in the QTF enable two information exchange modalities for QHINs: QHIN Query (query) and QHIN Message Delivery (push). The QTF generally leverages the IHE standards that are used by existing national networks.

Key Points/Changes:

• QHIN Message Delivery was Adopted: This push-based exchange method was finalized as a requirement using XCDR and all QHINs will have to support this capability.
• Functional Record Location and Patient Matching Standards: QHINs must meet a yet to be specified SLA for record location and patient matching. The QTF does not dictate a particular methodology that must be used. For instance, for record location QHINs may use a RLS or decentralized methods such as fanning out queries to all Participants.
• Other Items of Note:
• C-CDA 2.1 is still the foundation: C-CDA 2.1 is still the preferred/expected document format for exchange over TEFCA however they have softened the language. QHINs may use other format where required by Applicable Law (e.g., public health reporting) or if requested by the initiating QHIN.
• Starting January 1, 2023, for C-CDA 2.1 documents QHINs must include all appropriate data classes and elements from the USCDI v1. The RCE can require the use of newer versions of the USCDI in the future.

• Removed Certain QHIN Requirements:
• QHINs do not have to support creating a single combined C-CDA when multiple C-CDAs are returned.
• QHINs are not required to support converting other document types into the C-CDA 2.1 format.
• Additional Detail: QTF Version 1 added additional technical details that QHINs will be required to abide by.
• Use of Project US@ Specification Required: The initiating QHIN must convert data in the address field used in Patient Discovery Queries to conform to the Project US@ Technical Specifications prior to transmitting a response to any responding QHINs.

FHIR Roadmap

The FHIR Roadmap outlines a three-year plan to incorporate FHIR-based exchange into TEFCA. This timeline aligns with broader HHS regulatory pushes to mandate the use of FHIR by payers and providers. The roadmap envisions two paths for supporting FHIR-based exchange in TEFCA:

1. Facilitated FHIR Exchange: QHINs provide network infrastructure support to facilitate unbrokered FHIR API-based exchange between Participants and Subparticipants from different QHINs
2. Brokered FHIR Exchange: QHINs broker FHIR payloads by routing FHIR APIs transactions between Participants and Subparticipants from different QHINs

In 2022, as the first step, the RCE will convene work groups to initiate development of the use of FHIR for data exchange under the Common Agreement for both brokered and facilitated FHIR exchange. The goal is to include FHIR as an optional, additional standard in the QTF in calendar year 2023 for those ready to use it, and to gradually make it a required, additional capability during calendar year 2024.