Back to Home

Understanding the Trusted Exchange Framework and Common Agreement (TEFCA)

Written by Charlie Harp

January 14, 2020 at 10:33 AM

In January of 2018, ONC released its first draft of the Trusted Exchange Framework and Common Agreement (TEFCA), and in April of 2019, ONC released the second draft. After reviewing the second draft, I thought it might be useful to provide my perspective on what TEFCA is, what it addresses with regard to healthcare interoperability and what it does not.

 

TEFCA is intended to provide a common set of rules and operating procedures with the intent of reducing the burden involved in sharing patient data while improving the quality and consistency of the information being shared. It is comprised of three constituent documents:

  1. The Trusted Exchange Framework (TEF) document – which describes the guiding principles and terms to support the TEFCA initiative.
  2. The Minimum Required Terms and Conditions (MRTCs) document – which describes the terms and conditions that are mandatory for a Health Information Network (HIN) to function as a Qualified Health Information Network (QHIN) .
  3. The QHIN Technical Framework document – which details the technical and functional rules for information sharing between QHINs.

When trying to understand TEFCA, the best place to start is to understand its guiding principles and each entity and the roles they play in the cooperative agreement.

 

Guiding Principles

There are six common principles that are core to the Trusted Exchange Framework (TEF).

  • Principle 1 – Standardization
  • Principle 2 – Transparency
  • Principle 3 – Cooperation and Non-Discrimination
  • Principle 4 – Privacy, Security, and Safety
  • Principle 5 – Access
  • Principle 6 – Population-Level Data

 

These concepts provide insight into the goals and objectives of TEFCA. I believe these principles are in alignment with what most people with experience in Healthcare IT believe are necessary to improve care coordination across care venues and potentially accelerate knowledge discovery through population-level analytics.

 

Let’s walk through the entities that play a role in the proposed agreement architecture.

 

Patient

In the TEFCA documentation, the patient as an entity receiving care is not a defined entity (Individual Users accessing their data on a phone app notwithstanding). I would assume that this is because in this model, a patient, as a manifestation of data, is a given. They are mentioned here for completeness even though their involvement in TEFCA is mostly passive.

 

Individual User

An Individual User is a person who has legitimate access to healthcare information from any qualified TEFCA entity. This means that anyone, provider, or patient, that has the right to request or provide healthcare information through TEFCA is an Individual User. The main requirement for an Individual User is that they have appropriate credentials that were issued using defined minimum authentication protocols.

 

Participants and Participant Members

A Participant is essentially an entity that can request or provide healthcare information. This could range from a health system EHR or a cloud-based healthcare platform to a consumer mobile device application. In order to be a Participant, this entity must have entered into an agreement to participate with a QHIN, as that is the only mechanism for exchanging information under TEFCA.

 

A Participant Member represents an entity with authority to send or receive healthcare information. It is worth noting that an Individual User can also have this authority.

 

One of the things that I found confusing was the language around the Participant and Participant Member. They are described as ‘A natural person or entity that has entered into an agreement’. While this seems to be addressing a perceived need for flexibility, which is always appreciated in healthcare, flexibility can also introduce abmiguity. It seems as though we are focusing on the entity and not the role. Is a provider in a health system a Participant Member, Participant or Individual User?  Ambiguity is the foundation of the walls that keep us from meaningful interoperability. I think a good way to think about this is that a Participant agrees to follow the data sharing rules with a QHIN and a Participant Member and Individual User agree to follow the rules necessary to provide and receive healthcare information. I think that a “natural person” can function in different roles, depending on the nature of the application they are dealing with so any person could function as a Participant Member or an Individual User. If you disagree or have any feedback on this, please share them in the comments.

 

Qualified Health Information Network (QHIN)

The QHIN is the transportation mechanism that routes healthcare information, which is pushed or requested, between participants. Multiple QHINs may take part in that transportation according to the rules of TEFCA. The rules relating to the technical and functional details of how Participants and QHINs interact and share information with each other reside in the QHIN Technical Framework document, described earlier.

 

Recognized Coordinating Entity (RCE)

The RCE is essentially an authority that is responsible for keeping everything together. It develops and maintains the cooperative agreement, approves and monitors the QHINs and adjusts the technical framework as necessary.

 

Schoober - Connecting you with the people, places, and data you need

Schoober-Graphic

It’s time for an analogy! Let’s imagine TEFCA as a hypothetical student transportation network called “Schoober.” The business model of Schoober is to route students (healthcare information) from their homes (Participants) to their schools (other Participants). In order to do this, a parent (Participant Member) must approve and a school administrator (Participant Member) must also approve. The driver and vehicle (QHIN) picks them up and delivers them based on this agreement. Let’s imagine that these vehicles are confined to a given territory. That means that in some cases, the student may be required to ride multiple vehicles to get from home to school.

 

There might also be emancipated students (Individual Users) that require transportation to Schools (Participants) or to see their independent tutors (Individual Users) and Schoober can arrange for that to happen as well.

 

The management of the Schoober platform (RCE) is responsible for making sure all of the rules for student travel are in place, and the parents and teachers are authorized and in good standing. They enroll new vehicle drivers and monitor their activity. They establish the minimum requirements of each vehicle and ensure they have a protocol for receiving and delivering the students safely. When something happens that could impact the transportation network, they coordinate the activities necessary to mitigate the impact to evolve the network accordingly.

 

The Road Ahead

TEFCA provides a framework for sharing patient information that is absolutely necessary for our industry to improve our ability to bridge our data silos. The objectives that have driven TEFCA to this point are good ones, but the road ahead will not be easy. In general, the objective is “more data where it is needed.” While this can be helpful, many of us know that more is not necessarily better. For the objectives of TEFCA to be realized, there is still one big ugly barrier that stands in our way. That problem is the quality of the data that we have and that we share. Until we have a better handle on the quality of our data at each Participant, we have an inherent risk of sharing a virus instead of a cure. Looking back at our Schoober analogy, you want to make sure your student has been properly vaccinated before you send them to the school to avoid a measles epidemic. To address this, I believe we need to think about how we can improve the quality of the information we are sharing. I do not want to sound pessimistic. I think TEFCA is a great step in the right direction. We just need to realize that until we address the data quality problem, we may not get the results we expect. If we don’t get those results initially, we should resist the urge to throw the baby out with the bathwater. When we sort out the data quality barrier, we will be much better off with something like TEFCA in place.

 

There are many helpful references on the HealthIT website that helped me understand TEFCA. For an informative presentation deck from HealthIT.gov, go here.

Topics: Insider