If you're a healthcare vendor building integrations with EPIC or any certified EHR, you'll run into ONC USCDI sooner rather than later. The United States Core Data for Interoperability is a standardized set of health data classes and elements that certified health IT systems are required to support under the 21st Century Cures Act. It defines exactly which patient data, from allergies and medications to social determinants of health, must be accessible and exchangeable across systems.

USCDI matters because it determines what data your application can expect to read and write through FHIR APIs when connecting to EHRs like EPIC. Each version of the standard expands the required data set, and health systems pay close attention to whether your integration aligns with the current USCDI version their certified EHR supports. Missing this alignment can stall contracts and slow your path to market.

At VectorCare, we build our no-code SMART on FHIR platform around these standards so healthcare vendors can launch EPIC integrations in weeks, not months, without needing to decode every USCDI data class themselves. But understanding what USCDI is, how its versions have evolved, and how it maps to FHIR resources gives you a real advantage when scoping your product and talking to health systems.

This article breaks down USCDI from the ground up: what it covers, how each version builds on the last, and how the standard connects to FHIR implementation guides that power real EHR integrations.

What ONC USCDI is and who sets it

The Office of the National Coordinator for Health Information Technology (ONC) is the federal agency within the U.S. Department of Health and Human Services responsible for national health IT policy and standards. ONC USCDI, the United States Core Data for Interoperability, is a structured set of data classes and data elements that the ONC publishes and maintains. Certified health IT products, including EHR systems like EPIC, must support these data elements so that patient information can move reliably between providers, payers, and third-party applications.

USCDI is not a suggestion. Any health IT product that holds ONC certification under the 21st Century Cures Act must support every data element in the current required version.

The role of ONC in publishing and maintaining USCDI

ONC develops and updates USCDI through a transparent, public-comment process that draws input from clinicians, health IT vendors, patient advocates, and payers. The agency reviews proposals submitted through its USCDI portal, evaluates each candidate data element against criteria like clinical relevance and technical maturity, and then finalizes updates through formal rulemaking. This structured approach means USCDI evolves based on real industry feedback rather than arbitrary decisions, which gives you some predictability when planning your product roadmap.

Before a data element makes it into a published USCDI version, it passes through review stages: Level 1 submission, Level 2 proposal, and then final publication. Each stage involves deeper evaluation of whether health IT systems can feasibly implement the element. This staged process reduces the risk that a new requirement catches the industry off guard, but it also means that elements you see under review today could become mandatory in your target EHR within one or two regulatory cycles, so tracking the ONC pipeline is a worthwhile habit.

What USCDI actually defines

USCDI organizes required health data into data classes, which are broad categories, and data elements, which are the specific fields within each class. For example, the Medications data class includes elements like medication name, dosage, and route of administration. Other data classes cover allergies and intolerances, clinical notes, diagnostic imaging, laboratory results, patient demographics, and social determinants of health.

Here is a sample of key data classes USCDI includes:

• Patient Demographics: Name, date of birth, address, preferred language, sex, race, ethnicity
• Clinical Notes: Consultation notes, discharge summaries, progress notes, imaging narratives
• Medications: Medication requests, medication dispensed records, and adherence data
• Laboratory: Lab results with values and reference ranges
• Vital Signs: Blood pressure, heart rate, respiratory rate, body weight, and pulse oximetry
• Social Determinants of Health (SDOH): Health concerns and goals tied to social context

Each data class maps to specific FHIR resources, which is how EHRs expose these elements through their APIs. When you build a SMART on FHIR application, understanding these data classes tells you exactly what patient data you can pull and in what structure to expect it, before you write a single line of configuration or integration logic.

How federal law drives USCDI adoption

The 21st Century Cures Act, enacted in 2016 and implemented through ONC's information blocking and certification rules, established USCDI as a foundational standard for certified health IT. The ONC Health IT Certification Program requires EHR vendors to demonstrate support for the current USCDI version as part of their certification. Health systems rely on certified EHRs to meet their own regulatory obligations under programs like Medicare and Medicaid, which means USCDI compliance cascades through the entire ecosystem, from the federal level down to the third-party applications you build on top of those EHRs.

Why USCDI matters for interoperability

