ONC Gets It Mostly Right with TEFCA 2.0

Noam H. Arzt, Ph.D.On April 17, 2019 the Office of the National Coordinator for Health Information Technology (ONC) released the second draft of its Trusted Exchange Framework and Common Agreement (TEFCA) for comment. The initial version was released more than a year ago in January 2018 (see my original blog). As before, this is in response to a requirement imposed by Congress in the 21 Century Cures Act. After a somewhat lengthy (but well written) introduction, the document contains three parts (compared to just two parts the first time around):

• The Trusted Exchange Framework (TEF), which highlights a set of six core principles underpinning the whole effort. Just like the first draft, the principles seem pretty solid. I was struck by what I'll refer to as a "hierarchy of standards adoption" identified in Principle 1: Standardization which proposes that Health Information Networks (HINs) look first to standards adopted specifically by Health and Human Services (HHS), then to standards that are part of the ONC Health IT Certification Program, and finally standards identified in the Interoperability Standards Advisory (ISA).
• A set of Minimum Required Terms & Conditions (MRTC) for actors in trusted exchange (what had previously been identified as the Common Agreement), be they Qualified Health Information Networks (QHINs), participants connected to QHINs, or members and individual users connected directly to QHINs or to participants. This section defines relevant terms, describes a proposed process for designating QHINs including a new designation of "provisional QHINs" for HINs under consideration, and then defines the "rules of the road" for applicable transactions. These rules cover many different areas for QHINs, including basic operations; data quality; transparency; cooperation and non-discrimination; privacy, security and patient safety; and minimum obligations for participants and members.
• The QHIN Technical Framework (QTF) which describes how trusted exchange might be implemented. This did not exist previously as a separate document but was embedded within the TEF in the original version of TEFCA. This section includes some sample scenarios, or use cases, for the exchange transactions supported by TEFCA along with specified and alternate standards (when available) for each. The section then proposes a set of functions and the technology to support exchange, including digital certificate policy; encrypted transmission; user authentication and authorization; query; message delivery; record location; directory services; privacy preferences; auditing; and error handling. Embedded within this section are thirteen requests for comment (RFC) on specific aspects of the technology and standards.

The new draft contains a set of key changes, including:

• A narrowing of the exchange "purposes" covered by TEFCA to align better with HIPAA and to set a less ambitious agenda for initial implementation. Public health continues to be an included purpose.
• A change in the exchange modalities, with the removal of population-level data exchange which was deemed too aggressive and the addition of a message delivery (or "push") modality based on numerous comments on the initial draft.
• Removal of the technical standards from within the TEF itself into a separate QHIN Technical Framework (QTF) section to facilitate independent development and maturation of the standards and technologies separate from the policy in the TEF.
• A broadening of the definition of a QHIN.
• A change in the timelines associated with implementation, extending the basic timeline for QHINs to adopt TEFCA to eighteen months and placing much of the decision-making for the implementation timeline in the hands of the Recognized Coordinating Entity (RCE) to be selected via open procurement by ONC.
• Some slight changes to rules around QHINs and charging fees, including the removal of explicit language stating that QHINs cannot charge to respond to queries for public health.

To help further explain the new TEFCA draft, ONC has provided a User's Guideslide deck, plus a series of 2-page information sheets for different stakeholder groups including state government and public health.

So how did ONC do this time around, especially from a public health perspective? Public health continues to play a conspicuous role in this proposal, whether it's explicit presence in the list of stakeholders, inclusion in the exchange purposes, and recognition of the role of existing state and local consent laws as they affect information exchange. The document continues to read well, and the supporting material from ONC is well written and useful. Separation of the technical framework from the TEF into the QTF is also a big improvement, though the contents of the QTF are still problematic (see below). The general rubric of how the Common Agreement will work - it's essential hub and spoke design - is cleanly laid out and relatively straightforward, though the draft still leaves one wondering just how many QHINs ONC envisions operating at one time.

Perhaps the most dramatic improvement is the inclusion of a "push" transaction among the exchange modalities. This is a major win for public health conceptually. Though neither the QTF chapter nor the slides used by ONC during an April 23, 2019 webinar show a public health interoperability scenario, the User's Guide made available by ONC did show a "push" transaction involving a primary care provider submitting an immunization record to an Immunization Information System (IIS).

That's where the problems begin. ONC has made it very clear that initial implementation as guided by the QTF is expected to rely almost exclusive on Integrating the Healthcare Enterprise (IHE) standards and transactions which are largely document-centered (as opposed to message-centered) and which do not represent the majority of health information exchange implementations today. There is nominal recognition of HL7's Fast Health Interoperability Resources (FHIR) standard as an alternative or emerging standard but QHINs would still be required to support IHE standards. Given the push for FHIR in the February 2019 ONC Notice of Proposed Rulemaking on Interoperability with its fairly aggressive proposed timelines it seems surprising that ONC would not circle the wagons around that strategy and advocate for FHIR more strongly.

Even more so, most public health transactions - certainly interoperability with IIS - are not currently implemented with IHE technologies. In all fairness, TEFCA only maintains that the QHIN to QHIN interoperability use this type of transaction; the QHINs at either end (or both ends) of the transaction could receive and forward messages in the manner that seems natural to both the provider and the IIS with existing standards-in-use (in the case of IIS, web services, steps 1 and 3 in the diagram above) and leave the IHE transactions to be between the QHINs alone transparent to the other participants (step 2 in the diagram above). But the intermediation by the QHINs would be complicated to track in this type of transaction. It is worth noting, on the other hand, that the national implementation of electronic case reporting (eCR) does support IHE XDR (the basis for IHE XCDR) according to Digital Bridge technical documentation.

There are some additional issues worth noting, including:

• The February 2019 ONC Notice of Proposed Rulemaking on Interoperability has trouble defining Electronic Health Information (EHI), but TEFCA does not seem to have an easier a time. It is critical that this key definition and its relationship to the emerging US Core Data for Interoperability (USCDI) be reconciled.
• TEFCA proposes to extend HIPAA privacy and security regulations to allTEFCA participants, even those who are not covered entities or business associates under that law. It is unclear how the public health exclusion in HIPAA will be treated within TEFCA.
• The issue of patient matching across the healthcare ecosystem continues to be a serious obstacle to interoperability. The description of patient matching for query purposes within the MRTC presents a rather simplistic view of patient matching, with no recognition of the complexity of uncertain matches, multiple matches, and similar issues. The Patient Identity Resolution section of the QTF does detail more expectations of a QHIN in this area but offers no real solutions to the difficulties we all experience. And the same requests for comment about recommended data elements for matching (RFC #7), standardization of patient identity resolution (RFC #8), and matching algorithm performance metrics (RFC #9) continue to be made.

I'm sure more questions will emerge over the coming months. Note that Dr. Noam Arzt, President of HLN, has been asked to again join the ONC's HITAC Trusted Exchange Framework Task Forceas it reconvenes in May 2019 to discuss this draft.

Diagrams used above were provided by ONC.

Comments on TEFCA are due to ONC on June 17, 2019.