USCDI (United States Core Data for Interoperability)

regulatory framework regulatory compliancefhirinteroperabilityhealthcare

Acronym for: United States Core Data for Interoperability

Source: ONC System: https://www.healthit.gov/uscdi Code: USCDI Reviewed: 28/01/2026 License: CC-BY-4.0

USCDI (United States Core Data for Interoperability)

One-sentence definition: USCDI is the ONC-maintained policy standard that specifies which health data classes and data elements — clinical notes, laboratory results, medications, vital signs, and others — every federally certified EHR must support for nationwide interoperable exchange.

Full Definition

USCDI defines the minimum set of health data elements that must be exchangeable across certified health IT systems in the United States. It is organized into Data Classes (broad categories like “Medications” or “Clinical Notes”) and Data Elements within each class (specific items like “Medication Instructions” or “Consultation Note”). ONC publishes USCDI and updates it on an annual versioning cycle.

USCDI is a policy standard, not a technical one. It specifies what data must be supported but not how it is represented or exchanged. The technical implementation is delegated to HL7’s US Core Implementation Guide, which maps each USCDI data element to specific FHIR resources and profiles. The relationship is: USCDI defines the requirement; US Core provides the FHIR-based mechanism to fulfill it.

USCDI v1 was published in 2020 and incorporated into ONC’s certification criteria for certified health IT. Each subsequent version expands the required data set: v2 (2022), v3 (2023), and v4 (2024) each added data classes and elements reflecting evolving clinical priorities and policy goals.

For how USCDI versions map to US Core profiles, which data elements each version requires, and how ONC certification and USCDI adoption timelines interact — see the canonical reference → ONC, Cures Act, and Information Blocking.

Context and Usage

Where This Term Appears

USCDI appears in:

  • ONC certification criteria — certified EHRs must support the USCDI version referenced in the applicable certification edition
  • Implementation guide scope statements — US Core IGs specify which USCDI version they implement
  • Regulatory filings — CMS and ONC rules cite specific USCDI versions as required data sets for payer and provider FHIR APIs
  • Interoperability contracts — health system and payer agreements may specify which USCDI version a FHIR API must support
  • Product roadmaps — EHR vendors publish their USCDI version certification status on ONC’s CHPL (Certified Health IT Product List)

Common Usage Examples

In conversation: “We’re certified for USCDI v3 — the sexual orientation and gender identity elements were the tricky part to map.”

In documentation: “All patient-facing FHIR endpoints must return data conformant with USCDI v3 as required by the 2024 certification criterion.”

In technical contexts: An integrator checking ONC’s CHPL to confirm which USCDI version a partner EHR supports before designing a FHIR data exchange.

Why USCDI Exists

Before USCDI, the minimum data set for interoperability was scattered across certification criteria, Meaningful Use requirements, and individual HL7 standards with no coherent policy definition of what “the core patient record” includes. Different systems supported different subsets; there was no single authoritative list of what data must travel in a nationwide exchange.

ONC created USCDI to provide that single authoritative list. By defining a standardized, versioned data set that every certified EHR must support, USCDI creates a predictable floor: any two ONC-certified systems can exchange the USCDI elements, regardless of which vendor built them or which health system deployed them.

USCDI Structure and Data Classes

Data Classes and Elements

USCDI organizes health data into Data Classes, each containing one or more Data Elements. As of v3, the classes include: Allergies and Intolerances, Care Team Members, Clinical Notes, Diagnostic Imaging, Encounter Information, Goals, Health Insurance Information, Immunizations, Laboratory, Medications, Patient Demographics/Information, Problems, Procedures, Provenance, Smoking Status, Unique Device Identifier(s), Vital Signs, Clinical Tests, Sexual Orientation and Gender Identity, and Pregnancy Status.

Each Data Element specifies what must be supported — but not necessarily transmitted in every exchange. “Must support” in USCDI means the system must be capable of storing, retrieving, and exchanging the element when it is present in the source data.

Version Evolution

  • v1 (2020): 12 data classes, ~50 data elements. The baseline required for initial Cures Act certification. Covers demographics, clinical notes, medications, allergies, problems, procedures, lab results, vital signs, smoking status, and provenance.
  • v2 (2022): Added 2 data classes and several elements, including care team member information and health insurance information.
  • v3 (2023): Major expansion — added Clinical Tests, Encounter Information, Unique Device Identifiers, Sexual Orientation and Gender Identity, Pregnancy Status, and Diagnostic Imaging.
  • v4 (2024): Further additions including care experience preferences, functional status, mental/cognitive status, and additional clinical note types.

