USCDI defines the specific data content developers must support for multiple ONC certification criteria. To be certification-compliant, you must map, represent, and exchange the listed USCDI data elements using the vocabulary and syntax your certification criterion requires, with USCDI v3 as the current baseline for the ONC Health IT Certification Program. Content comes from the USCDI standard itself, while syntax and terminology come from FHIR, US Core, C-CDA, and vocabularies like SNOMED CT, LOINC, and RxNorm.
TL;DR:
- U.S. health data developers must support all USCDI v3 elements, mapped with current vocabularies like SNOMED CT, LOINC, and RxNorm, to meet certification criteria.
- Certification requirements include supporting data across multiple standards and formats, such as FHIR, C-CDA, and US Core profiles, depending on the criterion.
- USCDI versioning is ongoing, with USCDI v3 being mandatory for certification starting January 1, 2026, and draft versions published for stakeholder input.
- Effective mapping involves maintaining crosswalks, tracking terminology versions, and handling legacy data via backfill projects separate from ongoing pipelines.
- Prioritizing certification-relevant elements and communicating changes clearly helps small teams meet compliance efficiently and improve product-market positioning.
Table of Contents
- What USCDI Is and How Its Data Is Organized
- Which ONC Certification Criteria Reference USCDI
- USCDI Versioning, ONDEC, and USCDI+
- Technical Mapping for Engineers: Vocabularies and Syntax
- A Practical Compliance Checklist for Certification Readiness
- Practical Tips: Prioritization, Resourcing, and Communication
- Why Early USCDI Alignment Shapes Product-Market Fit
- How We Help With USCDI Readiness
- FAQ
- Sources
What USCDI Is and How Its Data Is Organized
The United States Core Data for Interoperability standard defines a set of data classes and elements intended for nationwide, interoperable health information exchange. A data class is a grouping concept, such as patient demographics or vital signs. A data element is the specific field inside that class.
A few examples make the structure concrete:
- Patient demographics includes elements like first name, last name, and date of birth.
- Vital signs includes elements like body temperature and blood pressure.
- Medications includes elements like medication name and dose.
Each element carries applicable vocabulary standards. Getting the content right means little if the underlying code set is wrong or outdated, which is why terminology management belongs in the same conversation as data mapping, not a separate afterthought.
Which ONC Certification Criteria Reference USCDI
Use of the USCDI standard is required as part of the API certification criterion at §170.315(g)(10), and it replaces the Common Clinical Data Set across several other criteria in the Cures Act Final Rule. For developers, this means USCDI is not a single checkbox. It is a thread running through most of your certified module.
The principal criteria that reference USCDI include:
- Standardized API for patient and population services, §170.315(g)(10)
- Transitions of care, §170.315(b)(1)
- View, download, and transmit to a third party, §170.315(e)(1)
- Consolidated CDA creation performance, §170.315(g)(6)
- Transmission to public health agencies, §170.315(f)(5)
- Application access to all data for a patient's request, §170.315(g)(9)
"Support" for a Health IT Module means the module can receive, store, retrieve, and exchange every applicable USCDI element for that criterion, not just the ones a customer happens to populate. Condition and Maintenance of Certification rules add an ongoing obligation: once a baseline shifts, you must update certified functionality and deliver that update to customers within the regulatory timeframe, not whenever a sprint allows it.
It helps to separate two questions that often get merged. USCDI tells you what content a criterion requires. The criterion and its implementation guide tell you what syntax that content must take, whether that is a FHIR resource, a C-CDA template, or an API response structure.
USCDI Versioning, ONDEC, and USCDI+
HTI-1 adopted USCDI v3 as the new baseline for the Certification Program, effective January 1, 2026, which gives teams a fixed point to plan against rather than guessing at a moving target. Versions do not stop there, though. ONC typically publishes draft USCDI versions in January and finalizes them in July, and Standards Bulletin 2026-1 describes that cadence alongside the proposed Draft USCDI v7.
A few mechanisms shape what lands in each new version:
- ONDEC submissions let stakeholders propose new data elements for ONC's consideration.
- USCDI+ extends the base standard with program-specific additions for use cases like quality reporting.
- The Standards Version Advancement Process, or SVAP, lets developers voluntarily adopt newer versions ahead of a mandated baseline.
Monitoring draft publications and public comment windows is not a compliance courtesy. It is roadmap intelligence that tells you which elements are coming before they become a certification deadline.
Technical Mapping for Engineers: Vocabularies and Syntax
USCDI itself is intentionally syntax-agnostic. It tells you what data to support, not what wire format to use. The applicable certification criterion and its implementation guide decide whether an element must appear as a FHIR resource under US Core, a C-CDA template, or both.
Vocabulary, by contrast, is specific and non-negotiable for most clinical elements. USCDI documentation points developers toward SNOMED CT U.S. Edition, LOINC, and RxNorm as the applicable code systems for most clinical data classes, and terminology versions need active maintenance, not a one-time import.
A few mapping notes that save rework later:
- Build a crosswalk table from internal fields to USCDI elements before writing any transformation code.
- Treat "not available" and "unknown" as distinct, codeable states rather than null values.
- Preserve provenance metadata wherever a criterion or implementation guide requires it.
- Keep a change log tied to terminology version updates, not just code releases.
Legacy data that predates a structured field often needs a one-time backfill project rather than an ongoing pipeline, and it is worth scoping that separately so it does not block your next certification cycle.
Pro Tip: Build your FHIR and C-CDA test samples once, as reusable fixtures, and version them alongside your terminology updates so every certification cycle starts from a known-good baseline.
A Practical Compliance Checklist for Certification Readiness
Teams that treat USCDI as a one-time project tend to redo the same work with every new version. A sequenced approach holds up better.
- Inventory your stored fields and run a gap analysis against the current USCDI element list.
- Identify which certification criteria apply to your product and the syntax or implementation guide each one requires.
- Prioritize elements by engineering effort versus configuration or vocabulary-only updates.
- Stand up terminology services with version control for SNOMED CT, LOINC, and RxNorm.
- Build test artifacts, including C-CDA samples, FHIR bundle examples, and API response fixtures, then schedule your ONC-Authorized Certification Body activities.
- Document a customer update plan that lands inside the Maintenance of Certification delivery window.
A few habits reinforce the sequence:
- Treat terminology updates as a recurring release, not a one-off migration.
- Keep a single source of truth for your USCDI-to-field crosswalk so new engineers do not re-derive it.
- Package USCDI-related fixes with other scheduled updates to reduce how often customers have to upgrade.
Our related guide on ONC certification steps walks through the certification body relationship in more detail, and the quality-reporting implications are covered in our HEDIS performance guide for startups whose USCDI work overlaps with measure reporting.
Practical Tips: Prioritization, Resourcing, and Communication
Small teams rarely have engineering capacity for every USCDI element at once. Prioritize the elements tied directly to the certification criteria your customers actually trigger, then fill in the rest. Fractional clinical leadership can shorten the time it takes to validate a clinical mapping, because someone with direct patient-care context can confirm whether a field like "reason for referral" is being captured the way clinicians actually document it.
Customer communication deserves the same discipline as the engineering work. A short migration note for each release, stating what changed and what the customer needs to do, prevents support tickets from piling up after a Maintenance of Certification update ships.
Pro Tip: Draft your customer-facing release note before the engineering work is finished. Writing it early forces clarity on what actually changed from the customer's point of view.
Why Early USCDI Alignment Shapes Product-Market Fit
Interoperability maturity is a signal enterprise buyers and payers read closely during procurement. A startup that can point to voluntary SVAP adoption ahead of a mandated baseline is telling a buyer, and an investor, that its engineering discipline extends beyond minimum compliance.
We see this come up repeatedly in diligence conversations: certification readiness gets scrutinized the same way clinical outcomes data does. Advisory support that compresses the time between gap analysis and shipped compliance gives a startup more runway to spend on the product decisions that actually differentiate it in a crowded healthcare SaaS market.
— Paul Bergeron MD, MBA
How We Help With USCDI Readiness
We work with healthcare SaaS and digital health teams as a fractional Chief Medical Officer or advisory partner, helping translate USCDI and certification obligations into a roadmap your engineering team can actually execute — an approach exemplified in the Greenwich EMS case study that highlights practical digital health implementation outcomes.
A typical engagement produces a gap report against your current certification criteria, a prioritized implementation roadmap, and customer communication templates for each release. If your team needs clinical judgment alongside the technical mapping, our services page is the place to start that conversation.
FAQ
What USCDI version is required for certification right now?
USCDI v3 is the current baseline for the ONC Health IT Certification Program, adopted through the HTI-1 Final Rule effective January 1, 2026. Developers can voluntarily adopt newer versions ahead of a mandated baseline through the Standards Version Advancement Process.
Does USCDI dictate the exchange syntax I must use?
No. USCDI defines required data content, while the applicable certification criterion and its implementation guide specify whether that content must be represented in FHIR, US Core profiles, or C-CDA templates. Content and syntax are governed separately, which is why teams often map twice: once to USCDI, once to the required format.
How do I find out about upcoming USCDI changes?
ONC publishes draft USCDI versions, typically in January, with final versions following in July, and these are announced through Standards Bulletins. Monitoring these drafts and the ONDEC submission process lets your team weigh in before an element becomes mandatory.
What vocabularies do USCDI elements require?
USCDI documentation points to SNOMED CT U.S. Edition, LOINC, and RxNorm as the applicable vocabulary standards for most clinical data classes. Keeping terminology versions current matters as much as the initial mapping, since outdated code sets can break conformance even when the underlying data model is correct.
Will new USCDI elements always require new engineering work?
Not always. Developer roundtable notes from March 2026 indicate that many proposed elements in newer USCDI versions are already represented in existing implementation specifications, which means a careful gap analysis often turns up fewer net-new engineering tasks than a first read of a draft version suggests.