USCDI v3 Compliance by January 2026: The Data Elements Your EHR Must Support Now

As of January 2026, certified health IT systems must support USCDI v3 (United States Core Data for Interoperability, version 3) under the ONC HTI-1 Final Rule. This is not optional. If your EHR, health information exchange, or patient-facing application is ONC-certified -- or connects to one -- USCDI v3 compliance is now a regulatory requirement.

USCDI v3 adds several new data classes and data elements beyond what v2 required, including Health Insurance Information, expanded Encounter Information, Clinical Tests, and Diagnostic Imaging. Many organizations are discovering that while their systems handle v2 data elements well, the v3 additions expose significant gaps in their data capture, storage, and API exposure.

This guide maps every USCDI v3 data class to its corresponding FHIR US Core profile, identifies the most common compliance gaps, and provides a testing approach using the Inferno US Core test suite. If you also support older or newer USCDI releases, our USCDI vs US Core version map shows which US Core release lines up with each one.

What Changed from USCDI v2 to v3

USCDI v3 builds on v2 by adding new data classes, expanding existing ones, and adding new data elements within existing classes. Here are the most significant changes:

New Data Classes in v3

• Health Insurance Information: Coverage status, coverage type, member identifier, group number, payer name, plan name, and relationship to subscriber. This is entirely new -- most EHRs capture insurance data but do not expose it through standardized FHIR APIs.
• Diagnostic Imaging (expanded): Diagnostic imaging reports, including imaging narrative and structured findings. Previously only partially covered under Clinical Notes.

Expanded Existing Data Classes

• Encounter Information: Now requires encounter diagnosis, disposition, encounter location, encounter time, encounter type, and encounter identifier. v2 only required basic encounter data.
• Clinical Tests: Expanded to include clinical test results and clinical test categories beyond basic lab results. This covers non-laboratory clinical assessments.
• Procedures: Now requires procedure status and procedure reason in addition to the procedure itself.
• Health Status Assessments: New data elements for functional status, disability status, and mental/cognitive status assessments using standardized instruments.

New Data Elements in Existing Classes

• Patient Demographics: Date of death added, sex parameter for clinical use added (distinct from administrative gender)
• Problems: Health concern added as a data element (distinct from conditions/diagnoses)
• Medications: Medication adherence added
• Clinical Notes: Expanded note types including imaging narratives

Complete USCDI v3 to FHIR Mapping

Every USCDI v3 data element maps to a specific FHIR US Core profile. Here is the complete mapping:

The Biggest Compliance Gaps

Based on our experience building EHR systems and working with healthcare organizations on compliance, these are the data classes where we see the most gaps:

Health Insurance Information (Compliance Rate: ~35%)

This is the biggest gap. Most EHRs capture insurance data for billing, but few expose it through a standard FHIR Coverage API. The challenge is that insurance data is typically stored in billing-specific tables, not in the clinical data model. Building a FHIR facade over billing data requires careful mapping:

{
  "resourceType": "Coverage",
  "status": "active",
  "type": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
      "code": "HIP",
      "display": "health insurance plan policy"
    }]
  },
  "subscriber": {
    "reference": "Patient/123"
  },
  "subscriberId": "MBR-12345",
  "beneficiary": {
    "reference": "Patient/123"
  },
  "relationship": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/subscriber-relationship",
      "code": "self"
    }]
  },
  "period": {
    "start": "2025-01-01",
    "end": "2025-12-31"
  },
  "payor": [{
    "reference": "Organization/insurance-456",
    "display": "Blue Cross Blue Shield"
  }],
  "class": [
    {
      "type": {
        "coding": [{
          "system": "http://terminology.hl7.org/CodeSystem/coverage-class",
          "code": "group"
        }]
      },
      "value": "GRP-789",
      "name": "Corporate Employee Plan"
    },
    {
      "type": {
        "coding": [{
          "system": "http://terminology.hl7.org/CodeSystem/coverage-class",
          "code": "plan"
        }]
      },
      "value": "GOLD-2025",
      "name": "Gold PPO Plan"
    }
  ]
}

Encounter Information (Compliance Rate: ~42%)

v3 requires much more encounter detail than v2. The expanded requirements for encounter diagnosis, disposition, and location mean that systems which previously stored minimal encounter data must now capture and expose structured encounter contexts. This is particularly challenging for organizations using EHR integration patterns that aggregate encounter data from multiple source systems.

Clinical Tests (Compliance Rate: ~48%)

Clinical tests that are not laboratory tests -- functional assessments, cognitive screenings, developmental evaluations -- are often captured in clinical notes rather than structured observations. USCDI v3 requires these as discrete, coded Observation resources. The extraction challenge here overlaps with the 80/20 unstructured data problem.

Health Status Assessments (Compliance Rate: ~45%)

Functional status, disability status, and mental health assessments are often captured using validated instruments (PHQ-9, GAD-7, PROMIS). USCDI v3 requires these as structured Observation resources with proper LOINC coding. Many systems store the assessment as a document rather than discrete coded values.

Testing with Inferno

Inferno (inferno.healthit.gov) is the official ONC-recommended testing tool for FHIR conformance. The US Core test suite validates both data structure and API behavior against US Core profiles -- which implement USCDI requirements. Because those tests check profile constraints, it helps to understand how FHIR profiles, extensions and Must Support work before your first run.

Setting Up Inferno Testing

1. Deploy Inferno: Run Inferno locally using Docker or use the hosted version at inferno.healthit.gov
2. Configure your FHIR server endpoint: Point Inferno at your FHIR server's base URL
3. Configure SMART credentials: Inferno needs client credentials for testing authenticated endpoints
4. Select the US Core test suite: Choose the version matching your US Core Implementation Guide version (US Core 6.x or 7.x for USCDI v3)
5. Run tests incrementally: Start with Patient, then expand to other resource types

