By John Travis and members of the EHRA Information Blocking Task Force 

In our last blog on the United States Core Data for Interoperability (USCDI), the focus was on USCDI as the policy ground for advancing federal interests for promoting high impact needs for health data, and USCDI’s import as a certification specification impacting developers of Certified Health Information Technology (CHIT). In this blog, we focus on how the evolution and curation of USCDI impacts the efforts of health IT developers and implementers to “stay current.” 

Under the Office of the National Coordinator for Health IT’s (ONC’s) Cures Act updates to the 2015 Edition of the health IT certification criteria, a developer of CHIT must certify to the ability to exchange all of the USCDI. For compliance with ONC’s information blocking regulation, an implementer of health IT will want to adopt capabilities to electronically exchange the USCDI, particularly when requested by HL7® FHIR® or document-based exchange. 

During a recent discussion on USCDI expansion by the ONC’s Health Information Technology Advisory Committee’s (HITAC) Interoperability Standards Priority (ISP) Task Force, members made this preliminary recommendation: 

“In order to provide a common foundation for research, social determinants/health equity, and administrative burden reduction, ONC should build a clear and rapid roadmap to expand USCDI which should incorporate research and administrative needs.” 

Thus, it appears that future versions of USCDI will not focus strictly on a core clinical data set. We agree with that recommended expansion, which would be in line with ensuring all Electronic Health Information (EHI) — the electronic subset of the Designated Record Set (DRS) — can be accessed, exchanged, and used in a standards-based format. 

Since USCDI is currently a vehicle by which key data elements of EHI become mandates, we question whether USCDI should remain “all or none” in certification or as a potential requirement to participate in the anticipated Trusted Exchange Framework (TEF). 

The simple fact is that not all health IT, not all health IT developers, not all health IT implementers, and not all health IT users have the need or the ability to support all of what may be in future versions of the USCDI — particularly once it covers the full DRS. This may be because their business is focused on specific aspects of healthcare delivery, or because the role and purpose of their health IT is limited to a defined segment within the health IT landscape. 

For example, a post-acute rehabilitation service provider that does not provide immunization services may not have reason to capture, process, store or exchange the full data set necessary for immunization administration. They do not provide relevant services to enable capture of that data. Furthermore, while they may receive data from other providers and stakeholders, they may never have a need to ingest and manage such data at the data element level, only for cursory viewing. 

Similarly, a health IT developer might not provide a full suite of products that enable front end processes supporting the capture, processing, storage or exchange of clinical data that must accompany prior authorization interactions with health plans. In these and other cases, the “all or none” nature of the USCDI as it currently exists would impose unintended or unneeded requirements beyond the purpose of the health IT module or capability. 

Early days of certification included the concept of the “complete EHR,” defined as a monolithic set of capabilities that had to be present in total to pass certification. Issues with this approach were escalated and ONC eliminated it in favor of a more practical, modular approach. Similar thoughts should be considered for USCDI, as the same underlying concerns and considerations are in play. 

At a time when industry desires faster adoption of health IT updates, it seems that a more tailored and segmented form of USCDI should emerge, to allow for contextually appropriate subsets of it to be applied to different healthcare venues and different types of health IT. This also supports a more varied and fluid evolution of health IT configurations that best serve the community, while not requiring new entrants to immediately — or ever — have to support all.

From a provider perspective, USCDI should support the notion that a provider should “share what you can” using the interoperability standards of USCDI. For example, if a provider has data elements conformant to the currently-adopted USCDI version electronically available, appropriate to their clinical focus, they should be able to join and participate in trusted exchange, as well as participate in programs that require USCDI use in a manner appropriate to their care mission and the abilities of their adopted health IT. 

Similarly, if a health IT developer focuses exclusively on supporting post-acute care or hospice, but does not provide capabilities necessary for the data capture of a particular type of data not applicable to their provider users, their products should be able to be used and certified for the scope of intended function. Similarly, if health IT focuses on administrative processes, and thus manages administrative EHI, it should not be required to also support clinical data not relevant to its administrative purpose. Nor should health IT focused on electronic prescribing be required to support data not relevant to those processes. A modular approach provides better opportunities for all health IT, supporting any subset of EHI, to expose such data using a common, standards-based approach.

Lastly, health IT may not need to support all data to be exchanged in all formats. HL7 is planning to migrate, over time, the expression of documents to an HL7 FHIR-based format, taking full advantage of using data elements, data sets, and/or documents as appropriate, not just full HL7 CDA CCD documents for all exchanges. USCDI and associated supporting standards should not yield a monolithic approach, but instead a modular and dynamic approach where health IT, of any size and shape, supporting EHI can interact at the right level of granularity, with the right data content, for the right user and right patient. 

Given these challenges, ONC should recognize that the time has come for USCDI to be “categorized” into subsets that are appropriate for given healthcare venues and for given types of health IT used in these venues. This should become a task of the USCDI Task Force of the HITAC, which can consider and develop recommendations as it considers the future state curation of the USCDI.