Interoperability sounds like an engineering concern, but for a practice choosing or switching an EHR it comes down to a plain question: when your system sends a patient's record to another system, what exactly travels? The answer is increasingly governed by the United States Core Data for Interoperability, or USCDI, a standardized set of health data classes and elements that certified health IT is expected to be able to exchange. USCDI is the common vocabulary that lets two different systems agree on what a "problem list" or an "allergy" is, so the data means the same thing on both ends.
What USCDI is
USCDI is maintained by the federal health-IT office (the Assistant Secretary for Technology Policy / Office of the National Coordinator, ASTP/ONC). It defines a baseline of health data that systems should exchange to support care and interoperability. Think of it as the agreed-upon minimum contents of a shared record: not every field any EHR could possibly store, but the core classes that everyone should be able to send and receive reliably.
Data classes and data elements
USCDI is organized as data classes that each contain data elements. A data class is a category; a data element is a specific piece of information within it.
| Example data class | Example data elements |
|---|---|
| Allergies and Intolerances | Substance, reaction |
| Medications | Medication, dose |
| Problems | Problem or diagnosis with a coded value |
| Laboratory | Test, values/results, specimen type |
| Patient Demographics | Name, address, preferred language |
| Clinical Notes | Consultation note, discharge summary, progress note |
Successive versions of USCDI add classes and elements over time, which is why the version number is not a trivia detail, it defines how much of the record can travel in a standardized way.
How it connects to FHIR and US Core
USCDI says what data should be exchanged. It does not, by itself, say how to format it on the wire. That job falls to standards like HL7 FHIR and, specifically, the US Core implementation guide, which maps USCDI data classes onto concrete FHIR resources so a developer knows exactly how to represent an allergy or a lab result. In shorthand: USCDI is the content list, FHIR is the transport and format, and US Core is the bridge that ties a USCDI element to a FHIR resource. A buyer does not need to write any of it, but knowing the three fit together explains why "we support FHIR" and "we support the current USCDI" are related but not identical claims.
Certification and why the version matters
Under the ONC Health IT Certification Program, certified health IT is expected to support USCDI as part of its certification criteria, and the program has moved from the older Common Clinical Data Set to USCDI and through successive USCDI versions. For a practice, the practical implication is about the version your product supports: a system aligned to a newer USCDI version can exchange more standardized data classes than one stuck on an older baseline. When information-blocking obligations push toward sharing electronic health information on request, the breadth of what your system can package in a standard format becomes an operational advantage, not just a compliance checkbox.
Questions a buyer should ask
- Which USCDI version does your certified product support today, and what is your timeline for the next one?
- Which USCDI data classes can we actually export and import in a standardized format, not just view on screen?
- Do you expose a standards-based FHIR API aligned to the US Core implementation guide?
- When we send a record to another system, which classes travel as coded data versus free text?
Interoperability failures rarely announce themselves at the demo. They show up the first time you try to move a real patient's record to another system and half of it arrives as an unstructured blob. Asking about USCDI versions and data classes up front is how you find out before the switch, not after.
Common questions
What is USCDI?
The United States Core Data for Interoperability (USCDI) is a standardized set of health data classes and data elements that certified health IT is expected to be able to exchange. Maintained by the federal health-IT office (ASTP/ONC), it acts as a common vocabulary so different systems agree on what core record items mean.
What is the difference between a USCDI data class and a data element?
A data class is a category of health information, such as Allergies and Intolerances or Medications, while a data element is a specific piece of information within that class, such as the substance and reaction for an allergy. USCDI is organized as classes containing elements, and newer versions add more of both.
How does USCDI relate to FHIR and US Core?
USCDI defines what data should be exchanged; HL7 FHIR defines how to format and transport it; and the US Core implementation guide maps USCDI data classes onto specific FHIR resources. USCDI is the content list, FHIR is the format, and US Core is the bridge between them.
Why does the USCDI version my EHR supports matter?
Each newer USCDI version adds data classes and elements, so a system aligned to a newer version can exchange more of the record in a standardized format. That breadth matters for interoperability and for meeting requests to share electronic health information, making the supported version a real buying consideration.