ONC operates a USCDI+ mechanism that allows federal programs (like CDC or VA) to define extensions to USCDI for program-specific data needs, without requiring those elements to be included in the base standard for all certifications.

USCDI and FHIR

US Core Implementation Guide

US Core is the HL7 FHIR Implementation Guide that translates USCDI requirements into FHIR profiles. Each USCDI data element maps to one or more FHIR resource elements in the corresponding US Core profile. When ONC updates USCDI, HL7 updates US Core to match. The two standards are tightly coupled: USCDI defines the policy; US Core provides the technical implementation.

Mapping to FHIR Resources

USCDI data elements map to FHIR resources across the clinical domain: Laboratory data maps to Observation and DiagnosticReport; Medications to MedicationRequest and MedicationStatement; Clinical Notes to DocumentReference; Encounter Information to Encounter; Vital Signs to Observation with specific LOINC codes. The US Core IG documentation provides the definitive element-to-profile mapping for each USCDI version.

Relationship to Other Terms

  • ONC — the agency that publishes, maintains, and enforces USCDI through the certification program
  • 21st Century Cures Act — the law that directed ONC to develop and maintain USCDI
  • FHIR — the technical standard through which USCDI data is exchanged via US Core profiles
  • Information Blocking — USCDI elements must not be blocked by covered actors

Contrasting Terms

  • USCDI vs EHI: USCDI defines a specific enumerated data set; EHI (Electronic Health Information) for information blocking purposes is broader — it includes all electronic protected health information in a Designated Record Set. An organization cannot refuse to share EHI that falls outside USCDI.

  • USCDI vs US Core: USCDI is the policy standard (what data elements are required). US Core is the technical implementation standard (how those elements are represented in FHIR). US Core implements USCDI; they are not interchangeable terms.

Common Misconceptions

Misconception 1: USCDI is a Technical Standard

  • Incorrect belief: USCDI defines FHIR profiles, data formats, or API specifications that systems must implement.
  • Reality: USCDI is a policy document that lists required data classes and elements in plain language. It deliberately avoids specifying implementation technology. The technical implementation is delegated to HL7’s US Core IG, which maps USCDI to FHIR resources and profiles.
  • Why it matters: Integrators looking for FHIR profile definitions should consult US Core, not USCDI. USCDI tells you what data must be there; US Core tells you how it must be structured.

Misconception 2: USCDI Defines APIs

  • Incorrect belief: USCDI specifies the API endpoints, authentication methods, or technical protocols that systems must expose.
  • Reality: USCDI says nothing about APIs. API requirements — FHIR R4, SMART on FHIR authorization, specific endpoints, capability statement requirements — come from ONC’s certification criteria (45 CFR Part 170), not USCDI itself. USCDI defines the data payload; the certification criteria define how it must be delivered.
  • Why it matters: A health system reviewing API requirements needs to read both the ONC certification criteria (for technical API specifications) and US Core (for data structure) in addition to USCDI. USCDI alone is not sufficient to understand what a compliant API looks like.

Why USCDI Matters

USCDI is the policy anchor for US health data interoperability. It creates a predictable, versioned, authoritative list of what data a certified EHR must handle — eliminating the guesswork about what “interoperable” means in practice. For integrators, USCDI defines the scope of what they can rely on receiving from a certified EHR. For vendors, it defines the minimum data set they must support to maintain certification. For patients, it defines what data they can expect to access through a patient-facing API.

The version trajectory also matters: as USCDI expands with each release, the floor for interoperability rises. Data elements that were discretionary in 2020 are mandatory by 2024 — and the regulatory mechanism ensuring compliance is ONC certification.

Cross-References

  • ONC — the agency that publishes and maintains USCDI
  • 21st Century Cures Act — the law that mandated USCDI development
  • FHIR — the technical standard used to exchange USCDI data via US Core profiles
  • Information Blocking — USCDI data elements fall within the scope of EHI subject to information blocking prohibitions

Last reviewed: January 28, 2026 Definition authority: ONC Content status: Canonical reference