Speaker 1: Hello, and welcome to 5 Minutes of Interoperability. My name is John Damore, and today we'll be speaking about U.S. CDI, otherwise known as U.S. Core Data for Interoperability. So let's get started. To set the stage for U.S. CDI, we have to talk a little bit about the certification of EHRs, or Electronic Health Records, in the United States. This dates back to 2009 and the American Recovery and Reinvestment Act. As part of that legislation, there was a program known as Meaningful Use that set aside approximately $40 billion for the adoption of EHRs over the coming years. That Meaningful Use program was administered by the Office of the National Coordinator for Health IT, or ONC, now known as the Assistant Secretary for Technology Policy. As part of that program, they originally had some minimum data requirements. Those were known as the Common Clinical Dataset. That eventually evolved into the data classes, elements, and terminologies in U.S. CDI. What U.S. CDI does is it specifies the data that is expected to be able to be recorded and also sent in an interoperable format out of Electronic Health Records. U.S. CDI is not a standard onto itself, but is really a listing of data expectations. The way that U.S. CDI is executed in standards is by using the two primary product families of HL7 of CDA and FHIR, or FHIR. We have separate videos about FHIR and CCDA, which we'll link from this video. Looking at that definition a little bit more, data are required to be supported by Electronic Health Records as part of certification. That expectation is that this information is routinely recorded in CARE and can be sent to other providers through interoperable exchange. U.S. CDI is a standardized set of health data classes and constituent data elements for nationwide interoperability. Data classes are an aggregate of various data elements that are a common theme, and we'll look at one example on a coming slide. U.S. CDI data elements are the most granular level at which a piece of data is represented and generally includes a simple definition of that data element so that it can be understood by both vendors and providers of healthcare. Here's one example of a definition and its terminology in U.S. CDI. Here we have the data class of procedures, and you can see multiple data elements such as procedures, performance time, social determinants of health, or SDOH interventions, and also reason for referral. Underneath each data element, we can see its definition. And then on the right-hand side, we can see whether that element requires certain terminologies to be used as part of the program. For example, with procedures, we can see that the definition is any activity performed on or for a patient as part of the provision of care. And the applicable vocabulary or terminology standards include the systemized nomenclature of medicine, such as SNOMED, the current procedural terminology, CPT, the Healthcare Common Procedural Coding System, HCPCS, and the Code on Dental Procedures and Nomenclature, known as CDT. In addition to these vocabularies, ICD-10, or International Classification of Diseases Procedure Coding System, may also be used. As you can see along the tabs on the top, here we're looking at the fifth edition, or U.S. CDI V5. This has evolved annually over the past five years and will continue to evolve in the future. The lifecycle of a U.S. CDI version is composed of the following steps. First, a new draft of the U.S. CDI is released, publicly and available for comment. Interested parties, as well as anyone in the public, can provide comments and feedback on U.S. CDI. Then that version of U.S. CDI becomes a final version. Over time, those final versions of U.S. CDI become integrated into HL7 standards, such as FHIR and CCDA. After being adopted into those standards, it is then also placed in the certification programs administered by independent testing bodies for EHR certification. Then, in several years, it actually may become a requirement for EHRs to be able to move up to that current version of U.S. CDI. While only the first version of U.S. CDI is currently required by EHRs today, it is expected in the coming years that they will be forced to upgrade to more recent versions of the U.S. CDI. As mentioned earlier, U.S. CDI is not a standard in itself. To have an implementable standard for the U.S. CDI data requirements, two different implementation guides are updated on an annual basis by HL7 to include the new specifications for U.S. CDI. These include the Consolidated Clinical Document Architecture, known as CCDA, that builds on the product family of HL7 CDA. You can see the link for this on the left. And then also on the right, the U.S. Core Implementation Guide, which is also known as U.S. Core FHIR, which builds off of the HL7 primary standard family of FHIR, or Fast Healthcare Interoperability Resources. Where do you go if you want to learn more about U.S. CDI or the specific standards that make it implementable? Well, first, you can browse U.S. CDI publicly and available online at the following web link on HealthIT.gov. In addition, you can go ahead and look at the key laws and regulations, such as the 21st Century Cures Act and also the Health, Data, and Interoperability, or HDI, regulations. These are the ones that require U.S. CDI implementation. You can also look for the details of certification as outlined by those independent testing bodies and maintained by ASTP. And you can also head to presentations and webinars hosted by ASTP, ONC, and HL7 and other key vendors. In the description of this video, we'll link to both the explanations of the CCDA Implementation Guide and also the FHIR U.S. Core Implementation Guide for more information. Thank you so much for your time and attention. I hope you've learned a little bit about U.S. CDI today and also how regulations can work with standards to make information more interoperable and accessible for patients nationwide.