By Hans Buitendijk (Oracle) Ex Officio Member, EHRA Executive Committee

As USCDI and USCDI+ expand, we see an increase in ambiguities in their data definitions that are creating increased challenges for programs and health IT required to support USCDI as intended. It’s of particular concern for certified health IT developers, as the ambiguity gap raises questions about what support is actually required, as HL7 FHIR US Core and HL7 CDA C-CDA specifications are used to certify to supporting USCDI.

The lack of clarity carries multiple risks, starting with complicating the update process to HL7 FHIR US Core and HL7 CDA C-CDA implementation guides, as well as the potential for missed expectations when USCDI can be interpreted to cover more than what these guides actually address. It ultimately decreases the effectiveness of standards-based interoperability that is based on clear expectations about what data is available for access and exchange, and that is aligned with ONC’s stated prioritization criteria.

To initiate deeper conversations regarding our members’ concerns about USCDI modeling, the EHR Association recently reached out to ONC, urging it to take steps to reduce ambiguity regarding the intended scope of USCDI data classes and elements. Doing so would provide clarity for standards developers to address gaps necessary to support the next standard and/or implementation guide version and for the industry to better understand available standards-based interoperability without having to understand all the details of the enabling standards and implementation guides.

Ambiguity Examples and Enhancements

In our letter to ONC, we provided several examples of ambiguity. One relates to the substantially different interpretations of whether Medication Administration is included or excluded from the USCDI scope. We learned that when considering each data class on its own, Medication Administration and its key data would not be covered but when combining multiple data classes one actually could consider its key data elements to be covered. 

According to a USCDI author, one could consider the combination of USCDI Medication and USCDI Procedure to indicate that Medication Administration is covered.  However, such an interpretation is very different from one used in interoperability, where Medication Administration is not considered a Procedure and those terms are used for different concepts. For example, HL7 v2, HL7 CDA C-CDA, and HL7 FHIR consider these two separate and distinct data classes. Because documentation does not clarify USCDI’s intent, and only as of USCDI v4 by way of an example, standards developers are forced to spend excessive time attempting to interpret and identify the appropriate scope and boundaries. 

Another scenario concerns USCDI data classes that, while defined, can’t exist on their own. For example, “facility information” has limited or no meaning without knowing the context in which a facility may be relevant and its level of detail. However, USCDI includes no indication of facility relevancy. In fact, if the definition is taken literally, it is only a listing of facilities. In the context of potential interpretations that require combining data classes to understand intent, it would not be clear which data class(es) it should be associated with.

Further, data classes relevant to various workflow concepts (e.g., order entry, referral requests, and results reporting) do not clearly indicate which aspect of the workflow the data class is meant to represent. There are distinct but similarly named data requirements whether one is ordering a laboratory test, medication, or procedure versus resulting. Data critical to the definition of the test, medication, or procedure is relevant, but ordering information is different than the recording of the actual results, administration, or performance. Understanding these differences is critical to understanding what constructs to include in HL7 FHIR US Core and HL7 CDA C-CDA, even if only currently used in query context.

There are also numerous data elements with a general ambiguity in the overall intended scope and definition, which leaves far too much room for variable interpretations and applications. The most obvious example of this is the Health Status Assessments data class, which includes elements such as Functional Status, Disability Status, Mental/Cognitive Status, Alcohol Use, Substance Use, and Physical Activity – all of which are substantially under-defined. All the named elements cite LOINC as a vocabulary standard but lack any specificity on distinct assessments or instruments around which the industry should coalesce for representing and exchanging the data. This leads to inconsistency in real-world application, watering down the value and purposes of standardizing these concepts for exchange in the first place.

Along with citing other examples of ambiguity, in our letter we share several enhancements we believe will address the current lack of clarity. These include:

• Utilizing multiple tools to decrease ambiguity. 
• Providing more specific vocabulary bindings beyond a general reference to a code system.
• Repositioning the links to the submission and adding further clarifications, reducing unintended interpretations beyond the actual definition.
• Expressing the perspective and scope of the data class explicitly. 

More Discussion is Warranted

As USCDI and USCDI+ advance to encompass electronic health information (EHI), standards-based interoperability will be enabled for all EHI. With the addition of new data elements in future versions, ambiguities will continue to hinder the interpretation and alignment of expectations regarding what can be reasonably advanced in a 12 to 24-month cycle, a key tenant of ONC’s prioritization criteria.

The EHR Association welcomes the opportunity to discuss our concerns with ONC and other stakeholders. Achieving clarity around USCDI data classes will improve the effectiveness of standards-based interoperability and eliminate the conflicts that threaten to impose a heavy burden on health IT and standards developers, as well as the healthcare providers they serve.

The EHR Association’s full letter to ONC can be accessed here.