USCDI v7: New Data Elements for Interoperability

The United States Core Data for Interoperability (USCDI) defines the minimum set of health data elements that must be exchangeable between systems nationwide. Every certified EHR, every health information exchange, and every FHIR API that participates in the US healthcare ecosystem is bound by USCDI requirements. When ONC adds new data classes and elements, the downstream impact touches integration teams, EHR vendors, app developers, and health systems alike.

USCDI v7, published by ONC in January 2026, introduces several new data classes and expands existing ones. This post breaks down what changed, why it matters, and what integration teams should do now to prepare.

What Is USCDI and Why It Matters

USCDI stands for United States Core Data for Interoperability. It is maintained by the Office of the National Coordinator for Health Information Technology (ONC) and defines the standardized set of health data classes and constituent data elements that must be supported for nationwide interoperable health information exchange.

In practical terms, USCDI is the answer to a fundamental question: when two healthcare systems exchange patient data, what data elements should both sides be able to send and receive? Before USCDI, the Common Clinical Data Set (CCDS) served a similar purpose but was narrower in scope and less systematically maintained.

USCDI matters for three reasons:

Certification requirements. EHR vendors seeking ONC Health IT Certification must demonstrate support for the current USCDI version. This directly affects what data their systems can produce and consume through standard APIs.
Regulatory mandates. CMS and ONC rules reference USCDI as the baseline for patient access APIs, provider directory APIs, and payer-to-payer data exchange under the CMS Interoperability and Prior Authorization final rule.
FHIR Implementation Guides. The US Core Implementation Guide, which defines how USCDI data elements map to FHIR resources and profiles, is updated in lockstep with USCDI versions. Every SMART on FHIR app and FHIR API that uses US Core is affected.

USCDI Version History

Understanding USCDI v7 requires context on how the standard has evolved. Each version has added data classes and elements that reflect the expanding scope of interoperable health data exchange.

USCDI v1 (2020)

The initial version established the foundation with core clinical data classes: Allergies and Intolerances, Assessment and Plan of Treatment, Care Team Members, Clinical Notes, Goals, Health Concerns, Immunizations, Laboratory, Medications, Patient Demographics, Problems, Procedures, Provenance, Smoking Status, Unique Device Identifiers, and Vital Signs. These mapped closely to the earlier CCDS requirements.

USCDI v2 (2022)

Added Clinical Tests (including clinical test results and diagnostic imaging reports), Encounter Information, and Health Insurance Information (draft). Expanded Patient Demographics to include sexual orientation, gender identity, and date of death.

USCDI v3 (2023)

Introduced Facility Information, Health Status Assessments (functional status, disability status, mental/cognitive status), and expanded Laboratory to include specimen type. Added Average Blood Pressure to Vital Signs.

USCDI v4 (2024)

Added Treatment Intervention Preferences, Functioning and Disability (using ICF codes), and expanded Health Insurance Information from draft to standard. Included Medication Instructions and Reason for Referral.

USCDI v5 (2024)

Expanded diagnostic imaging with standardized report formats. Added emergency contact and related person data. Introduced race and ethnicity granularity aligned with OMB recommendations.

USCDI v6 (2025)

Introduced advance directive information as a formal data class. Expanded encounter information to include discharge disposition. Added surgical history and family health history improvements.

USCDI v7 (2026)

The current version introduces several new data classes and elements described in detail below.

What Is New in USCDI v7

USCDI v7 represents the most substantial expansion since v3. The additions reflect ONC’s priorities around social determinants of health, patient preferences, and administrative data exchange.

SDOH has been a Level 2 element in the USCDI expansion queue for several versions. In v7, it becomes a full data class with the following elements:

SDOH Assessment: Standardized screening results using validated instruments (PRAPARE, AHC-HRSN, etc.), represented as FHIR Observation resources with LOINC-coded questions and answers.
SDOH Goals: Patient-specific goals related to social determinants, represented as FHIR Goal resources.
SDOH Interventions: Referrals and services provided to address identified social needs, represented as FHIR ServiceRequest and Procedure resources.
SDOH Problems/Health Concerns: Conditions identified through SDOH screening, coded using ICD-10 Z-codes (Z55-Z65), represented as FHIR Condition resources.

