TEFCA: Update for 2022

Originally part of the 21st Century Cures Act of 2016, TEFCA (the “Trusted Exchange Framework and Common Agreement”) has been with us for quite a few years now. The first set of Draft Specifications was released in 2018, followed by a second set in 2019, and then later that year, ONC announced that The Sequoia Project would serve as the Recognized Coordinating Entity (RCE).

Since then, the RCE has been working to advance the Common Agreement–essentially the “rules of the road” under which TEFCA will operate, with current ONC timelines projecting TEFCA to be live in 2022.

In this blog post, we’ll look at the progress that’s been made to date by the RCE, peek at some of the key provisions of the proposed Technical Framework, and offer some thoughts on some of the outstanding challenges facing TEFCA.

TEFCA: Key Concepts

TEFCA Information (TI)

The Common Agreement establishes some new definitions, key among them being TI (or TEFCA Information). TI is defined as “any information that is exchanged between QHINs for one or more of the Exchange Purposes pursuant to any of the Framework Agreements”.

Note that TI is not synonymous with EHI, PHI, ePHI, USCDI nor any of the other current acronyms associated with Information Blocking or HIPAA. This is because there will likely be additional types of information exchanged besides healthcare information as part of TEFCA in order to support some of the proposed exchange purposes.

Exchange Purposes

Exchange purposes are defined as “the reasons for which information could be requested and shared through QHIN-to-QHIN exchange”. Currently there are six defined exchange purposes, yet the door is open for the addition of future exchange purposed by modifying the Common Agreement.

1) Treatment
2) Payment
3) Health Care Operations
4) Public Health
5) Benefits Determination
6) Individual Access Services

Also, any other purpose authorized as an Exchange Purpose by the Standard Operating Procedure (SOP) adopted as part of the Common Agreement may be considered in the future.

Treatment, Payment, and Health Care Operations would have the same definitions as they do under the HIPAA Privacy Rule, although these definitions would apply to all TEFCA Information, regardless of whether or not the exchange parties are HIPAA Covered Entities or Business Associates.

Public Health exchange would include requests for information by Public Health Authorities (so long as they are consistent HIPAA and any other applicable laws).

Benefits Determination supports governmental agencies that need information to determine whether a person qualifies for non-health government benefits (again consistent HIPAA and any other applicable laws).

This includes determinations by any federal, state, local, or tribal agency, instrumentality, or other unit of government as to whether an individual qualifies for government benefits for any purpose other than health care (for example, Social Security disability benefits).

Note that currently there is no defined list of applicable benefits, nor a definition of what types of non-health information might be necessary.

Individual Access Services (IAS) supports assisting individuals in obtaining access to their health information, particularly in support of consumer-facing applications or platforms.

Interestingly it should be noted that a QHIN, Participant, or Subparticipant would be allowed but not required to offer Individual Access Services to individuals with whom they have a Direct Relationship. Note that IAS providers have additional obligations under the Common Agreement as well (e.g. see security and consent sections below).

Challenges Facing TEFCA

Privacy & Security

In general, QHINs (Qualified Health Information Networks) and other connected entities would be required to protect individually identifiable TEFCA Information 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 and Rule) even if they are not HIPAA Covered Entities or Business Associates.

This includes Breach notification requirements pursuant to the HIPAA Breach Notification Rule at 45 CFR u00a7164.400-414 for QHINs, Participants, and Participant Members.

QHINs will also have to conduct annual security assessments, and will be expected to achieve certification from an industry recognized third-party cybersecurity framework. QHINs will also be required to maintain current cyber-liability coverage meeting the requirements of the Common Agreement, or sufficient funds to self-insure up to the amount specified in the SOP.

For IAS Providers:

IAS Providers would need to implement security requirements, including encryption and certain security incident notifications.

These security requirements may pose challenges for some connected entities that find themselves subject to HIPAA PHI protection and Breach notification requirements.

Consent

In general, patient consent is not required for TEFCA participants. The Common Agreement would not require QHINs, Participants, and Subparticipants to obtain Individual consent to use or disclose TI except to the extent they would be required to do so under applicable law, or if they that were IAS Providers.

For IAS Providers:

Patient consent would be required for items such as how an individual’s information may be accessed, exchanged, used, and/or disclosed, including whether that information may be sold.

