Federal policy efforts to advance health data exchange and interoperability through the Trusted Exchange Framework and Common Agreement (TEFCA) have advanced rapidly in the past several months. Since TEFCA became operational in December 2023, the seven designated Qualified Health Information Networks (QHINs) have been facilitating data exchange under the TEFCA framework. The Sequoia Project, Inc., the TEFCA Recognized Coordinating Entity (RCE) or the organization responsible for providing oversight and the governing approach for QHINs, released over the past several months (on July 1, August 6, and November 13, 2024) its latest batch of Standard Operating Procedures (SOPs), which are written procedures or other provisions that are adopted pursuant to the Common Agreement. In the below summary, we outline a number of TEFCA-related policy developments and highlight considerations from the SOPs that are important to health information networks (HINs)/health information exchanges (HIEs) and other entities keeping apprised of interoperability policy developments.
Background
The Assistant Secretary for Technology Policy and Office of the National Coordinator for Health Information Technology (ASTP/ONC) has led a multi-year, public-private process in collaboration with The Sequoia Project to implement TEFCA, which was required by Congress in the 21st Century Cures Act (Cures Act) to make data sharing more efficient, secure, and move the healthcare industry toward greater interoperability. The Trusted Exchange Framework outlines a set of non-binding but foundational principles for health information exchange that QHINs may use to share health data with other QHINs, individuals, and entities. TEFCA has 3 goals: (1) to establish a universal governance, policy, and technical floor for nationwide interoperability; (2) to simplify connectivity for organizations to securely exchange information to improve patient care, enhance the welfare of populations, and generate healthcare value; and (3) to enable individuals to gather their health care information.
Upon initial operation, TEFCA designated the first five QHINs—eHealth Exchange, Epic Nexus, Health Gorilla, KONZA, and MedAllies. In February 2024, ONC announced two additional QHINs: CommonWell Health Alliance and Kno2. Additional HINs are currently in the process of becoming designated as QHINs. As pillars of TEFCA Exchange, QHINs provide shared services and governance to securely route queries, responses, and messages across networks for healthcare stakeholders.
On April 22, 2024, ASTP/ONC and The Sequoia Project released Common Agreement Version 2.0 (CA v2.0), a legal agreement that establishes the technical infrastructure model and governing approach allowing different QHINs and their users (i.e., Participants and Subparticipants) to exchange health information as part of TEFCA. CA v2.0 defines baseline legal and technical requirements for secure information sharing, including outlining the TEFCA governing approach and QHIN onboarding process; identifying permitted TEFCA Exchange purposes and activities; and establishing privacy and security requirements in line with the Health Insurance Portability and Accountability Act (HIPAA) regulations.
CA v2.0 includes a number of changes from previous versions, including allowing participants to participate in TEFCA with multiple QHINs. It also requires support for Health Level Seven (HL7) Fast Healthcare Interoperability Resources (FHIR®) application programming interface (API) exchange through an updated QHIN Technical Framework (QTF) Version 2.0. In addition, CA v2.0 updates and removes certain defined terms. For example, the definition of “Treatment” with respect to permitted exchange purposes was deleted, and instead defined and addressed in the Exchange Purposes SOP.
Standard Operating Procedures (SOPs)
The Sequoia Project has also released SOPs, which contain technical requirements and recommendations governing TEFCA Exchange. These SOPs are important to understand as they are required for QHINs and TEFCA participants, but also because they may drive policies for health information exchange outside of TEFCA (as demonstrated by TEFCA’s approach to the definition of treatment). Below we summarize and provide highlights of several recent TEFCA SOPs.
- The Exchange Purposes (XP) SOP (see here) defines the authorized XPs and identifies any XPs requiring a Response pursuant to the Framework Agreements, as well as when fees are prohibited or permitted. As outlined in CA v2.0, QHINs, Participants, and Subparticipants can utilize TEFCA Exchange only for Exchange Purposes (XPs). There are currently six types of authorized Exchange Purposes (XPs): Treatment; Payment; Health Care Operations (including Health Care Operations SubXP-1); Public Health (including Public Health SubXP-1); Government Benefits Determination; and Individual Access Services. Notably, The Sequoia Project requires responses for TEFCA Required Treatment and Individual Access Services. For both of these XPs, fees are not permitted. Additionally, the XP SOP explains that a Level 1 XP Code identifies an authorized XP, while a Level 2 XP Code identifies a specific use case within an authorized XP and may reference specific technical requirements.
- The Treatment XP Implementation SOP (see here) identifies implementation specifications that QHINs, Participants, and Subparticipants must follow when asserting the Treatment Exchange Purpose, including the Level 2 XP Code, TEFCA Required Treatment. The Treatment SOP separates the XP into two distinct levels and narrowed the term significantly: while Level 1 “Treatment” simply holds the meaning assigned to it under 45 CFR § 164.501; Level 2 “TEFCA Required Treatment” applies only to entities that “electronically transmit any health information” for which HHS “has adopted standards in the normal course of business” and are one of the enumerated types of providers including delegates of those providers. This excludes healthcare providers not subject to HIPAA and certain types of entities that are “health care providers” that are subject to HIPAA but are not in the enumerated list.
- The Health Care Operations XP Implementation SOP (see here) identifies implementation specifications QHINs, Participants, and Subparticipants must follow when asserting the Health Care Operations (HCO) Exchange Purpose, including Level 2 use cases of Care Coordination/Case Management, Quality Reporting, and Healthcare Effectiveness Data and Information Set (HEDIS) Reporting. Health Care Operations means TEFCA Exchange for the purposes of determining how to deliver care for a particular patient by performing one or more actions in order to organize the provision and case management of an Individual’s health care. The initial requirements in this SOP specify that responding nodes should respond to queries for each of the HCO Level 1 and Level 2 XP Codes. However, eighteen months following the initial publication date of this SOP, responding nodes must respond to queries for all HCO Level 2 XP Codes specified in this SOP. The SOP states that this transition period supports TEFCA’s goal of bolstering exchange for all XPs in an iterative and predictable way that encourages broad participation, trust, and reciprocity.
- The Individual Access Services (IAS) XP Implementation SOP (see here) outlines specific requirements that IAS Providers are required to follow for Individual identity verification when sending an IAS Query and also identifies when a QHIN, Participant, or Subparticipant is required to Respond to an IAS Query. All TEFCA Exchange under IAS must use the XP Code Level 1 T-IAS. The SOP extends requirements beyond the Credential Service Provider (CSP) approval organization; the CSP itself must now provide a signed OpenID Connect token to the IAS Provider after verifying an individual’s identity on behalf of that provider; this may be used to validate an identity token issued by that CSP. The updated IAS SOP also expands its identity verification procedure.
- The Public Health XP Implementation SOP (see here) identifies requirements and technical specifications that QHINs, Participants, and Subparticipants are required to follow when asserting the Level 1 Public Health XP. Level 1 exchange may include the sharing of information between public health authorities (PHAs) and reporting of information from a PHA to the Centers for Disease Control and Prevention (CDC). Level 2 public health use cases include Electronic Case Reporting and Electronic Laboratory Reporting, which allow PHAs to identify disease trends, track and monitor outbreaks, and prevent and control future outbreaks.
- The Governance Approach SOP (see here) sets forth the formation, composition, responsibilities and duration of the Transitional Council and the Governing Council, which responsible for serving as a resource to the RCE and governing body for activities conducted under the Framework Agreements.
- The Delegation of Authority SOP (see here) identifies specific requirements that QHINs, Participants, and Subparticipants are required to follow when authorizing a Delegate to initiate Delegated Requests. CA v2.0 established the Principle-Delegate relationship, which allows for a TEFCA Exchange Request initiated by a Delegate working, directly or indirectly, for a Principal (e.g., designated QHIN).
- The Facilitated FHIR Implementation SOP (see here) identifies specific requirements for Facilitated FHIR implementation activities. Any FHIR Adopter may participate in any of the FHIR activities specified in this SOP. The stated goal is to encourage consistent adoption of a scalable, network approach to Facilitated FHIR across TEFCA.
- The TEFCA Security Incident Reporting SOP (see here) details minimum reporting requirements for communicating TEFCA Security Incidents to the RCE, to other potentially impacted QHINs, and to any potentially impacted Participant and/or Subparticipant within the QHIN’s network, as set forth in the Common Agreement and Terms of Participation. This SOP states that this reporting will help enable the RCE to assess the overall security risks facing TEFCA Exchange and empower QHINs to take timely action to mitigate risks such as those from a compromised system of another QHIN, Participant, or Subparticipant.
- The QHIN Security for the Protection of TEFCA Information SOP (see here) identifies specific requirements that QHINs must follow to protect the security of TEFCA Information. It also provides specific information about the Cybersecurity Council.
- The XP Vetting Process SOP (see here) establishes a framework for evaluating and approving Entrants (e.g., providers and other covered entities) before their inclusion in the RCE Directory Service to assert a specific XP. The RCE Directory Service is a technical service provided by the RCE that enables QHINs to identify their Nodes to enable TEFCA Exchange.
Takeaways
According to a RCE monthly informational call, additional candidates are undergoing QHIN onboarding and designation process. The Sequoia Project stated that it will continue to roll out additional SOPs to identify technical specifications supporting TEFCA Exchange.
The Biden Administration and current ASTP/ONC leadership have been razor-focused on developing policies and implementing TEFCA. With the change in Administration, we do not expect that this work will be completely overhauled, but it remains to be seen whether the next Administration will prioritize TEFCA and other interoperability initiatives in the same manner.
Healthcare entities and other stakeholders should continue to follow policy developments because these changes, such as new and updated versions of the SOPs, may have a considerable impact on the federal policies governing health information exchange. For more information on the TEFCA SOPs and other interoperability issues, please contact the professionals listed below, or your regular Crowell contact.