The FHIR mapping leverages the Gravity Project’s SDOH Clinical Care Implementation Guide, which defines specific profiles for each of these elements. Integration teams working with SDOH data should review the Gravity Project IG alongside the US Core updates.

New Data Class: Patient Communication Preferences

This data class captures how patients prefer to receive health information and communication:

Preferred Language: Already partially captured in Patient Demographics but expanded with more granular language codes.
Communication Method Preference: Whether the patient prefers phone, text, email, or postal mail for different types of communication.
Health Literacy Considerations: Indicators of health literacy level that may affect how information should be communicated.

In FHIR terms, these map primarily to the Patient resource’s communication element and extensions defined in the US Core Patient profile.

Expanded: Health Insurance Information

Health Insurance Information was elevated to a standard data class in v4. In v7, the coverage data elements are significantly expanded:

Coverage Status: Active, cancelled, or entered in error.
Coverage Type: Medical, dental, vision, pharmacy, etc.
Subscriber Information: Relationship to policyholder, subscriber ID, group number.
Payer Information: Payer name, payer ID (using NPPES NPI for organizations or the CMS National Plan and Provider Enumeration System).
Plan Information: Plan name, plan type (HMO, PPO, EPO, etc.).
Coverage Period: Start and end dates.

These elements map to the FHIR Coverage resource and are critical for the CMS Interoperability and Prior Authorization final rule, which requires payers to make coverage information available through standardized FHIR APIs.

Expanded: Encounter Information

Encounter data gains several new elements:

Encounter Reason: Coded reason for the encounter (chief complaint or reason for visit), mapped to FHIR Encounter.reasonCode.
Encounter Diagnosis Ranking: Primary, secondary, and additional diagnosis ranking for the encounter.
Encounter Service Provider: The organization responsible for the encounter.

Expanded: Clinical Notes

Clinical Notes adds structured support for:

Consultation Notes: Previously optional, now a required note type.
Referral Notes: Documentation accompanying referrals, including reason for referral and relevant clinical history.
Operative Notes: Structured operative note elements beyond free-text narratives.

Expanded: Vital Signs

Two new vital sign elements join the existing set:

Pediatric BMI for Age: Age- and sex-specific BMI percentile for patients under 20.
Pediatric Head Circumference: Occipitofrontal circumference measurement.

These align with the existing FHIR Vital Signs profiles and use the same Observation resource structure with specific LOINC codes.

Impact on EHR Certified Technology

EHR vendors seeking ONC certification must demonstrate support for the USCDI version specified in the applicable certification criteria. The ONC Health IT Certification Program typically references a specific USCDI version in its regulations, and vendors have a compliance window to implement support.

For USCDI v7, the practical impact on EHR vendors includes:

FHIR API updates. Certified EHR APIs must support new FHIR profiles corresponding to v7 data elements. This means new resource types in API responses, new search parameters, and updated capability statements.
Data capture workflows. EHRs must provide mechanisms for clinicians to capture the new data elements (SDOH screening, communication preferences, expanded coverage data) during clinical workflows.
Data export. Bulk FHIR export ($export operation) must include the new data classes for population health and payer use cases.

Health systems running Epic, Oracle Health (Cerner), athenahealth, or other certified EHRs should expect updates from their vendors to support v7. The timeline depends on when ONC finalizes the certification criteria referencing v7 and the compliance deadlines in those rules.

Impact on FHIR Implementation Guides

The US Core Implementation Guide is the primary FHIR IG affected by USCDI changes. US Core defines FHIR profiles, extensions, search parameters, and capability statements that implement USCDI requirements in FHIR R4.

US Core Profile Updates

For USCDI v7, expect US Core updates to include:

USCDI v7 Addition	FHIR Resource	US Core Profile
SDOH Assessment	Observation	US Core SDOH Screening Assessment
SDOH Goals	Goal	US Core Goal (updated)
SDOH Interventions	ServiceRequest, Procedure	US Core ServiceRequest, US Core Procedure (updated)
SDOH Problems	Condition	US Core Condition (updated)
Communication Preferences	Patient	US Core Patient (updated)
Expanded Coverage	Coverage	US Core Coverage (new/updated)
Encounter Reason	Encounter	US Core Encounter (updated)
Consultation Notes	DocumentReference	US Core DocumentReference (updated)
Pediatric Vital Signs	Observation	US Core Vital Signs (new profiles)

