The Tension in TEFCA

The following is a guest article by Don Rucker, MD, Chief Strategy Officer at 1upHealth

Patients want the same modern computing experience in healthcare that they enjoy the rest of their lives to extend to our health and medical care. They want a modern consumer experience with ease of access, speed, availability, accuracy, and affordability. US healthcare is notorious for whiffing on the consumer experience, and it looks like we are about to miss another big opportunity to get things right if the current TEFCA plans stay mired in 90s tech.

The public comment period for the current TEFCA proposal closes on June 20th, and I encourage all of my health tech colleagues to consider submitting a letter. The following are some of my thoughts on the matter:

The 21st Century Cures Act provides a platform to empower patients and enable a more modern and robust consumer experience. Two requirements in particular are critical to that goal: “APIs without special effort” and a requirement to share data on behalf of the patient (“information blocking prohibited”). The Act also outlines the concept of a Trusted Exchange Framework and Common Agreement (TEFCA). While standardized APIs and a prohibition on information blocking are relatively straightforward concepts, there was no clear technical roadmap to what might be a “trusted exchange framework”. Obviously, the Internet seems like the place to start thinking about an exchange framework. The modern Internet, a stunningly successful network, relies on flyweight management, competition on the provision of infrastructure, Domain Name Services without a lot of overhead, and privacy/security through mathematically robust authentication mechanisms.

The Sequoia Project, a spinoff of a prior EHR network, was chosen as the governing body for TEFCA. They have advanced the current TEFCA implementation which is based on the 1990’s IHE document exchange protocols with a brokerage model (QHIN) overlay. Use of a protocol from when the Internet was largely page-views (think the old AOL and Yahoo days) clearly generates concerns when we see what modern RESTful APIs and JSON based granular data and straightforward APIs have enabled globally.

Considerations shift over to what use cases TEFCA supports today and what a reimagined TEFCA might support in the future. Today TEFCA only supports document exchange and frankly largely within legacy EHR vendors who have familiarity with the IHE protocols. While the QHIN brokers hope to attract new users such as payers and Federal agencies, it is unlikely that TEFCA will allow new entrants from outside of healthcare who would be unlikely to have legacy programmers or derive value from needing to parse documents. The document exchange nature of current TEFCA makes it largely an “eyeball” protocol, i.e. a human has to read the documents to derive value. “For the doctor’s eyes only” if you will (Bond fans anyone?) and providing information between treating clinicians is currently TEFCA’s most commonly cited use case. 

Current TEFCA proponents offer several value propositions which are worth investigating. One is that the QHIN directory services will add value. While some QHINs have extensive private EHR network connections searching for a patient’s data cannot result in every query searching every medical record in the United States so some form of localization of search must occur. The hard work for a software developer is in that search and whether the search can be “directed” to a specific provider or “broadcast” to a small enough set of query targets to be reasonable.   Fundamentally, that work has to be done by TEFCA participants. Interestingly, the same Cures Act requires CMS to stand up a publicly accessible electronic provider directory. If that were to exist there would be little need for brokered services to do the same. The Internet does with the DNS protocol which generates extremely low per transaction costs embedded in connection fees.

Another suggested value proposition is that of brokered security and consent. I suspect that having proprietary security protocols different from the Internet at large will add in rather than remove security risks. This is simply because the modern Internet standards have had so many eyeballs looking at them that they are quite robust.

There have been public statements from ONC and to extent from the Sequoia Project that TEFCA will be modernized to computable data – i.e. FHIR data. There are also some statements that it will not require brokers in the future. FHIR has been around for over 10 years so it is worth pondering why it was not incorporated into TEFCA from the start. FHIR is a data standard not an API standard but it is typically coupled with elegant RESTful API standards. Trying to load atomic data on a verbose API standard strips out much of the speed of use and programming ease so the failure to figure out a way to do this so far is not surprising.

Of course, the big question is, what is the public benefit? Moving snippets of the medical record around can certainly help in some patient care scenarios but does any of this support the type of modern computing needed to fundamentally change the value proposition in American medical care or enable the approaches that will really prolong life and improve health?

So, we see that in today’s TEFCA there is an innate tension between the past and the future. ONC and HHS should carefully think about the policies that might lock in the past and policies which would enable the future. We look forward to true interoperability and computable health information and hope that TEFCA will become one of those building blocks rather than serve as a detour in our search for true interoperability.