USCDI Explained: Data Classes, v3, and FHIR

USCDI (the United States Core Data for Interoperability) is a standardized set of health data classes and data elements that certified health IT systems in the US must be able to exchange. Where standards like HL7 and FHIR define how health data moves between systems, USCDI defines what data must move: the specific data classes (patient demographics, laboratory results, clinical notes, medications, allergies, and more) and the individual data elements within them that every certified system is required to support. USCDI is the content standard that sits alongside the transport standards, and together they make interoperable health data exchange work in practice.

USCDI matters to any organization that exchanges health data, including imaging providers, because it is not optional. It is mandated by federal regulation: the certification criteria that health IT products must meet and the information-blocking provisions of the 21st Century Cures Act both reference USCDI as the baseline data set. The version currently mandated as the certification baseline is USCDI v3, established under the HTI-1 final rule effective January 1, 2026. This guide explains what USCDI is, how its data classes and elements are structured, what USCDI v3 added and where the version progression is heading, how USCDI relates to FHIR, and what it means for medical imaging specifically.

It is written for healthcare IT teams, interoperability leads, and imaging providers working to understand their obligations under the current interoperability rules. For the broader picture of how clinical systems exchange data, see the Medicai guides to the difference between EMR and EHR and what HL7 is.

What USCDI Stands For and What It Defines

USCDI stands for the United States Core Data for Interoperability. It is structured as a set of data classes, each containing individual data elements. A USCDI data class is a category of health information (such as “Medications” or “Laboratory”), and the USCDI data elements are the specific pieces of information within that class (such as the medication name or a specific lab test result and its value). The standard specifies which data classes and elements a certified health IT system must be capable of exchanging, which creates a common baseline so that when one system sends data to another, both support the same core set.

The purpose of defining this common set is to address the problem that made early health data exchange unreliable: two systems could both claim interoperability while supporting different data, so information sent by one system arrived incomplete or unusable at the other. By specifying the minimum data classes and elements every certified system must support, USCDI raises the floor. It does not limit what systems can exchange beyond the core set; it guarantees the core set is universally supported. That is the difference between being able to send data and being able to use the data that arrives.

The data classes in USCDI cover the core of a patient record: patient demographics, allergies and intolerances, clinical notes, laboratory results, medications, immunizations, problems, procedures, vital signs, care team members, and more. Each successive version has expanded both the number of data classes and the elements within them, as the standard is designed to grow over time.

USCDI v3: The Current Mandated Version

USCDI is not a static standard. It expands over time through an open process managed by the Assistant Secretary for Technology Policy and the Office of the National Coordinator (ASTP/ONC), incorporating input from healthcare stakeholders. Because the applicable version is set by regulation, it is worth understanding both the currently mandated version and the progression leading up to it.

USCDI v1 established the foundational data classes and elements in 2020 through the ONC Cures Act Final Rule, covering the core of the patient record: allergies, clinical notes, medications, laboratory results, and the other baseline classes.

USCDI v2 and USCDI v3 expanded the standard considerably. v2 added elements including health insurance information and additional clinical data, and USCDI v3 added further data elements including expanded social determinants of health, health status, and care team information. USCDI v3 is the version currently mandated as the baseline: under the HTI-1 final rule, USCDI v3 became the required standard for certified health IT effective January 1, 2026, replacing v1 as the certification baseline. For most organizations, the answer to which version applies today is USCDI v3.

USCDI v4 and later continue the progression. USCDI v4 has been finalized, adding additional data elements, and later versions (v5, v6, and a draft v7) are at various stages of development and comment. Because the standard advances continuously while the mandated version is set by regulation, there is a gap between the latest published version and the version currently required for certification. As of the HTI-1 final rule, v3 is the mandated baseline, even though later versions exist in either finalized or draft form. Organizations should track both the current mandated version (for compliance) and the forthcoming versions (for planning), since the mandated baseline advances on the regulatory timeline rather than immediately upon each new version’s publication.

USCDI vs FHIR: What Each Standard Does

USCDI and FHIR are frequently mentioned together and sometimes confused, but they solve different parts of the interoperability problem. The short version: FHIR defines how data is exchanged, and USCDI defines what data is exchanged.

FHIR (Fast Healthcare Interoperability Resources) is the transport and format standard developed by HL7. It concerns the technical mechanics of exchange: how data is structured into resources, how those resources are transmitted through APIs, and how systems request and receive them. FHIR addresses how health data should be formatted and exchanged between systems.

USCDI is the content standard. It concerns what data must be exchanged: which data classes and elements a certified system must support. USCDI answers the question of what specific health information must be included when systems exchange data.

The two work together. FHIR provides the framework and protocols for structuring and transmitting health data, and USCDI defines the specific data that must be included in those exchanges. USCDI is designed to align with FHIR, and the data elements USCDI specifies are exchanged using FHIR resources in modern certified health IT. A useful way to hold the distinction: FHIR is the envelope and the postal system, and USCDI is the required contents of the letter. A system can implement FHIR correctly but still fail to exchange the data USCDI requires, and it can support all the USCDI data classes but needs FHIR to actually move them. Both are required for interoperable exchange under the current rules, which is why they are almost always discussed together. For the difference between the older and newer transport standards, see the Medicai guide to HL7 and how it connects radiology to the rest of the hospital.

What USCDI Means for Medical Imaging

USCDI is a general health data standard rather than an imaging-specific one, but it matters to imaging providers for a specific reason: imaging does not occur in isolation from the rest of the patient record. An imaging provider that exchanges data with EHRs, health information exchanges, and referring organizations operates within the interoperability framework defined by USCDI, and the imaging-adjacent data (the orders that generate imaging, the clinical context that informs interpretation, the reports that flow back to the record) travels through the USCDI-and-FHIR exchange infrastructure.

The imaging pixel data itself travels by the DICOM standard rather than USCDI, and that distinction matters: USCDI does not replace DICOM for the images. But the clinical data surrounding imaging (the orders, results, clinical notes, and structured data that connect an imaging study to the rest of the patient record) falls within the USCDI framework. An imaging platform that integrates with the broader healthcare enterprise through FHIR APIs participates in the exchange governed by USCDI, and its ability to send and receive USCDI data classes cleanly determines how well imaging integrates with the clinical record.

This is why cloud-native imaging platforms emphasize FHIR-based, API-first integration: it is what connects imaging to the USCDI-governed data exchange the rest of the healthcare system runs on. Medicai’s cloud imaging platform connects to EHR systems including Epic, athenahealth, and AdvancedMD through FHIR, embedding imaging access directly within the EHR interface, and implements the standards-based pathways that carry imaging into the clinical record: DICOMweb (WADO-RS for image retrieval, QIDO-RS for study queries, STOW-RS for image storage) for the images themselves, and HL7 v2 ORU messages and FHIR DiagnosticReport and ImagingStudy resources for the imaging reports and metadata that populate the USCDI-governed clinical record. The images stay in DICOM, but the connection to the clinical record runs through the same FHIR framework that carries USCDI data. For how that imaging-to-EHR integration works in practice, see the Medicai guide to medical imaging EHR integrations, and for the systems that exchange imaging-adjacent clinical data, the EMR vs EHR guide.

Frequently Asked Questions