Health data interoperability fails when systems speak different languages. Without a shared standard defining which data elements must exist and how they must be structured, a lab result from one system might arrive in a format another system cannot read, a medication list might be incomplete, or a patient record might transfer without the social context a care team needs. ONC USCDI solves this by establishing a common baseline that every certified EHR must support, making data exchange predictable rather than a case-by-case negotiation.

How USCDI removes guesswork from data exchange

When you build a healthcare application, your biggest technical risk is uncertainty: you don't know exactly what data the EHR will return, in what format, or whether the fields you depend on will be populated. USCDI eliminates that uncertainty for the required data elements it defines. Because certified EHRs must support each element in the current USCDI version, you can design your application around a guaranteed minimum data set rather than hoping each health system has configured their EHR to expose what you need.

This is especially important when you're selling to multiple health systems at once. Instead of auditing each customer's EHR configuration individually, you can map your product to the USCDI data classes and trust that any certified EHR will meet that baseline. That alignment shortens your integration scoping process and gives your sales team a concrete answer when prospects ask whether your solution works with their EHR.

The real power of USCDI is that it shifts the interoperability conversation from "can we get access to this data?" to "here is the data you already have access to."

The consequences of missing USCDI alignment

Ignoring ONC USCDI in your product design creates problems that surface at the worst possible time: during health system procurement and technical review. Health IT committees at large health systems evaluate third-party applications against specific compliance benchmarks, and USCDI alignment is often a direct checklist item. If your integration pulls data in ways that don't match the current USCDI structure, you introduce risk that reviewers flag before you even reach contract negotiation.

Beyond procurement, missing alignment creates ongoing maintenance burden. When a health system upgrades to a newer certified version of EPIC that implements a newer USCDI version, your integration may break or return incomplete data if you haven't tracked the data class changes. Building your application against USCDI from the start means you maintain a single, well-defined integration surface rather than patching custom data mappings whenever an EHR vendor updates their certification.

USCDI versions and how updates happen

ONC USCDI has gone through multiple published versions since its initial release, each one expanding the required data set that certified EHRs must support. Understanding which version a health system's EHR is certified against tells you exactly what data your application can count on when connecting to that system.

A brief history of USCDI versions

The first version, USCDI v1, was published alongside the 2020 ONC Cures Act Final Rule. This initial release established the core baseline: data classes like allergies, medications, patient demographics, lab results, and clinical notes. USCDI v2 followed in 2022, adding new elements such as health insurance information, sexual orientation, and gender identity, reflecting growing recognition that clinical care depends on social and demographic context.

USCDI v3 arrived in 2023 and introduced additional data classes, including facility information and patient communication preferences. Version 4 expanded the set further in 2024, adding care team members and related-person data. Each version builds directly on the previous one: no data element is removed, only added or refined. That backward-compatible structure means your integration does not break when a health system moves to a newer certified EHR version, but you may need to account for new elements your application should read or write.

When a health system upgrades their certified EHR, the USCDI version bundled with that certification becomes the new floor your integration is measured against.

How ONC processes new data element proposals

Any stakeholder, whether a clinician, a payer, or a health IT vendor, can submit a candidate data element through ONC's public USCDI portal. Submissions pass through a staged review process. At Level 1, ONC collects the submission and evaluates clinical relevance and feasibility. At Level 2, the element moves to formal proposal status and receives public comment, where the broader industry can respond. Final publication into a USCDI version happens only after ONC confirms that health IT systems can realistically implement the element at scale.

Tracking this pipeline gives you advance visibility into upcoming requirements. Reviewing Level 2 proposals today tells you which data elements are likely to become mandatory in the next one or two USCDI versions. If your product roadmap depends on a specific data type, checking the ONC pipeline lets you plan your FHIR resource mappings before a new version becomes a hard requirement for your health system customers.

How USCDI works with FHIR and US Core

USCDI defines what data certified EHRs must support. FHIR defines how that data gets structured and transmitted. These two standards work together, not in competition. When ONC USCDI specifies that a certified EHR must support patient demographics or laboratory results, FHIR provides the technical format and API protocol those data elements travel through. Understanding how they connect helps you design integrations that are both compliant and practical from day one.

The relationship between USCDI data classes and FHIR resources

