USCDI is the federal list of health data that certified health IT must be able to share, written in plain language and maintained by ASTP/ONC. US Core is the HL7 FHIR R4 implementation guide that turns that list into profiles, search rules and Must Support obligations, and each US Core release targets one USCDI version: US Core 6.1.0 carries the USCDI v3 certification baseline, and US Core 9.0.0 carries USCDI v6.
Below: the version map copied from the US Core specification, each version's regulatory status as of September 12, 2026, why the two never line up in time, and a method for finding which profile carries a USCDI element. It is for teams planning EHR integration who need to know which version to build to.
Key takeaways
- USCDI answers "what data". US Core answers "how that data looks in FHIR R4". You build and test against US Core, never against USCDI directly.
- The US Core USCDI page maps v1 to US Core 3.1.1 and 4.0.0, v2 to 5.0.1, v3.1 to 6.1.0, v4 to 7.0.0, v5 to 8.0.1 and v6 to 9.0.0.
- The regulatory baseline for certified health IT is USCDI v3 (45 CFR 170.213) with US Core 6.1.0 (45 CFR 170.215). USCDI v1 and US Core 3.1.1 expired for certification on January 1, 2026.
- The 2026 SVAP approved USCDI v6 and US Core 9.0.0 for voluntary certification from August 29, 2026, while the Inferno (g)(10) test kit currently offers US Core 6.1.0 and 7.0.0.
- One USCDI element can land in several profiles. SDOH Assessment maps to four of them.
- CMS payer API rules cross-reference the same 45 CFR 170.215 standards, so payers inherit the version question too.
What is USCDI?
USCDI, the United States Core Data for Interoperability, is "a standardized set of health data classes and constituent data elements for nationwide, interoperable health information exchange," according to the ASTP/ONC Interoperability Standards Platform. It names data, such as Group Number or Progress Note, without saying how to encode it.
A data class groups elements by theme, such as Health Insurance Information or Clinical Notes. The owner is HHS's Assistant Secretary for Technology Policy and Office of the National Coordinator for Health IT (ASTP/ONC; some newer healthit.gov pages say ONC). New elements are proposed through the ONDEC system, and a new version is published roughly every July.
Per the ISP page, USCDI v5 was published July 16, 2024, v6 on July 24, 2025 with 6 new data elements, and v7 on July 23, 2026 with 31 new data elements. There is also a v3.1, which updates v3 by removing or updating the sex, sexual orientation and gender identity elements, consistent with Executive Order 14168.
USCDI becomes binding only when a regulation adopts a version. Today 45 CFR 170.213 lists two: USCDI v1 (July 2020 Errata), whose adoption expired on January 1, 2026, and USCDI v3. Element-level detail lives in our USCDI v3 compliance guide and USCDI v7 developer guide.
What is US Core?
US Core is the HL7 FHIR implementation guide that sets the minimum constraints on FHIR R4 (4.0.1) resources for US data exchange: which profiles exist, which elements are Mandatory or Must Support, which terminology bindings apply, and which searches a server must answer. It is where USCDI becomes something a server returns and a validator checks.
The HL7 Cross-Group Projects work group publishes it. The current release is US Core 9.0.0 (STU 9), dated May 31, 2026, and the editors have updated it annually to meet each new USCDI version.
The guide is explicit about the relationship: "USCDI and FHIR US Core are complementary initiatives, with USCDI defining high-level data requirements and FHIR US Core providing detailed FHIR-based profiles for meeting those requirements." It also notes that many US Core elements map to no USCDI element "because US Core's usage is broader than certification and because additional US Core elements are required to make FHIR implementable." For a profile-by-profile tour, read our US Core implementation guide and our field guide to FHIR profiles, extensions and Must Support.
USCDI vs US Core: what is the difference?
The difference is layer and owner. USCDI is a policy artifact from ASTP/ONC that lists data in plain language. US Core is a technical artifact from HL7 that specifies FHIR profiles, searches and conformance rules for that data. Regulations adopt versions of both, and API conformance is tested against US Core.
| Dimension | USCDI | US Core |
|---|---|---|
| Owner | ASTP/ONC, part of HHS | HL7 International, Cross-Group Projects work group |
| Format | A document of data classes and data elements, with applicable vocabulary standards | A FHIR R4 implementation guide: StructureDefinitions, extensions, value sets, search parameters, CapabilityStatements |
| Purpose | Defines what data must be accessible and exchangeable | Defines how that data is represented, constrained and queried in FHIR |
| Versioning | A new version about every July: v1 (2020) through v7 (2026), plus v3.1 | Annual releases after a January ballot: 3.1.1 (2020) through 9.0.0 (2026) |
| Who must comply | Certified health IT developers through 45 CFR 170.213; CMS-regulated payers through cross-references such as 42 CFR 422.119 | Certified FHIR APIs through 45 CFR 170.215 and 170.315(g)(10); CMS-regulated payer APIs through the same cross-references |
| How it is tested | Not on its own. It is tested through the standards that express it, such as US Core for APIs | Inferno (g)(10) Standardized API test kit, plus profile validation |
Which US Core version maps to which USCDI version?
HL7 publishes the map on the US Core USCDI page. As of US Core 9.0.0, USCDI v1 maps to US Core 3.1.1 and 4.0.0, v2 to 5.0.1, v3.1 to 6.1.0, v4 to 7.0.0, v5 to 8.0.1, and v6 to 9.0.0. The first two columns below are copied exactly from that page.
| USCDI Version | US Core Version | Published (HL7 package history) | Regulatory status as of September 12, 2026 |
|---|---|---|---|
| v1 | 3.1.1 | June 30, 2020 | Adopted at 45 CFR 170.215(b)(1)(i). Adoption expired January 1, 2026. Still the version named in CMS payer API rule text such as 42 CFR 422.119(c)(1) |
| v1 | 4.0.0 (improved Must support guidance) | June 28, 2021 | Not adopted in 45 CFR 170.215 |
| v2 | 5.0.1 | June 22, 2022 | Not adopted in 45 CFR 170.215 |
| v3.1 | 6.1.0 | June 30, 2023 | Adopted at 45 CFR 170.215(b)(1)(ii) with no expiration date. The certification baseline, paired with USCDI v3 |
| v4 | 7.0.0 | May 8, 2024 | Not adopted in regulation. Selectable in the Inferno (g)(10) test kit |
| v5 | 8.0.1 | December 10, 2025 (8.0.0 was June 10, 2025) | Not adopted in regulation |
| v6 | 9.0.0 | May 31, 2026 | Not adopted in regulation. 2026 SVAP approved for 170.315(g)(10), available for voluntary certification from August 29, 2026 |
Sources: the USCDI and US Core columns come from the US Core 9.0.0 USCDI page, publication dates from the US Core version history, and status from 45 CFR 170.215 and the SVAP page.
Four details in that table trip people up:
- Two rows for v1. US Core 4.0.0 added no USCDI content, only clearer Must Support guidance.
- v3.1, not v3. The regulation at 170.213(b) names USCDI v3. The HL7 page labels the 6.1.0 row v3.1, reflecting ASTP/ONC's 2025 update. ASTP/ONC states it is exercising enforcement discretion and issuing certification guidance for certain USCDI v3 data elements, so read that row as the v3 certification baseline and check the ISP page for the affected elements.
- 8.0.1, not 8.0.0. 8.0.1 is a technical correction to the USCDI v5 release.
- No row for USCDI v7 yet. Each January US Core ballot has added the USCDI version published the previous July. If that pattern holds, v7 arrives in the next ballot; treat that as a planning assumption.
Why do USCDI and US Core versions leapfrog each other?
Because four clocks run at different speeds. ASTP/ONC publishes USCDI each July. HL7 ballots a matching US Core the following January and publishes it mid-year. SVAP approves newer versions for voluntary use. Regulation and test tools move last. So the newest, the required and the testable versions are rarely the same.
Follow USCDI v6 through the pipeline. ASTP/ONC published it on July 24, 2025. The US Core 9.0.0 ballot package is dated December 11, 2025 for the January 2026 ballot. HL7 published US Core 9.0.0 on May 31, 2026. ONC announced the 2026 SVAP approvals on June 30, 2026, made them available for voluntary certification on August 29, 2026, and says updated test tools and procedures will follow by December 2026.
Regulation is slower again. The HTI-1 final rule (January 9, 2024) adopted USCDI v3 and US Core 6.1.0 and set January 1, 2026 as the expiry for USCDI v1 and US Core 3.1.1. The result: the mandatory baseline in September 2026 is a 2022 USCDI version expressed in a 2023 US Core release.
| Question | Answer on September 12, 2026 | Where to check |
|---|---|---|
| Newest USCDI | v7, published July 23, 2026 | ISP USCDI page |
| Newest US Core | 9.0.0 (USCDI v6), published May 31, 2026 | US Core version history |
| Required for ONC certification | USCDI v3 with US Core 6.1.0 | 45 CFR 170.213(b) and 170.215(b)(1)(ii) |
| Newest SVAP approval | USCDI v6 and US Core 9.0.0 (2026 SVAP) | healthit.gov SVAP page |
| Selectable in Inferno (g)(10) kit 8.0.7 | US Core 6.1.0 / USCDI v3 and US Core 7.0.0 / USCDI v4 | inferno.healthit.gov |
| Named in CMS payer API rule text | US Core 3.1.1, with approved newer versions permitted | 42 CFR 422.119(c) |
Watch two items. ASTP/ONC proposed the HTI-5 deregulatory rule on December 29, 2025 (HTI-5 fact sheet), and it was still described as proposed on August 4, 2026. The FY2027 IPPS final rule revised 45 CFR 170.215 paragraphs (j), (k), (m) and (n), updating the Da Vinci and CARIN guide versions, but left the USCDI and US Core adoptions untouched.
What does USCDI vs US Core mean for EHR vendors, app developers and payers?
EHR vendors carry a certification duty against specific USCDI and US Core versions. App developers carry no certification duty but inherit whatever each site exposes. Payers regulated by CMS must meet API rules that cross-reference the same federal standards, with their own permission to use newer approved versions.
EHR vendors and certified health IT developers
The 170.315(g)(10) criterion requires a certified API to respond to single-patient requests according to 170.215(a) and (b)(1), "including the mandatory capabilities described in 'US Core Server CapabilityStatement,' for each of the data included in the standards adopted in § 170.213." It adds: "All data elements indicated as 'mandatory' and 'must support' by the standards and implementation specifications must be supported."
US Core adds one more layer. Some elements needed for certification are neither Mandatory nor Must Support, because non-certifying implementers do not need them. The US Core Must Support page calls these Additional USCDI Requirements and states that "Implementers seeking ONC certification SHALL interpret Additional USCDI Requirements as Must Support elements." Because SVAP is voluntary and multiple approved versions are permitted, customer bases split across versions.
App developers
Apps are not certified. You consume whatever certified APIs your customers' EHRs expose, US Core 6.1.0 at minimum today. Build your client to the Must Support rules for requestors: US Core says requestors "SHALL be capable of processing resource instances containing the data elements without generating an error," and SHALL treat missing elements as data not present in the responder's system.
Map by profile, not by vendor. Race, Ethnicity and Tribal Affiliation, for example, each map to the US Core Patient Profile plus a dedicated extension, which our FHIR Patient resource guide covers field by field. For how the major EHR APIs differ on top of US Core, see our EHR integration API comparison.
Payers
For Medicare Advantage organizations, 42 CFR 422.119(c)(1) requires API technology "conformant with 45 CFR 170.215(a)(1), (b)(1)(i), (c)(1), and (e)(1)", and (b)(1)(i) is US Core 3.1.1. Content must follow the standards at 45 CFR 170.213. Paragraph (c)(4) lets payers use an updated version when, among other conditions, the National Coordinator has approved it for the certification program. The CMS-0057-F final rule names US Core 6.1.0 among the updated versions available under that policy.
On April 14, 2026, CMS published proposed rule CMS-0062-P. It acknowledges that US Core 3.1.1 expired on January 1, 2026 and proposes to cross-reference 45 CFR 170.215(b)(1) as a whole, covering all adopted versions. It also proposes extending electronic prior authorization requirements to drugs. Comments closed June 15, 2026, and it is not final. For scoping the payer APIs themselves, see our CMS-0057-F readiness guide and Payer-to-Payer API guide.
Supporting more than one US Core version across customer sites? We build and run EHR integrations for product teams across Epic, Oracle Health, athenahealth, eClinicalWorks, NextGen and others. Talk to our team and we will map which US Core profiles and searches each of your target sites actually exposes.
How do you find which US Core profile carries a USCDI element?
Look it up on the USCDI mapping page of the exact US Core version you build to, then read each listed profile. Mappings are version-specific, one element can map to several profiles, and names differ between USCDI and FHIR, so the wrong version gives confident but wrong answers.
- Find the USCDI element. Note the exact element name and data class on the ISP page for the USCDI version you need.
- Pick your US Core version. The regulatory baseline, an SVAP version, or whatever the target server documents.
- Open that version's USCDI page. For 6.1.0 it is
hl7.org/fhir/us/core/STU6.1/uscdi.html. The unversioned URL always shows the newest release. - Read the profile's Must Support. Check Mandatory, Must Support and Additional USCDI Requirements elements, plus the mandatory searches.
- Confirm in the CapabilityStatement. Make sure the server lists the profile and supports the searches before you write mapping code.
Example 1: insurance group number maps to the US Core Coverage Profile
Group Number sits in the Health Insurance Information data class. The US Core 9.0.0 mapping sends Coverage Status, Coverage Type, Relationship to Subscriber, Member Identifier, Subscriber Identifier and Group Number to the US Core Coverage Profile, and Payer Identifier to both the Coverage and Organization profiles. The 6.1.0 mapping page lists the same Coverage rows.
The Coverage profile says each Coverage must have a member identifier or subscriber id, a status, the beneficiary, the beneficiary's relationship to the subscriber and the payer. It must support coverage type, start or end date, group and plan. The group number lives in Coverage.class with a class type of group. Servers SHALL support GET [base]/Coverage?patient=[id]. This fragment is trimmed from the official US Core 9.0.0 example:
{
"resourceType": "Coverage",
"id": "coverage-example",
"meta": {
"profile": ["http://hl7.org/fhir/us/core/StructureDefinition/us-core-coverage|9.0.0"]
},
"status": "active",
"subscriberId": "888009335",
"beneficiary": { "reference": "Patient/example" },
"relationship": {
"coding": [{ "system": "http://terminology.hl7.org/CodeSystem/subscriber-relationship", "code": "self" }]
},
"payor": [{ "reference": "Organization/acme-payer", "display": "Acme Health Plan" }],
"class": [{
"type": {
"coding": [{ "system": "http://terminology.hl7.org/CodeSystem/coverage-class", "code": "group", "display": "Group" }]
},
"value": "xyz",
"name": "XYZ employee Group Plan"
}]
}One trap from the profile guidance: Coverage.status alone may not tell you whether someone is covered. The guide says to consider Coverage.period too, because coverage can be expired with a status of active.
Example 2: clinical notes map to DocumentReference and DiagnosticReport
The Clinical Notes data class maps to the US Core DocumentReference Profile and the US Core DiagnosticReport Profile for Report and Note Exchange. Imaging Narrative and Procedure Note map to both profiles. Consultation, Discharge Summary, History and Physical, Progress, Operative and Emergency Department notes map to DocumentReference.
The version matters here. The US Core 9.0.0 clinical notes guidance says servers SHALL support at minimum ten common clinical notes, including Progress Note (LOINC 11506-3), Surgical Operation Note (11504-8) and Emergency Department Note (34111-5), plus three DiagnosticReport categories: Cardiology (LP29708-2), Pathology (LP7839-6) and Radiology (LP29684-5). The US Core 6.1.0 guidance lists eight notes, without the surgical operation and emergency department notes. A client built to 9.0.0 that expects those two notes will find gaps on 6.1.0 servers.
GET [base]/DocumentReference?patient=Patient/1137192&category=http://hl7.org/fhir/us/core/CodeSystem/us-core-documentreference-category|clinical-noteOur DocumentReference clinical notes guide covers retrieving the attached content and the vendor differences.
Example 3: an SDOH assessment maps to four profiles, not one
SDOH Assessment sits under Health Status Assessments (named Health Status/Assessments on the 6.1.0 page). Both versions map it to four profiles: US Core Simple Observation, US Core Condition Problems and Health Concerns, US Core Observation Screening Assessment, and US Core QuestionnaireResponse. Which you receive depends on whether the source stored a finding, a problem, a screening answer or the whole questionnaire.
The Observation Screening Assessment profile requires a status, a category code of survey, a LOINC code if available, and a patient. It must support the time, the answer or a reason it is absent, the performer, and the related responses or observations. Here is a trimmed Hunger Vital Sign result from the official US Core 9.0.0 examples, which carries the sdoh category alongside survey:
{
"resourceType": "Observation",
"id": "HVS-item-example-88124-3",
"meta": {
"profile": ["http://hl7.org/fhir/us/core/StructureDefinition/us-core-observation-screening-assessment|9.0.0"]
},
"status": "final",
"category": [
{ "coding": [{ "system": "http://hl7.org/fhir/us/core/CodeSystem/us-core-category", "code": "sdoh", "display": "SDOH" }] },
{ "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "survey", "display": "Survey" }] }
],
"code": {
"coding": [{ "system": "http://loinc.org", "code": "88124-3", "display": "Food insecurity risk [HVS]" }]
},
"subject": { "reference": "Patient/example" },
"effectiveDateTime": "2020-09-10T21:56:54.671000+00:00",
"valueCodeableConcept": {
"coding": [{ "system": "http://loinc.org", "code": "LA19952-3", "display": "At risk" }]
},
"derivedFrom": [{ "reference": "QuestionnaireResponse/hunger-vital-sign-example" }]
}A client that only queries Observation?category=sdoh will miss SDOH problems stored as Condition and full screenings stored as QuestionnaireResponse. Our FHIR Observation resource guide covers the category and code search patterns in depth.
Check what the server says it supports
This trimmed response was captured on September 12, 2026 from the public ONC (g)(10) reference server at inferno.healthit.gov/reference-server/r4/metadata:
{
"resourceType": "CapabilityStatement",
"fhirVersion": "4.0.1",
"implementationGuide": [
"http://hl7.org/fhir/us/core/ImplementationGuide/hl7.fhir.us.core",
"http://hl7.org/fhir/uv/bulkdata/ImplementationGuide/hl7.fhir.uv.bulkdata"
],
"instantiates": [
"http://hl7.org/fhir/us/core/CapabilityStatement/us-core-server",
"http://hl7.org/fhir/uv/bulkdata/CapabilityStatement/bulk-data"
],
"rest": [{
"resource": [{
"type": "Coverage",
"supportedProfile": ["http://hl7.org/fhir/us/core/StructureDefinition/us-core-coverage"]
}]
}]
}Notice what is missing: a version. Profile canonical URLs are identical across US Core releases, and this server appends no |6.1.0 or |7.0.0. The CapabilityStatement shows which profiles and searches exist, not which release they follow; for that, read the developer's API documentation and test real responses. Our guide to reading a FHIR CapabilityStatement goes further.
How is US Core conformance tested for certification?
Through the ONC Certification (g)(10) Standardized API Test Kit, built on the Inferno framework and approved as the test method for 170.315(g)(10). It acts like a real API client and checks SMART App Launch, every US Core profile, the required searches, Must Support elements, profile and reference validation, and multi-patient Bulk Data export.
The hosted test kit page showed version 8.0.7, last updated September 8, 2026. Its session options are US Core 6.1.0 / USCDI v3 or US Core 7.0.0 / USCDI v4, SMART App Launch 2.0.0 or 2.2.0, and Bulk Data 1.0.1 or 2.0.0. The page notes that US Core 7.0.0 should only be used with SMART App Launch 2.0.0 or above because of granular scope requirements. A team that adopts US Core 9.0.0 through the 2026 SVAP should expect testing support to trail approval, since ONC's SVAP page commits to updated test tools by December 2026.
Run the kit early. Our open-source FHIR server passes the (g)(10) Inferno SMART App Launch suite 47 of 47, and we have run SMART on FHIR launches against both the Epic and Oracle Health sandboxes. The lesson from both is the same: the failures that take longest to fix are data-shape failures, not transport failures. Our step-by-step Inferno testing guide walks through a local setup.
Where teams get stuck with USCDI and US Core
Recurring USCDI and US Core problems usually trace back to one of four assumptions. Each looks harmless in design review and becomes a re-mapping and re-test cycle later, often found by a customer or a test lab.
Building to the wrong US Core version
Teams read the newest guide at hl7.org/fhir/us/core, which today is 9.0.0, and build a client that expects ten clinical note types and newer profiles, then connect to servers certified on 6.1.0. Payer teams make the opposite mistake and build to 3.1.1 because the rule text names it, even though that version expired for certification. The cost is a second mapping pass and a new round of validation per site.
Assuming one USCDI element equals one profile
SDOH Assessment spans four profiles, clinical notes span two resources, Payer Identifier spans Coverage and Organization, and several demographics need extensions. A mapping sheet with one profile per row looks complete and silently drops data, usually noticed when a screening result never arrives.
Must Support confusion
Must Support does not mean always present. US Core says responders SHALL NOT include an element when data is absent and the reason is unknown, and SHOULD send a reason code when they know why. Clients that treat Must Support as mandatory crash on sparse records. Servers that skip Additional USCDI Requirements fail certification tests. Both need the same reading of the Must Support page.
Version drift across sites
The same EHR product can behave differently at two customers because of configuration, upgrade timing or SVAP choices, and the CapabilityStatement rarely carries the US Core version. Teams that hard-code one site's behavior end up spending launch time debugging the second site. Our write-up on why FHIR compliant does not mean interoperable covers the vendor-extension side of the same problem.
USCDI and US Core readiness checklist
Use this before you commit a mapping or certification plan.
- Name the US Core version per customer. Record the USCDI and US Core versions for every site or contract, and where the requirement comes from: 45 CFR 170.215, an SVAP choice, a CMS rule or a customer contract.
- Map each USCDI element to profiles. Use that version's USCDI page, and list every profile and extension named for each element, not just the first.
- Populate every Must Support element. Implement all Mandatory and Must Support elements and the SHALL searches, such as
Coverage?patientandDocumentReference?patient&category. - Treat USCDI extras as Must Support. If you certify, handle Additional USCDI Requirements exactly as Must Support elements.
- Handle missing data without errors. Servers omit unknown data and send reason codes when known. Clients process absent elements and data-absent reasons without failing.
- Read each site's CapabilityStatement. Confirm profiles and searches per site, then check the developer's API documentation for the release version.
- Run the Inferno (g)(10) test kit. Select the US Core version you claim, and validate real responses, not only sandbox data.
- Plan the next SVAP version yearly. Put the July USCDI release, the January US Core ballot and the June SVAP announcement on your roadmap calendar.
Need a second pair of eyes on your USCDI and US Core scope? Our healthcare interoperability solutions team builds the FHIR, HL7 and EHR connection layer against the version each site really runs, and our healthcare software product development team builds the product around it. Talk to our team to pressure-test your version plan before you commit a timeline.
