The Trusted Exchange Framework and Common Agreement

Author: Brian Ahier

I have been talking and writing a lot about the concept of Interoperability 2.0 as I see a strong need for an upgrade to our interoperability capabilities in the healthcare industry. 2018 is going to see interoperability come even more to the forefront as regulatory action, pressure from value based payment and delivery models, and deeper partnerships between physicians and payers bring the needs for sharing health data into sharp focus.

HIMSS defines interoperability as the ability of different information technology systems and software applications to communicate, exchange data, and use the information that has been exchanged. Congress in the 21st Century Cures Act specifically defines interoperability in that it:

A. enables the secure exchange of electronic health information with, and use of electronic health information from, other health information technology without special effort on the part of the user;

B. allows for complete access, exchange, and use of all electronically accessible health information for authorized use under applicable State or Federal law; and

C. does not constitute information blocking as defined in section 3022(a).

The law also defines information blocking (and assigns some potential stiff penalties for violation) as a “practice that . . . is likely to interfere with, prevent, or materially discourage access, exchange or use of electronic health information” if that practice is known by a developer, exchange, network, or provider as being likely to “interfere with, prevent, or materially discourage the access, exchange, or use of electronic health information.” 42 U.S.C. §300jj-52(a).

HHS has a big pile of work to do on interoperability issues in the next few years. 2017 saw Tom Price, MD come and go as Secretary at HHS. And after a year of the Cures Act being signed into law ONC is expected to provide rulemaking on implementation of the relevant sections. The OIG at HHS, who will be the enforcement arm investigating possible information blocking violations, is waiting for such rulemaking to work through process and become final – hopefully by April 2018 to provide some stability to the market. The law also calls upon the Office of the National Coordinator for Health IT (ONC) to develop or leverage a trusted exchange framework and common agreement to support achieving nationwide interoperability.

