ONC's Trusted Exchange—A Public Health Perspective

Noam H. Arzt, Ph.D.In January 2018 the Office of the National Coordinator for Health Information Technology (ONC) issued a draft Trusted Exchange Framework and Common Agreement (TEFCA), and related supporting documents, in response to a requirement imposed by Congress in the 21^st Century Cures Act. The Act says that the TEF may include a common method for authenticating users, a common set of rules, enabling policies, and a process for managing non-compliance. Nowhere does the Act instruct ONC to determine an actual technical architecture in this process, though such a step is not precluded either.The primary document is in two parts: Part 1 is a set of principles that set the foundation for Part 2 which is a set if minimum terms and conditions for trusted exchange.

While the principles seem overall quite reasonable, the terms and conditions have many, many technical specifications and standards embedded within them and lay the groundwork for a very specific nationwide implementation. Though the phrase “network of networks” appears nowhere in these documents, Part 2 seems to describe a technical implementation not too unlike the original NwHIN/eHealth Exchange model that was implemented with limited success a number of years ago. It does not appear that this model fits all that well with any of the major market-based strategies that have emerged in the past several years, notably the Commonwell Health Alliance, Carequality, or the Strategic Health Information Exchange Collaborative (SHIEC).

In several public webinars since the release of the documents, ONC described the vision as a “network of networks of networks” and suggested that only a small number of top-level networks to participate directly in TEFCA. This is presumably to limit the number of entities that actually need to comply directly with TEFCA requirements, though at least some of these requirements “flow down” to entities connected to these top-level networks. At the core of the model is the Health Information Network, or HIN, which brokers the movement of electronic health information between two or more unaffiliated entities. A Qualified HIN (QHIN) is an HIN that abides by the terms and conditions of the Common Agreement. To keep the number of QHINs manageable, they must be “participant neutral,” and ONC maintains that a regional or state HIE would not qualify.

The definition provided by the TEFCA document does not clearly state why, though if this is ONC’s intent a clearer definition is required. Perhaps ONC should define a QHIN based on the number of levels, or “hops,” it is from the clinical user: A single-organization HIE is zero hops since it is transmitting its own data and therefore clearly could not be a HIN. A regional or state HIE which directly connects provider organizations would be one “hop” from the clinical data whose exchange it enables and could also be excluded if ONC desired. A state, regional, or national HIE that connected multiple lower-level HIEs would be two “hops” from the clinical data and could by this definition be eligible to be a QHIN, as could a national network which interconnected regional HIEs (three “hops” from the clinical organization). But interestingly, some national networks like Commonwell and to a lesser degree Carequality, also have provider organizations as members and supporters. It does not seem that they could ever be QHINs by ONC’s current definition (or even the one proposed here).

The model embedded with the Common Agreement is a somewhat muddled implementation that draws on the technical capabilities of a number of approaches; the IHE Cross-community Access (XCA) standard supported by Patient Identifier Cross Referencing (PIX) for patient matching adjudication seems to be supplemented by calls for a master patient index and a record locator service, neither of which are features of XCA. The model is also completely a query (“pull”) model, and unsolicited, or “push” transactions (such as those supported by the Direct protocol, once heavily promoted by ONC) is not even mentioned.

ONC has clarified that push transactions were excluded because they considered these transactions well served by current networks and trust authorities. The model references the Consolidated-Clinical Document Architecture (C-CDA) format exclusively and ignores mentioning virtually all other data exchange formats, including HL7 v2 messages that account for a large volume of transactions today, with a passing reference to HL7’s Fast Healthcare Interoperability Resources (FHIR) and the SMART specification. It seems somewhat limiting for the assumed technical architecture of TEFCA to be embedded in the CA itself. A more sustainable approach might be to reference an external technical architecture that could be determined and maintained independent of the agreement itself but included by reference. Including only “pull” and not “push” transactions also runs the risk of the establishment of parallel infrastructures operating under parallel, but not necessarily consistent, policies.

Very few public health data exchange transactions are supported on the architecture described in these documents. Most public health reporting is done via unsolicited HL7 v2 messages (e.g., immunization data submission, electronic laboratory reporting), and in some cases via CDA document transmission (e.g., cancer reporting, electronic case reporting). Queries to public health registries are usually executed with a known end-point (i.e., the registry in the clinician’s jurisdiction), though with an increasingly mobile population and medical trading areas that cross jurisdictional lines there is certainly a need for query to public health registries beyond the provider’s home jurisdiction. The Common Agreement also pays little specific attention to the reality of inconsistent state, local and tribal patient consent and data sharing laws that are often an obstacle to cross-jurisdiction interoperability.

The requirement that a Qualified HIN implement APIs embedded in standards within twelve months of their publication seems somewhat unrealistic. The standards development process is ongoing, yet it takes longer for a set of systems fulfilling a particular use case to implement a particular version of a standard consistently and pervasively. For example, though the Immunization Information System community is still working to implement HL7 v2.5.1 messaging, HL7 has already balloted a v2.9 message. Organizations – including public health agencies – are unprepared to migrate to newer standards just because HL7 has published them. Even for C-CDA and FHIR standards, new (and sometimes conflicting) profiles are developed continuously and it may not be clear which one is appropriate to use. In some cases in the public sector, standards themselves are embedded in legislation or regulation that has longer chance cycles.

A companion document, the Draft US Core Data for Interoperability (USCDI), introduces some additional uncertainly. It is not clear how an ever-expanding set of core data can ever be routinely satisfied when we struggle today to accommodate even the most basic data requirements reliably and accurately. It is also unclear how the HIPAA notion of “minimum necessary” applies to the requirement for transmitting a pre-determined core set of data.

There is a one page document provided targeted at State Government and Public Health. Finally, note that the ONC Shared Nationwide Interoperability Roadmap is not referenced in any of these documents.

Though the strategies and draft agreements described in these documents, if adopted by ONC, would remain completely voluntary, the Act mentions that Federal agencies may require its use in certain circumstances. This may have a profound effect on both public health agencies and their trading partners; if they don’t consider TEFCA in their planning it may become a requirement nonetheless. Existing HIEs (or HINs) and collaborative activities may not find it compelling in the short run to change their direction. New initiatives may now find themselves unsure of what direction to pursue. Only time will tell if TEFCA will have the impact on interoperability that Congress desires.