Common Inferno Failures and Fixes

Implementation Timeline

For organizations not yet fully compliant, here is a realistic implementation timeline:

Phase 1: Gap Assessment (Month 1)

• Run Inferno US Core test suite against current implementation
• Document all failing tests by data class
• Map failures to USCDI v3 data elements
• Prioritize: focus on new v3 requirements first (Health Insurance, expanded Encounters, Clinical Tests)

Phase 2: Data Model Updates (Month 2-3)

• Update database schema to support new data elements
• Build or update FHIR resource mappings for Coverage, expanded Encounter, Clinical Test Observations
• Implement terminology bindings (correct LOINC, SNOMED CT, CVX codes)
• Ensure Provenance resources are generated for all writes

Phase 3: API Development (Month 3-5)

• Implement or update FHIR endpoints for new resource types (Coverage)
• Add required search parameters for expanded data classes
• Update CapabilityStatement to reflect new capabilities
• Implement proper SMART on FHIR scope handling for new resources

Phase 4: Testing and Validation (Month 5-6)

• Run full Inferno US Core test suite -- target zero failures
• Validate all resource instances against US Core profiles using the HL7 FHIR Validator
• Conduct integration testing with downstream consumers
• Perform security review of new endpoints and data access

Phase 5: Certification and Deployment (Month 7+)

• Submit for ONC certification testing if applicable
• Deploy to production with monitoring for new data classes
• Set up observability dashboards for USCDI v3 API usage patterns

The Regulatory Context

Understanding where USCDI v3 fits in the regulatory landscape helps prioritize implementation:

• ONC HTI-1 Final Rule: Published December 2023, effective January 2026 for USCDI v3 adoption. This is the primary regulatory driver.
• CMS Interoperability Rules: CMS requires payers and providers to support patient access APIs using USCDI standards. The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) reinforces USCDI v3 adoption for payer-to-provider data exchange.
• TEFCA (Trusted Exchange Framework and Common Agreement): TEFCA uses USCDI as the minimum data set for nationwide health information exchange. TEFCA Qualified Health Information Networks (QHINs) must support USCDI v3 data elements.
• 21st Century Cures Act: The underlying legislation mandating standardized APIs and prohibiting information blocking. USCDI defines the minimum data set that must be available through these APIs.

Practical Checklist for USCDI v3 Compliance

1. Audit current USCDI v2 compliance: Run Inferno and document your baseline
2. Map v3 gaps: Identify specific data elements you cannot currently produce via FHIR API
3. Prioritize Health Insurance Information: This is the highest-impact new data class with the lowest current compliance rate
4. Update Encounter model: Add encounter diagnosis, disposition, and location if not already structured
5. Add Clinical Test observations: Ensure non-lab clinical tests (screenings, assessments) produce coded Observations
6. Implement Health Status Assessments: Map PHQ-9, GAD-7, and other standard instruments to LOINC-coded Observations
7. Update CapabilityStatement: Ensure your server metadata reflects all new capabilities
8. Test with Inferno: Run the US Core test suite until all tests pass
9. Monitor production: Track API usage for new data classes to verify real-world data flow

Frequently Asked Questions

Is USCDI v3 compliance mandatory for all healthcare organizations?

USCDI v3 compliance is mandatory for ONC-certified health IT. If your EHR or health IT product holds ONC certification (or plans to), you must support USCDI v3. Organizations that use certified health IT (hospitals, clinics) are indirectly affected because their vendor must provide the capabilities. Non-certified applications (analytics tools, patient engagement apps) are not directly regulated but benefit from supporting USCDI v3 for interoperability.

What happens if we are not compliant by January 2026?

For ONC-certified health IT developers, non-compliance risks certification status. For healthcare organizations using certified EHRs, the vendor is responsible for providing USCDI v3 capabilities. If your vendor has not updated, escalate through their product roadmap process. There is no explicit penalty for individual provider organizations, but information blocking regulations require making USCDI data elements available when requested.

Related Reading

For more insights, explore our guides on USCDI v7 Developer Guide: 156 Data Elements & FHIR and FHIR in Modern Healthcare.

You may also find value in EHR Software Development Guide and Building a Healthtech App.

How does USCDI v3 relate to US Core profiles?

USCDI defines the data elements (what data). US Core profiles define how to represent those elements in FHIR (the format). US Core Implementation Guide versions are updated to align with USCDI versions. US Core 6.1 and 7.0 align with USCDI v3 requirements. Always implement against the US Core profiles, not against USCDI data classes directly.

Is USCDI v4 coming? Should we wait?

Yes, USCDI v4 is in development and will add more data classes. However, v4 is not expected to be regulatory-required until 2028 at the earliest. Do not wait -- implement v3 now and plan for incremental v4 additions later. Each USCDI version builds on the previous one, so v3 work is not wasted.

How do we handle data elements we do not currently capture?

USCDI requires the capability to capture, store, and exchange data elements -- not that every patient record must contain them. If your system can accept and return Health Insurance Information when it exists, you are compliant even if many patient records lack insurance data. The key is capability, not completeness.

Can we use Bulk Data Export for USCDI v3 compliance?

Bulk Data Export ($export) is part of the FHIR access API but is tested separately. USCDI v3 compliance focuses on individual patient access (SMART on FHIR patient-level APIs). Bulk Data Export is required for provider-to-provider and payer-to-provider data exchange but is covered under separate certification criteria.