Below is Centralis Health’s formal response to the Office of the National Coordinator for Health Information Technology (ONC) request for information as it relates to the United States Core Data for Interoperability (USCDI) v2. This response is reflective of the needs and thoughts of participants.
Introduction
Centralis Health, LLC welcomes the opportunity to provide comments and suggestions on the United States Core Dataset for Interoperability (USCDI) version 2 (v2) and hope that our input will be found as intended: positive, supportive, and aimed at improving healthcare for everyone. We base our comments on our company’s long history of providing data exchange between and among healthcare entities, the Final Rule on Information Blocking1, and our work on the implementation of a practical data model to support community/regional health information exchange.
We respectfully submit that, due to the pivotal role that the USCDI v2 will play in the health data exchange ecosystem and the enforcement of the Information Blocking Rule (IBR), the community will need to supply a robust and expansive definition of the USCDI v2 so it does not become the “regression to the mean” that will allow various players to not support interoperability by leveraging (i.e., not providing) information currently available in existing exchange settings (e.g., HL7 elements exchanged today). Even if our suggestions only encourage the Office of the National Coordinator to opine on the future direction of the standard, we think that this will encourage better realization of interoperability. Our suggestions fall into three major categories:
- Scope and depth of USCDI v2 (unintended limitation of data elements for interoperability). The data elements currently in the USCDI v2 are not as expansive as those in HL7 messages currently being exchanged today.
- Metadata and Structure Elements of USCDI v2 (Limiting Usability of Data Elements in Workflows). Interoperability requires context as well as content and the metadata elements linking the structure of patient treatment to its representation in the data are not fully developed.
- Expandability of USCDI v2 to Support Emergent Needs (COVID-19 Results Response). The ability to handle more immediate or emergent expansion of data elements and classes to meet real-world requirements does not seem to be addressed (i.e., the exchange of detection, diagnostic information, and treatment of COVID-19.)
Each of these categories is developed below and, in the interest of brevity, we do not explore full implications however we are ready as a company to offer greater insight upon request.
Scope and Depth of USCDI v2
(Unintended Limitation of Data Elements for Interoperability)
The Office of the National Coordinator defines Interoperability2 as: “… the term ‘interoperability,’ with respect to health information technology, means such health information technology that— “(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).” In somewhat more colloquial language, Centralis Health likes to define Interoperability as “the right data, for the right person, at the right time” playing off the triple aim3 enunciated long ago. Over the course of the last 32 years, the HL7 organization has created a rich, robust data interchange method covering many thousands of systems within HIT exchanging millions of discrete data elements, data containers, and metadata information. There are troves of electronic health information (EHI) encoded in HL7 moving between entities every day. Centralis believes that it is this existing exchange that USCDI seeks to support and expand.
The concept and spirit of interoperability means that we should seek to exchange all available EHI between authorized and verified partners. In medical trading areas (MTA) and among certain HIT vendors, this rich exchange of EHI, supported by HL7 in its various flavors, continues daily. Yet, the latest IBR sets as a “minimum” standard the exchange of USCDI v1 elements. Without doing an exhaustive analysis, we believe it clear that defining USCDI so narrowly (or alternatively, allowing participants to block all but the USCDI elements) offers the possibility of stymying the progress we have fought for since 1989 by defining as “good enough” a small subset of the EHI a vendor must share. Giving a vendor the option to use USCDI to “meet the standard” for IBR seems to defeat the proviso that (from the Final Rule) “The criterion’s proposed conformance requirements were intended to provide a means to export the entire EHI a certified health IT product produced and electronically managed …” [emphasis ours]. We would respectfully contend that the USCDI v2 does not offer a broad enough range or scope of data elements and classes to meet Final Rule conformance requirements as written.
Metadata and Structure Elements of USCDI v2
(Limiting Usability of Data Elements in Workflows)
One of the most defining trends of the healthcare ecosystem is that all care journeys require interaction of a patient with multiple providers and organizations across an MTA. This means that we must manage and coordinate information in both time and space (locations of care) and that the vast information stores referenced earlier must support these temporal translocations. In doing so, the system must have ways to collect and distribute relevant data (e.g., treatment for a 46-year-old prostate cancer patient does not require information from their tonsillectomy 33 years ago) and link it to disparate systems all along the way. Individual medical records are far too large to transfer to every provider in the chain. In fact, such a broad sharing limits the usefulness of the data through obfuscation as well as overburden HIT systems and decrease system performance.
That means that the data presented at each stage and process step of treatment needs to be focused and appropriate. The challenge of HIT support of this system is to encapsulate the relevant data, present it to the provider(s) giving care in real time, collect the new and still relevant data, and distribute the new data collected during treatment to the next “node” in the patient care journey. As an example, lets reference HL7 again and specifically note the embedded established hierarchy of Facility -> Patient -> Encounter -> Clinical Note/Order -> Results. Now think about the linkage between the data elements and how important that relationship is to workflows and the relevance of that data within the episodic care delivery model. If you remove the Encounter, and its associated data, from the chain the Result is orphaned and loses relevance (i.e., what was the reason for the visit that led to the result – a patient wellness visit or a trip to the ER.)
The challenges in all of this linkage and transfer are far too numerous to list but suffice it to say that the USCDI v2 acknowledges this (somewhat) in saying things like “… it would be ill-advised for USCDI to enumerate the tens of thousands of specific observation ‘variables’… “ but continues to say that we can handle this vast diversity through the use of “shared templates.” Centralis Health contends that we need an explanation and explication of what such templates would look like. More specifically, we need a rich set of metadata fields to go with the information as it moves through the process.
Perhaps we should imagine the use of an umbrella Patient Journey ID that allows collection and linkage of numerous other System Patient IDs where the relevant information collects (along with its timing and location) along the way. This will provide the context for treatment and display of the right data at the right time and then appropriate redistribution of relevant data to the supplying systems post-treatment. Our review did not show definition or acknowledgement of this type of metadata (or the many other types available). Since again, we are trying to allow the exchange of the full universe of EHI, USCDI v2 should both acknowledge and call out the need for metadata and its linkage to the hierarchical structure needed to represent a patient journey even in its definition of “Core.”
Expandability of USCDI v2 to Support Emergent Needs
(COVID-19 Results Response)
While the practice of medicine responds to the environmental needs well (see, for example, the COVID-19 reaction), the need to communicate in new ways (e.g., contact tracing operations) during these responses are rarely anticipated. Other data standards and processes have acknowledged this reality and offer ways that exchanging organizations can define transactions and elements “on the fly.” This gives the standards bodies and regulators the time to evaluate and approve how the information flows and, potentially, even shows the best uses and data elements for a given response. All the while, the actual process of treatment and its supporting data flow appropriately.
To put this in a more concrete way, a patient that has had several COVID-19 tests over time can be tracked and traced “higher” in priority4 based upon whether these tests were PCR or saliva tests due to the relative accuracies of each. But only if the results reporting gives the tracing organization the tools to know what test was used and when it was collected. The potential values (“Positive, Negative, and Inconclusive”) are necessary but not sufficient to support the need.
Since the whole system evolved over a matter of weeks, the exchange of data must take these exigent circumstances into account. Else, as happened this last year, we “revert” to using tools such as facsimile (fax) as the initiator of response to a positive test. Centralis Health speaks from hard experience having to “reformat” electronic laboratory data from its rich, searchable form to a PDF that gets sent via fax to the local health department to initiate the contact tracing. Not only does this represent a loss in functionality (e.g., searchability and input to public health analysis), it also prevents even the most basic forms of data quality checking and improvement. Long and short, we believe that the USCDI v2 should include the ability to respond to emergency and other circumstances without resorting to “ancient” technology. We suggest something along the lines of the HL7 Z-segment with a process to pull these “local” variations into the overall standard much like we do with open-source software.
Conclusion
We at Centralis Health hope that our comments and suggestions about the scope and depth of USCDI v2 data elements (and its relation to IBR), the inclusion of metadata elements and linkages to support workflows, and the method of meeting urgent needs quickly will provide insight and impetus to expand and enrich the USCDI. This brief position paper examined only the surface of the many deep areas needed to improve the USCDI v2, the IBR, interoperability in general, and practitioners’ ability to respond to the world as we find it. Centralis Health, as a day-to-day implementor and operator of interoperability, hopes that this view contributes to the overall understanding of the community.
121st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program
(25642 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations)
2https://www.healthit.gov/topic/interoperability accessed April 12, 2021.
3https://www.healthaffairs.org/doi/10.1377/hlthaff.27.3.759 accessed April 12, 2021.
4Given that most contract tracing groups needed to triage cases due to lack of resources.