Additionally, individuals would have the right to have all of their individually identifiable information maintained by an individual Access Service Provider deleted, as well as have the right to obtain an export of their data in a computable format.

Finally, if consents are required under municipal, state, or other regulatory laws (such as HIPAA), then these obligations would remain in effect under TEFCA, meaning that in such cases, providers would need to obtain consent prior to disclosing an individual’s information.

Obtaining proper consent may pose challenges (e.g. would this be the responsibility of the requestor or the responder or both?) Also, participants may find it difficult to navigate the myriad of local, state, and federal laws that may come into play (e.g. when information is shared among states with different–and perhaps incompatible–privacy laws).

Technical Challenges

The QHIN Technical Framework (QTF) specifies a number of technical requirements, many of which may have outstanding challenges that will need to be resolved as TEFCA moves forward:

Exchange Purposes

While the initial six Exchange Purposes are defined by the Common Agreement, they remain somewhat vague (e.g. lack of a defined list of benefits when considering the Benefits Determination purpose). Similarly, implementation guides to support specific use cases are not yet available, making it challenging for developers to support QHIN requirements.

Additionally segmentation of sensitive data remains problematic, along with consistent definitions for TEFCA Information (TI), and what types of non-health information might be included for exchange. It would be helpful if all definitions (e.g. TI, EHI, PHI, ePHI, etc.) associated with various regulatory rules could be aligned among the various programs (e.g. TEFCA, MIPS/MACRA, Information Blocking, etc.)

Lastly, given the scale of supporting all six Exchange Purposes, the proposed Technical Framework could likely require QHINs to significantly expand their technical architecture in order to build and/or augment a centralized gateway infrastructure to facilitate cross-network exchange. This overhead may prove costly and a barrier to entry for many potential QHIN candidates.

RCE Directory Service

The Common Agreement specifies that each QHIN must maintain its own up-to-date copy of the RCE Directory (potentially a Record Locator Service (RLS) or Enterprise Master Patient Index (eMPI) or other methodology), yet it remains unclear what specific information will be contained in the RCE directory or how will it be kept current.

Also not yet determined is whether RCE Directory Services will be available outside of TEFCA (i.e. to non-QHINs, Participants and Subparticipants) and whether there will be fees levied for use of these services.

Patient Identity Resolution

The issues of Identity Proofing / User Authentication (verifying a person is who they claim to be) and Patient Matching (appropriately matching patients to medical records) remain significant technical hurdles for prospective QHINs.

Meaningful Choice

The Common Agreement specifies that Individuals must have the option (free of charge) to exercise “Meaningful Choice”, requesting that their EHI not be used or disclosed via the Common Agreement, except as permitted by Applicable Law. Note that this only applies on a prospective basis, which means that there will be no way to rescind PHI that has already been shared.

Additionally with respect to Individual Access Services (IAS), participating individuals have the right to obtain an electronic copy of their data, as well as to have their data deleted.

Sustainability

The subject of sustainability for QHINs and how fees may be structured (e.g. transaction-based fees) and charged remain a debated topic. While QHINs will not be allowed to charge fees to other QHINs, they would be permitted to charge fees to Participants, and concerns exist that such fees may be higher than desired in order to support the technical needs of the QHINs (e.g. server hardware to support directory services, information storage, etc.) with most feeling that fees should not be perceived as a barrier to participation, especially for participant with limited resources.

Additionally, discussion surrounding the appropriateness of whether QHINs can sell data (even if de-identified) in order to maintain viability has been controversial, and will need further deliberation.

Given the historical challenges associated with HIE sustainability, sustainability may be the most critical issue for the RCE and TEFCA to resolve.

Helpful Links

TEFCA: https://www.healthit.gov/topic/interoperability/trusted-exchange-framework-and-common-agreement

QTF Draft 1: http://www.healthit.gov/sites/default/files/draft-trusted-exchange-framework.pdf
QTF Draft 2: https://www.healthit.gov/sites/default/files/page/2019-04/FINALTEFCAQTF41719508version.pdf

Sequoia Project (RCE): RCE.sequoiaproject.org (Email: rce@sequoiaproject.org)

For more on TEFCA see these Impact Advisors blog posts:

TEFCA in a Nutshell
TEFCA in a Nutshell – Part 2