How Will the Healthcare Blockchain Accommodate New Data Classes in The U.S. Core Data for Interoperability (USCDI)?

On January 5, 2018 HHS’s ONC released the Draft Trusted Exchange Framework and Common Agreement (TEFCA)which has received a significant amount of attention in the healthcare information technology media. TEFCA is designed to to comply with the 21st Century Cures Act which addresses the current state of healthcare infrastructure and access in the United States.

To be sure, the Trusted Exchange Framework has the potential to change the digital health landscape in ways not imagined under meaningful use, HITECH Act, and even the Accountable Care Act.

Currently, there are many Health Information Networks (HINs) that operate locally, regionally, or nationally. But often, these entities don’t exchange health information with each other due to variations in their participation agreements and sometimes competitive interests. This limits the ability of individuals, providers, health systems, public health, and others to use the existing HINs to exchange data no matter where an individual has received care. Building and maintaining trust across and among these HINs is key to interoperability of health information outlined in the Cures Act. This affects everyone in the country — patients and their family members, providers, public health officials, and health plans and systems that need information to ultimately help improve patient care and outcomes. ( Genevieve Morris / Principal Deputy National Coordinator for Health Information Technology)

The ONC also released a 13 page document titled U.S. Core Data for Interoperability (USCDI) on January 5, 2018. It is a fact that the USCDI will not remain static and will incorporate additional information and specific patient related data elements over the next 5 years.

The Draft US Core Data for Interoperability (USCDI) and its proposed expansion process aim to achieve the goals set forth in the Cures Act by specifying a common set of data classes that are required for interoperable exchange and identifying a predictable, transparent, and collaborative process for achieving those goals. This document provides ONC’s first draft of the data classes that would be in the USCDI and lays out the process and structure by which the USCDI will be updated and expanded. The USCDI and its expansion process are intended to be collaborative vehicles around which ONC and the industry can coalesce to identify the critical data needed to enable interoperability and achieve the goals outlined in the Cures Act, we invite stakeholders to submit feedback on the proposed process and initial assignment of the data classes. (USCDI, January 5, 2018)

The most striking aspect of the Draft USCDI Data Classes is what is NOT included.

Shockingly there are NO data classes for patient generated data, including patient stories, interpretations, social media activity, and wearable IoT data streams.

In reviewing the document from a blockchain perspective, it is interesting to see “Provenance” identified as a “Data Class” all its own. It is probably more realistic to incorporate provenance at a more granular level associated with individual results/values. For instance, a lab analyzer and specific reagent batch may be associated with a patients clinical laboratory result from an identified clinical lab. By following the provenance of a particular lab result form a Roche, Becton Dickinson, or other analyzer frauds such as the Theranos Medical Device Fraud could have been avoided.

It would be very interesting if ONC intends to place provenance related to the origins of specific results from reporting systems, EMRs, MRI Machines, and other laboratory analyzer at a granular test level. This data is already required or at a minimum referenced in the HL7 Laboratory Automation Documentation.

The types of information communicated between these systems include process control and status information for each device or analyzer, each specimen, specimen container, and container carrier, information and detailed data related to patients, orders, and results, and information related to specimen flow algorithms and automated decision making. This wide array of communicated information is essential for a Laboratory Automation System (LAS) to control the various processes and to ensure that each specimen or aliquot has the correct tests performed in the proper sequence.

It is possible that the Provenance Data Class could represent a set of information that identifies any and all entities that transferred or communicated data to the USCDI. If this is the case, this data class might be an excellent candidate for reporting on a public or “semi-public” blockchain. In any event, kudos to the ONC for placing such a high priority on data provenance.

The Emancipation Data Class does not refer to any underlying technical specifications such as FHIR, HL7, ASTM, ANSI, or C-CDA. The Emancipation data class defines a “… legal process that specifies when and under what conditions minors can become legally recognized as adults, independent of their parents.” The Emancipation data class could be specified as a smart contract on a blockchain which would cause various security privileges and access to be switched on or off for parents with minor children. For instance, the execution of an emancipation data class as a smart contract could prevent future access to the records by a parent, and simultaneously create a new record referenced on a blockchain that would represent the minor child, completely separate from and relationship with a parent or guardian. Issues surround the Emancipation Data Class will have to be integrated into other parts of the patient record to make sure that the “emancipated minor” will be allowed to receive prescribed medications without the parent or guardian.

The expansion of the USCDI is an important step to modernize the US Healthcare System. Individuals and entities looking integrating blockchain solutions will need to pay attention to the data classes being added.

Edward Bukstel

CEO

Clinical Blockchain