The Balance Challenge for Policy in Progressing the U.S. Core Data for Interoperability (USCDI)

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


With publication of the 21st Century Cures Act: Interoperability, Information Blocking , and ONC’s Certified Health IT program final rule (Cures Act Final Rule), the Office of the National Coordinator for Health IT (ONC) worked to implement important provisions of the 21st Century Cures Act (Cures Act) for nationwide interoperability. The initial proposal from ONC addressing the Trusted Exchange Framework and Cooperative Agreement (TEFCA), which was also required by the Cures Act, created a central role for the U.S. Core Data for Interoperability (USCDI) in federal health IT policy, and it is important to consider what that role will be in the national policy framework. Will the USCDI push the industry beyond where it would go on its own by being progressive in its version expansion? Will it affirm and codify an extension of the current state, adhering to a principle of expansion based on supporting pre-requisites of already established interoperability standards? Or something in between?

In recent deliberations of the USCDI Task Force of the Health Information Technology Advisory Committee (HITAC), the Federal Advisory Committee established under the Cures Act, this tension point has come to light. The members of the task force seem to have two perspectives on the matter. 

On one hand, there are those who advocate for an assertive role for the USCDI to push the industry forward by elevating high priority data elements and concepts to advance policy goals of the federal government. Examples shared by task force members included progress towards greater health equity through inclusion of data associated with social determinants of health and providing context for quality measures, public health reporting and other important priorities.  

On the other hand, there are those who prioritize expansion where there are well-established interoperability standards and strong, market-based use cases backed by proven production use of said standards. Neither perspective is wrong; however, considering how the USCDI version is referenced through federal rulemaking, the appropriate role of USCDI curation is an important matter for consideration, especially regarding the full weight of what version adoption means to health IT developers and their users.

It is clear that the expansion of the USCDI is something that must be done with an eyes-wide-open, cognizant understanding of the current state of support for any new data elements.

For example, the USCDI is not only an interoperability data set but also a required standard for health IT certification under the Cures Act Final Rule. The version of the USCDI that is the adopted certification standard is a de facto mandated floor for health IT developers and for healthcare providers to use. Over time, as future versions of USCDI are incorporated into certification, that floor will rise. By the time a USCDI version is adopted as a certification standard, well-used interoperability standards and specifications for every data element in the USCDI that is supported by established production use are a must. Although there is some runway for new versions of the USCDI to push the boundaries on adoption prior to becoming a certification standard, by the time any new versions are part of the basis of certification, the time for groundbreaking should be past. 

Further, as a certification standard, the USCDI is also part of the Standards Version Advancement Process (SVAP), by which health IT developers may elect to support new versions of certification standards prior to the time a new version of an existing certification standard becomes required. The SVAP allows for certified health IT developers to adopt it sooner rather than later, thereby allowing new additions to the USCDI to be proven out through production use. However, there is also the risk that health IT developers do not pursue support for a new version of the USCDI through SVAP if additions are not backed by available production-worthy standards. In fact, pushing the envelope on adding new elements to the USCDI could result in health IT developers being risk-averse to adoption because of the requirements of certification and SVAP. 

We note, too, that when a developer adopts a new USCDI version through the SVAP process, it must adopt the entire scope of USCDI at that point. This underscores the importance of ensuring that the standards referenced in support of any USCDI expansion are capable and sufficiently mature to support the full USCDI (for both the vocabulary standards referenced within the USCDI and the document and API standards that support them).

Third, as a part of SVAP, the USCDI is also part of what must be proved by developers of certified health IT in compliance with new Real World Testing (RWT) requirements from ONC. When a health IT developer voluntarily elects to support a new version of an interoperability standard through SVAP, the developer also must prove out their support of such a new version through RWT. This can be substantiated either through demonstration of production experience or an acceptable simulation of production use for one full year prior to required reporting dates established by ONC. It requires proof of support through measurement. 

It’s important to note that this RWT requires that any expansion of the USCDI considers realistic timelines for incorporation of new data elements and their interoperability requirements. If this is not done, any future expansion of the USCDI risks becoming self-defeating by deflating the adoption prospects by health IT developers who will be concerned about the need to “prove it” each time. 

It is clear that the expansion of the USCDI is something that must be done with an eyes-wide-open, cognizant understanding of the current state of support for any new data elements. While it may not be an absolute must to establish a hard prerequisite for adopted interoperability standards to be in use before a new data element is incorporated into the next USCDI version, there are questions to ask.  Are health IT developers able to offer production support? Is the use of new data elements supported by capture through workflow? These must be part of the calculation for ONC and its advisory committee process before making a recommendation. Similar factors should also inform where ONC goes in its relationships with Standards Development Organizations (SDOs) like HL7 as it presses for development and progression of needed interoperability standards. Otherwise, important public policy goals and objectives risk being frustrated by a disconnect with the ability of health IT infrastructure in the United States to fully incorporate new data standards. It is an important part of being a responsible steward that the federal advisory process be informed by this perspective.

Leave a comment

1 Comment

  1. The USCDI Curation Process: Why Stratify? | EHRA Blog

Share your thoughts on this topic!

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  • Categories

  • Follow EHRA on Twitter

  • Enter your email address to follow this blog and receive notifications of new posts by email.

    Join 178 other subscribers
  • Contact Us

    Kasey Nicholoff
    staff @

    Amanda Patanow
    Communications and Media
    ehracomms @
%d bloggers like this: