Taction Software®
Healthcare IT Glossary

What is USCDI?
US Core Data for Interoperability

Interoperability only works when both sides agree on what data to exchange. You can build the most elegant FHIR API in the world, but if the sending system includes medication data and the receiving system only expects lab results, nothing useful happens. USCDI solves this by defining exactly which data classes and elements every certified health IT system must be able to send and receive — creating a common baseline for the entire U.S. healthcare ecosystem.

Certifications

Tell Us Your Requirements

Our experts are ready to understand your business goals.

What is 1 + 1 ?

100% confidential & no spam

Definition of USCDIHow USCDI Works in HealthcareKey USCDI Standards and SpecificationsImplementation ConsiderationsHow Taction Helps with USCDI

Definition of USCDI

USCDI, which stands for United States Core Data for Interoperability, is a standardized set of health data classes and data elements required for nationwide interoperability. It defines the minimum data that certified health IT systems must be able to exchange — establishing a common denominator that ensures every compliant system can share and consume the same core patient information.

USCDI is developed and maintained by the Office of the National Coordinator for Health IT (ONC) as part of its mandate under the 21st Century Cures Act. It is not a messaging standard or an API specification — it is a data content standard that defines what must be exchangeable. The how is handled by standards like FHIR, C-CDA, and HL7v2.

USCDI is versioned and evolves over time. Each new version adds data classes and elements based on stakeholder input, clinical need, and technical feasibility:

USCDI v1 (2020) — The initial version, establishing core data classes: Patient Demographics, Allergies and Intolerances, Medications, Conditions (Problems), Procedures, Laboratory Results, Vital Signs, Immunizations, Clinical Notes, Provenance, and Unique Device Identifiers.

USCDI v2 (2022) — Added Health Insurance Information, Clinical Tests (non-lab), and additional note types.

USCDI v3 (2024) — Added Functional Status, Disability Status, Mental/Cognitive Status, Social Determinants of Health (SDoH) assessment data, Specimen data, and expanded Clinical Tests.

USCDI v4 (2025) — Further expanded with Emergency Contact, Treatment Intervention Preferences, and additional granularity in existing classes.

ONC also maintains the USCDI+ program — domain-specific expansions of USCDI for use cases like quality measurement, public health, and behavioral health that require data elements beyond the core set.

In simple terms: USCDI is the nationally agreed-upon answer to “what data must every health IT system be able to share?” — the content standard that makes interoperability meaningful, not just technically possible.

How USCDI Works in Healthcare

USCDI doesn’t operate on its own — it’s implemented through technical standards, certification requirements, and clinical workflows that reference it.

EHR certification
ONC’s Health IT Certification Program requires certified EHR systems to support the current USCDI version. This means every certified EHR must be able to capture, store, and exchange all data classes and elements defined in the applicable USCDI version. When ONC advances to a new USCDI version (typically through rulemaking like HTI-1 or HTI-2), EHR vendors must update their systems to support the expanded data set within the compliance timeline.
FHIR API implementation
USCDI data classes map directly to FHIR US Core profiles. The Patient data class maps to the FHIR Patient resource. Medications map to MedicationRequest and MedicationStatement. Conditions map to the Condition resource. Lab results map to Observation. Each USCDI element has a corresponding FHIR resource, profile, and search parameter — defined in the HL7 FHIR US Core Implementation Guide.
C-CDA document exchange
USCDI data classes also map to C-CDA document sections. A Continuity of Care Document (CCD) exchanged between providers must include USCDI-required sections — Allergies, Medications, Problems, Procedures, Lab Results, Vital Signs, and Immunizations. As USCDI expands, C-CDA templates are updated to accommodate new data classes.
Patient data access
Under the Cures Act, patients have the right to access their USCDI data through FHIR-based patient access APIs. Third-party applications authorized by the patient can retrieve USCDI data classes from the EHR — enabling personal health records, care management apps, and consumer health tools.
Payer interoperability
CMS rules require regulated payers to exchange USCDI data through Patient Access APIs, Provider Access APIs, and Payer-to-Payer exchange. The Da Vinci Project and CARIN Alliance develop FHIR implementation guides that operationalize USCDI for payer-specific workflows like prior authorization and coverage determination.
Quality and public health reporting
USCDI+ expansions define additional data elements needed for quality measure reporting, electronic case reporting, and public health surveillance. Organizations participating in CMS quality programs should track USCDI+ developments relevant to their reporting requirements.

Key USCDI Standards and Specifications

Legacy
USCDI Data Classes
As of USCDI v3, the standard defines the following data classes (each containing multiple specific data elements):
Legacy
USCDI and Vocabulary Standards
USCDI specifies which vocabulary standards each data element must use: SNOMED CT for problems and procedures, LOINC for lab tests and observations, ICD-10 for diagnoses on claims, RxNorm for medications, CVX for immunizations, UCUM for measurement units. Systems that store data using proprietary codes must map to these standard vocabularies for USCDI-compliant exchange.
Legacy
USCDI Expansion Process
ONC uses a public, transparent process for USCDI expansion called ONDEC (ONC New Data Element and Class) submissions. Stakeholders can submit proposals for new data classes or elements. ONC evaluates proposals through a leveling system — Level 1 (submitted), Level 2 (under consideration), and promotion to the next USCDI version. Healthcare IT teams should monitor ONDEC to anticipate future USCDI requirements.
Patient DemographicsName, date of birth, sex, race, ethnicity, preferred language, address, phone, email
Allergies and IntolerancesSubstance, reaction, severity, status
MedicationsActive medications, medication allergies, fill status
Problems (Conditions)Active diagnoses, health concerns, coded using SNOMED CT and ICD-10
ProceduresProcedures performed, coded using SNOMED CT and CPT
Laboratory ResultsTest results coded using LOINC with UCUM units
Vital SignsBlood pressure, heart rate, respiratory rate, temperature, BMI, weight, height, oxygen saturation
ImmunizationsVaccine administered, date, CVX code
Clinical NotesConsultation notes, discharge summaries, history and physical, progress notes, imaging narratives, lab reports, pathology reports, procedure notes
Health Insurance InformationCoverage type, plan name, subscriber ID, group number
Clinical TestsNon-laboratory diagnostic test results
Functional Status, Disability Status, Mental/Cognitive StatusAssessment scores and observations
Social Determinants of HealthSDoH screening results, food insecurity, housing, transportation
ProvenanceAuthor, timestamp, and source of each data element
Unique Device IdentifiersImplantable device information
Building an USCDI integration? Let’s talk.
Book a free call

Implementation Considerations

USCDI implementation spans EHR configuration, FHIR API development, vocabulary management, and data quality governance.

Gap analysis against the current version
Start by auditing your system’s current data capture capabilities against the USCDI version required by your certification or compliance timeline. Identify data classes your system doesn’t capture at all (common gaps: SDoH, functional status, disability status, health insurance information) versus data classes it captures but not in the required standardized vocabulary.
Vocabulary alignment is the hardest part
USCDI doesn’t just require that you exchange “allergies” — it requires that allergies be coded in SNOMED CT. If your system stores allergies as free text or uses proprietary codes, you need a vocabulary mapping and enrichment pipeline. This applies across all data classes — problems must be in SNOMED CT, labs in LOINC, medications in RxNorm.
FHIR US Core profile conformance
Each USCDI data class maps to specific FHIR US Core profiles with required elements, cardinality rules, and terminology bindings. Your FHIR implementation must conform to these profiles — not just return valid FHIR resources, but return resources that meet the US Core constraints. Use the HL7 FHIR Validator to test conformance.
SDoH data capture is new for most systems
USCDI v3 requires SDoH assessment data — food insecurity, housing instability, transportation access, interpersonal violence. Many EHR systems don’t have structured SDoH capture workflows. Implementing SDoH requires new screening questionnaires (using standardized instruments like AHC-HRSN), structured data storage, and FHIR Observation resources coded with LOINC SDoH panel codes.
Version migration planning
ONC advances USCDI versions through rulemaking with defined compliance timelines. Your roadmap must account for migrating from one USCDI version to the next — adding new data classes, expanding existing ones, and updating FHIR profiles and C-CDA templates. This is not a one-time implementation; it’s a recurring cycle.
Testing and validation
Use ONC-approved testing tools (Inferno, Lantern) to validate your FHIR API against US Core USCDI requirements. Testing should cover both the presence of required data elements and the correctness of vocabulary coding — a medication list coded with proprietary drug codes instead of RxNorm fails USCDI compliance even if the FHIR resource structure is valid.

How Taction Helps with USCDI

At Taction, our team helps healthcare organizations and health IT vendors build USCDI-compliant systems — from gap analysis through FHIR API development and ongoing version migration.

What we do:

Whether you’re pursuing ONC certification, building FHIR APIs for Cures Act compliance, or preparing for the next USCDI version, our healthcare interoperability team delivers the standards precision and implementation depth these requirements demand.

USCDI gap analysis
We audit your system’s data capture, storage, and exchange capabilities against the target USCDI version — identifying missing data classes, vocabulary gaps, and FHIR profile conformance issues.
FHIR US Core implementation
We build USCDI-compliant FHIR APIs that conform to US Core profiles — including Patient, Condition, Medication, Observation, Procedure, Immunization, DocumentReference, and all required USCDI data classes.
Vocabulary mapping and enrichment
We map your system’s internal codes to USCDI-required vocabularies (SNOMED CT, LOINC, RxNorm, ICD-10) and build automated enrichment pipelines that maintain mapping accuracy as vocabularies evolve.
SDoH data capture
We build structured SDoH screening and documentation workflows within EHR systems, including standardized assessment instruments and FHIR-ready data storage.
USCDI version migration
We manage the upgrade path from one USCDI version to the next — adding new data classes, updating FHIR profiles, expanding C-CDA templates, and re-validating API conformance.

Explore Related Terms

What is Interoperability?What is HIE?What is Meaningful Use?

Ready to discuss your USCDI project?

Schedule a free call

Ready to Discuss Your Project With Us?

Your email address will not be published. Required fields are marked *

What is 1 + 1 ?

What's Next?

Our expert reaches out shortly after receiving your request and analyzing your requirements.

If needed, we sign an NDA to protect your privacy.

We request additional information to better understand and analyze your project.

We schedule a call to discuss your project, goals. and priorities, and provide preliminary feedback.

If you're satisfied, we finalize the agreement and start your project.