USCDI & US Core
USCDI names the data the US must be able to exchange; US Core says how to represent it in FHIR. How the two versions track each other, and how certification pins them down.
In one line
USCDI is a policy list of what data must move. US Core is the FHIR implementation guide for how to represent it. One is a government artefact, the other an HL7 standard, and you need both to build anything that talks to a certified US EHR.
USCDI: data classes and data elements
The United States Core Data for Interoperability is a standardized set of health data classes and their constituent data elements for nationwide interoperable exchange.
- A data class is an aggregation of related data elements around a common theme or clinical use case — Problems, Medications, Laboratory, Patient Demographics.
- A data element is a single defined piece of data within a class — "Problems" contains a date of diagnosis, a date of resolution, and so on.
ASTP/ONC publishes a new version roughly annually through an open, comment-driven process where anyone can submit a candidate element and watch it move through levels of maturity:
| Version | Published |
|---|---|
| USCDI v1 | July 2020 |
| USCDI v2 | July 2021 |
| USCDI v3 | October 2022 |
| USCDI v4 | October 2023 |
| USCDI v5 | July 2024 |
| USCDI v6 | July 2025 |
There is also a USCDI v3.1 errata release and a draft v7 published in January 2026. Publication is not adoption: a version only bites when a regulation names it.
Note the deliberate trajectory. v1 was essentially the old Common Clinical Data Set. Later versions push into areas that expose gaps in most EHRs: social determinants, health status assessments, patient characteristics for equity analysis, and more granular encounter, facility and provenance information.
What is actually required
USCDI v3 is the certification baseline for the ONC Health IT Certification Program as of 1 January 2026, adopted by the HTI-1 final rule. Everything past v3 is published and usable — often through the Standards Version Advancement Process — but not the floor.
Separately, CMS-9115-F (the payer rule) pinned payer clinical data exchange to USCDI v1, and CMS-0057-F carries that lineage forward. So on a single project you can legitimately have an EHR obligated to v3 and a payer obligated to v1. That mismatch is not a bug in your reading; it is the actual state of the regulations. Confirm which rule binds each party.
US Core: the FHIR side
US Core is HL7's US Realm implementation guide over FHIR R4. It defines the profiles, value sets, search parameters and server capability statements that make USCDI concrete:
- Profiles —
us-core-patient,us-core-condition-problems-health-concerns,us-core-observation-lab,us-core-medicationrequest, and dozens more. Each constrains a base FHIR resource: which elements aremust support, which are required, which terminology binding applies. - Terminology bindings — this is where SNOMED CT, LOINC, RxNorm, ICD-10-CM, CVX and UCUM actually enter the picture. USCDI says "Laboratory"; US Core says the result must be LOINC-coded with a UCUM unit.
- Search and capability requirements — the guide states exactly which searches a server must support, which is what makes a third-party app portable across vendors.
US Core is versioned annually to track USCDI. Version 6.1.0 is aligned to USCDI v3, and the 8.0.x series carries the USCDI v5 data classes and elements. Version 9 is in development. Every published version ships a USCDI mapping page that lists, class by class, which profile and element satisfies it — that page is the fastest way to answer "where does this data element live in FHIR?"
How certification ties the knot
The connection runs through one certification criterion: § 170.315(g)(10), the standardized API for patient and population services.
HTI-1 adopted US Core 6.1.0 at § 170.215(b)(1)(ii), and made SMART App Launch v2 the only usable version in the program from 1 January 2026 (v1 remained available through 31 December 2025). So a certified EHR in 2026 gives you, without a bespoke contract:
- a FHIR R4 endpoint,
- US Core profiles over USCDI v3 data,
- SMART v2 app launch and scopes,
- plus bulk export for population-level access.
That stack is the entire reason a SMART app written against one vendor has any chance of running against another.
Working with it
Three habits save time:
Start from the USCDI mapping page, not the resource. You will be handed requirements in USCDI language ("we need Assessment and Plan of Treatment") and have to find the FHIR home. The mapping table answers that in seconds; guessing at resources does not.
Read must support, not required. US Core's must support flag means a server has to
be able to populate the element if it has the data, and a client has to be able to process it.
It is not the same as FHIR cardinality. Most integration surprises live here.
Check the version in the CapabilityStatement. Ask a server what it declares rather than assuming. Vendors run different US Core versions in different regions and tenants, and a profile that exists in 8.0.0 may not exist in the 6.1.0 endpoint you were pointed at.
If you have worked with India's NRCeS profiles, the mental model transfers exactly: a national body names the data, an HL7 realm guide constrains FHIR to carry it, and certification makes it real. Only the terminology bindings and the regulator's name change.