On January 5, 2018 the ONC released the draft Trusted Exchange Framework and Common Agreement (TEFCA). What exactly is this TEFCA you might be asking… Well, creation of framework is consistent with the focus on interoperability in the Cures Act. Public comments are due by February 20th, 2018 (you can submit comments electronically via email at and the final version is expected to be published at the end of 2018. The TEFCA is a voluntary program designed to connect Health Information Networks (HINs) by having a framework of Qualified HINs (QHINs) overseen by a Recognized Coordinating Entity (RCE). The RCE would get authority through a Cooperative Agreement with the ONC chosen through a competitive bidding process. The RCE will be responsible for developing the Common Agreement and to operationalize the Trusted Exchange.

The draft released by the ONC has two parts:

· Part A, which lays out the principles for Trusted Exchange

· Part B, which sets the minimum terms and conditions for Trusted Exchange

The principles articulated in Part A are:

  1. Standardization. Stakeholders should adhere to industry and federally recognized standards, policies, best practices and procedures.
  2. Transparency. Stakeholders should conduct all exchanges openly and transparently (e.g., publicly releasing terms, conditions and contractual agreements that govern the exchange of information).
  3. Cooperation and Non-Discrimination. Stakeholders should collaborate across the continuum of care to exchange Electronic Health Information (“EHI”) regardless of the competitive nature of stakeholders (e.g., stakeholders should not create policies that use the law as a pretext for limiting access to patient information to health care providers or health plans outside of their preferred network).
  4. Privacy, Security and Patient Safety. Stakeholders should exchange EHI in a secure manner that promotes patient safety and ensures data integrity (e.g., ensuring that data are consistently and accurately matched to the right patient, so care is provided based on the right information).
  5. Access. Stakeholders should ensure that individuals and their authorized caregivers have easy access to their EHI.
  6. Data-Driven Accountability. Interoperability should include the ability for participants to request and receive multiple patient records in a single instance, consistent with applicable legal requirements, for more effective use of data analytics to lower the cost of care and improve the health of the population.

These principles embody a decent set of guardrails and general principles that I believe health information networks should embrace to support interoperability.

Part B focuses on technical rules and details relating to the obligations of QHINs to adopt common authentication processes for network participants and a minimum core set of organizational and operational policies to enable the exchange of EHI among networks. ONC designed the terms and conditions to align with, and in some instances exceed, HIPAA privacy and security requirements (e.g., requiring participants to notify the RCE within 15 days of a breach).

The draft proposes quite a number of conditions on QHINs, some of which would require changes in business practice, necessitate technical upgrades, and make changes to existing participation agreements to conform with the Common Agreement. QHINs will be expected to use standards adopted or recognized by ONC’s Health IT Certification Program and Interoperability Standards Advisory (ISA). QHINs would be required to cooperate with and not discriminate among stakeholders across the continuum of care by not implementing policies, procedures, technology or fees that will obstruct access and exchange of EHI between other QHINs, participants, and end users. And QHINs will be expected to support the ability for participants to pull and push population level records—bulk transfer—in a single transaction rather than transmit one record at a time. A QHIN would be required to be participant neutral, although this term is not adequately defined in the draft proposal.

With regard to fees and other costs, the draft requires that they be reasonable and should not be used to interfere with, prevent, or materially discourage the access, exchange, or use of EHI within a QHIN or between QHINs. Fees may include but are not limited to, one-time membership fees, ongoing membership fees, testing fees, ongoing usage fees, transaction fees, data analytics fees, and any other present or future obligation to pay money or provide any other thing of value. ONC’s approach is to let the market sort out how much providers, vendors, payers and other end users will have to pay to participate.

QHINs will need to provide or make use of the services of a Connectivity Broker. The connectivity broker must provide all of the following services with respect to all permitted purposes: master patient index (federated or centralized); record locator service; all types of queries/pulls; and EHI return to an authorized requesting QHIN. The Qualified HIN’s Broker service must return EHI from across all of the QHIN’s participants and their End Users in a single transaction or, upon request of the initiating QHIN, provide a list of all EHI locations back to the initiating QHIN’s Broker and, if further requested by the initiating Qualified HIN, subsequently return the requested EHI to the initiating QHIN. Currently these connectivity broker services are primarily provided to health information exchange networks by vendors.

The provisions relating to QHINs would flow down to the participants and ultimately the end users on the network. The terms and conditions required within the Common Agreement would apply up and down the chain of trust.

There are three types of use cases envisioned under the draft TEFCA: Broadcast Query, Directed Query, and Bulk Transfer.

· A broadcast query is sending a request for a patient’s EHI to all QHINs to have data returned from all organizations that may have it. This is intended to support situations where it is unknown who may have EHI about a patient.

· A targeted query is a request for a patient’s EHI to a specific organization. This is intended to supports a situation where one would want specific EHI concerning a patient, for example data from a particular specialist or a certain facility. These types of queries are common today generally supporting transition of care.

· A bulk transfer, or query for population level data is when information about multiple patients is included in a single query. This is intended to support population health management, quality measurement, risk analysis, and other analytics.

Bulk transfer for the purposes of population health is certainly a laudable goal, but one that the market is not yet ready for being a mandatory provision. This would seem to create additional burdens upon participants in QHINs in order to meet the permitted use requirements, and that these requirements may have a negative downstream effect on participants and their willingness to join a QHIN or an HIE that is a member of a QHIN.

There is a call out to the rights of individuals who do not wish to have their EHI exchanged, and managing consent (already a challenging prospect) becomes incredibly complicated under the TEFCA. There are multiple state laws dealing with consent and managing the spaghetti strands of intermingled laws and regulations to accomplish this at national scale is ambitious to say the least. And as a HIPAA Business Associate, the QHIN must also enable a Covered Entity to process a request consistent with the right of an individual to request restriction of Uses and Disclosures. Further, if an individual who previously granted consent to share EHI, they may at any time revoke such consent – there is no mention of how to deal with the data that has already been shared and proliferated across the various networks. There are still outstanding questions regarding consent management, and the impact of state laws and contract variance (e.g. opt-in vs. opt-out).

What are the qualities ONC is looking at for the RCE and what will be the responsibilities for the selected entity? The RCE will need to have experience with building multi-stakeholder collaborations and implementing governance principles. A non-profit organization acting in a neutral manner would be necessary. Entities will be able to bid on the Cooperative Agreement to be the RCE later this spring, then ONC officials plan to engage with the RCE by August. The RCE will work with ONC to further define and enforce that minimum core set of organizational and operational policies to enable the exchange of EHI among networks. The RCE will use the policies, procedures, technical standards, principles and goals to develop a single common agreement that QHINs and their participants will voluntarily agree to adopt. HHS may make adoption of the framework and common agreement a requirement for funding, either through grants, MIPS, and other payment mechanisms, and it could also be that the upcoming rule on information blocking could specifically describe adoption of the TEFCA as NOT information blocking.

The ONC also released simultaneously a set of data standards called the U.S. Core Data for Interoperability (USCDI). Under the Trusted Exchange Framework, those minimum data classes would be “adopted and updated from time to time by HHS.” Use of an Open Application Programming Interface (API) is one of several priorities for the agency. Under the 2015 EHR Certification requirements, EHR vendors are required to be able to transmit CCDS data via open API. The USCDI expands on the previously published Common Clinical Data Set, including the same data classes referenced by the 2015 Edition CCDS definition but also includes two new data classes: Clinical Notes and Provenance. Clinical Notes is composed of structured (pick-list and/or check the box) and unstructured (free text) data. The free text portion of the clinical note may include the assessment, diagnosis, plan of care and evaluation of plan, patient teaching and other relevant data points. Provenance describes the metadata, or extra information about data, that can help answer questions such as when and who created the data. The data classes for the initial draft USCDI v1 are expressed in the table below:

The draft USCDI provides the process, data policy context, and structure by which a predictable schedule to expand the USCDI can be accomplished through collaboration with the industry. Once a data class has been proposed by the industry, it will follow a gradual process where it will be promoted to emerging status, then candidate status, and, ultimately, included in the USCDI. Once a data class is officially included in the USCDI, it will be required for nationwide exchange. The timeline for expansion is aggressive with USCDI v2 scheduled for 2019 and USCDI v3 to be published in 2020.

I do not expect 2018 to be year that the Federal government solved healthcare interoperability – as a matter of fact, I believe the solutions lie in the private market with a light regulatory touch from the government. ONC acts best in the role of convening and collaborating with the private market to solve the pressing issues facing our nation as we attempt to transform the system to one that pays for quality of care, not quantity. Organizations like the Sequoia Project and DirectTrust have successful trust frameworks in place that are industry led and standards based. ONC would do well to remember that Congress warned that the TEFCA should not disrupt the exchange that is already in place. I do not expect this administration to start throwing out all kinds of new regulations in any event. However, interoperability will continue to be front and center in 2018, and it is not simply a technology problem.

Ready to see Medicity in action?
Contact Us