Search Parameter Additions

New search parameters will be required to locate resources corresponding to v7 data elements. For example, searching for SDOH-related Conditions by category (using the social-history category code) or searching for Coverage resources by status and type.

CapabilityStatement Updates

FHIR servers supporting US Core will need to update their CapabilityStatement resources to advertise support for new profiles, search parameters, and interactions. Client applications should check the CapabilityStatement to determine which v7 features a given server supports.

Timeline for Certification Requirements

ONC typically follows a predictable cycle for incorporating new USCDI versions into certification requirements:

USCDI version published (USCDI v7: January 2026).
US Core IG updated to reflect new data elements (typically 3-6 months after USCDI publication).
ONC proposed rule referencing the new USCDI version (variable timeline, typically 6-12 months after USCDI publication).
ONC final rule with compliance deadlines (6-12 months after proposed rule).
EHR vendor compliance deadline (specified in the final rule, typically 12-24 months after the final rule).

Based on historical patterns, integration teams can expect US Core updates reflecting v7 in mid-2026, with certification requirements finalized by late 2026 or early 2027 and vendor compliance deadlines in 2027 or 2028.

This timeline gives integration teams a meaningful window to prepare, but the preparation should start now, not when the compliance deadline approaches.

What Integration Teams Should Do Now

Audit Your Current USCDI Support

Start by assessing your current integration capabilities against USCDI v7. Document which data classes and elements your systems already support and which represent gaps. Many organizations implemented partial support for SDOH and coverage data ahead of formal USCDI inclusion. Understanding your current state helps prioritize implementation work.

Review the Gravity Project IG

If you will be handling SDOH data (and most health systems will), invest time in the Gravity Project’s SDOH Clinical Care Implementation Guide. It defines the value sets, code systems, and FHIR profiles that US Core will reference for SDOH data elements. Understanding these profiles now avoids rework later.

Plan FHIR API Updates

If you maintain FHIR APIs (whether custom-built or based on a FHIR server like HAPI FHIR or Smile CDR), start planning the API updates needed to support new v7 profiles. This includes adding new resource types to your API, implementing new search parameters, and updating your CapabilityStatement.

Coordinate with EHR Vendors

Contact your EHR vendor (Epic, Oracle Health, athenahealth, etc.) to understand their USCDI v7 implementation timeline. Ask specifically about:

When they expect to support v7 data elements in their FHIR APIs.
Whether v7 support will require an EHR version upgrade.
What changes are needed in your integration interfaces to consume new data elements.

Update Integration Interfaces

For integration engines like Mirth Connect or OIE, review your channel configurations. Channels that process CDA documents, HL7 v2 messages, or FHIR resources may need updates to handle new data elements. At a minimum, ensure your channels do not drop or reject messages that contain unfamiliar data elements, which is a common source of interoperability failures when standards evolve.

Test with Synthetic Data

The FHIR community maintains public test servers and synthetic data sets. Use these to test your systems’ ability to process v7 data elements before real-world data starts flowing. The SMART on FHIR sandbox, Synthea (synthetic patient generator), and Inferno (ONC testing tool) are all useful for this purpose.

Looking Ahead

USCDI is an evolving standard. ONC maintains an expansion queue (USCDI+) of data elements under consideration for future versions. Elements currently in the queue include genomic data, public health reporting elements, and additional social determinant categories. Integration teams that build flexible, standards-based architectures today will find it easier to absorb future USCDI expansions without major rework.

The trend is clear: the scope of interoperable health data exchange continues to expand. Organizations that treat USCDI compliance as a one-time project will find themselves perpetually catching up. Those that build USCDI awareness into their integration development lifecycle will stay ahead.

For help implementing USCDI v7 data elements in your integration environment, explore our related services:

Healthcare Interoperability Services — Standards-based interoperability strategy and implementation
FHIR API Integration — FHIR R4 API development and US Core compliance
EHR Integration Services — Integration with Epic, Oracle Health, athenahealth, and other certified EHRs