Each USCDI data class maps directly to one or more FHIR resources. The Medications data class, for example, maps to the MedicationRequest and MedicationDispense FHIR resources. The Laboratory data class maps to the Observation resource. This mapping is not informal. The US Core Implementation Guide published by HL7 formally specifies exactly how each USCDI element should be represented as a FHIR resource, which profiles apply, and which fields are mandatory versus optional.

When you query an EPIC FHIR API for a patient's lab results, you're calling the Observation endpoint structured according to US Core profiles, which in turn implement the USCDI laboratory data element requirements. That chain, from USCDI requirement to US Core profile to FHIR resource to EHR API response, is what makes data exchange predictable across different health systems without custom negotiation for every new customer.

What the US Core Implementation Guide adds

US Core does the translation work between policy and implementation. The HL7 US Core Implementation Guide takes the data elements defined in ONC USCDI and specifies the exact FHIR resource profiles, terminology bindings, and cardinality rules that EHR vendors must follow. Without US Core, two vendors could each claim USCDI compliance while returning data in completely different FHIR structures, which would make interoperability fragile in practice regardless of what the regulation requires.

US Core turns a regulatory requirement into a concrete API contract you can build against with confidence.

Each new USCDI version triggers a corresponding US Core update. When USCDI v3 added communication preferences as a required data element, US Core added the matching FHIR profiles defining exactly how those preferences appear in an API response. Your integration roadmap should track both USCDI versions and their corresponding US Core versions together rather than treating them as separate concerns. A health system that upgrades to a newer certified EHR brings both changes into your integration surface at the same time, so staying current on one without the other creates gaps you'll eventually have to close under pressure.

How to use USCDI in SMART on FHIR apps

When you build a SMART on FHIR application that connects to EPIC, your first step is mapping what data your product needs against the data classes that ONC USCDI defines. This mapping exercise tells you immediately whether the data your product depends on falls within the guaranteed baseline or requires negotiation with each health system individually. Getting this clarity early prevents you from scoping integrations that assume data availability you cannot rely on in practice.

Map your product requirements to USCDI data classes

Start by listing every patient data point your application reads or writes. Then place each item against the USCDI data classes your target EHR's certification version covers. If your application needs medication history and laboratory results, those land squarely within USCDI data classes that every certified EHR must expose. If your product depends on data outside the current USCDI scope, you need to plan for variability: some health systems will have that data available through FHIR, others will not, and you cannot set a uniform expectation across customers.

This mapping also sharpens your product positioning. When a health system's IT committee asks what data your application needs, you can hand them a clear list tied directly to USCDI data classes rather than a vague API requirements document. That level of specificity builds credibility with technical reviewers and shortens the procurement review cycle in ways that vague integration descriptions never will.

The cleaner your USCDI mapping, the faster health system technical reviewers can approve your integration and move you toward contract.

Query against US Core profiles to stay compliant

Once you know which USCDI data classes your application depends on, write your FHIR queries against the US Core profiles that correspond to those classes. US Core profiles specify the exact resource structures, required fields, and terminology codes that certified EHRs return. Querying against US Core means your application handles responses consistently across different health systems rather than breaking when one EPIC instance returns a slightly different response structure than another.

Validating your FHIR responses against the relevant US Core profile during development, not just in production, is the practical move that separates teams that hit go-live dates from teams that scramble at the last minute. Catching structural mismatches early means you fix integration gaps before a health system's launch, not during it. Platforms like VectorCare handle this profile alignment automatically through pre-built FHIR actions, so your team configures data pulls visually rather than hand-coding every resource query and validation check from scratch.

Key takeaways

ONC USCDI gives you a guaranteed baseline of patient data that every certified EHR must support, removing guesswork from your integration planning. Each version expands that baseline without removing prior elements, so your integration surface grows in a predictable direction. USCDI data classes map directly to US Core FHIR profiles, which translate regulatory requirements into concrete API contracts you can build against. When you align your product to those profiles from the start, you move faster through health system procurement, reduce maintenance surprises when EHRs upgrade certifications, and give technical reviewers the clear compliance picture they want before approving your application.

Staying ahead of USCDI matters more as health systems raise their integration standards. If you want to launch a SMART on FHIR app on EPIC without decoding every data class and profile yourself, VectorCare's no-code SMART on FHIR platform handles FHIR configuration, USCDI alignment, and EPIC Showroom submission so your team can focus on your core product.