Clinical Decision Support Tools and Examples: A Builder's Guide
What clinical decision support tools exist, how they work in Epic, Oracle Health and OpenEMR, why alert fatigue happens, and how to build CDS with CDS Hooks, FHIR and CQL.
TL;DR
- USCDI is ONC’s list of the data classes and elements certified health IT has to be able to share.
- The version required for certification is v3, with 94 data elements, in force since January 1, 2026.
- ONC has released v4 through v7 since, but none of them is required. Developers can adopt v5 or v6 voluntarily.
- US Core 6.1.0 maps v3 onto FHIR R4 profiles, and the (g)(10) API criterion tests it with Inferno.
- CMS payer rules, TEFCA and state frameworks all point back to the same data set.
If you build an EHR or other health IT system in the US that patient apps, providers or payers pull patient records from, USCDI decides which data your system has to be able to share. Under USCDI v3, the version required today, that’s 94 data elements across classes like patient demographics, medications and vital signs. A patient app that asks for allergies, lab results or clinical notes expects them to be there, and certified EHRs are tested on whether they are.
USCDI lists the data. It doesn’t set the format the data travels in. For APIs, that comes from FHIR and the US Core implementation guide, which map USCDI elements to FHIR profiles you can code against and test. For documents, it comes from C-CDA.
What is USCDI?
USCDI, or United States Core Data for Interoperability, is a standardized set of health data classes and data elements for nationwide health information exchange. The Office of the National Coordinator for Health Information Technology (ONC) maintains it on behalf of the US Department of Health and Human Services (HHS) and publishes a new version every year.
It works at two levels. A data class groups related data by theme, such as Allergies and Intolerances or Patient Demographics/Information. A data element is the smallest piece of data inside a class, such as a patient’s first name or the reaction to an allergen. ONC’s own example is First Name and Last Name. Both sit in Patient Demographics/Information, and both get used for patient matching and for identifying the patient on a document, a lab result or an imaging report.
USCDI came out of the 21st Century Cures Act. In 2020, ONC adopted USCDI v1 as a required standard for its Health IT Certification Program, replacing the older Common Clinical Data Set (CCDS). In October 2026, the HTI-5 final rule removed the CCDS definition from the regulations because nothing referenced it anymore.
USCDI, C-CDA and CCD
USCDI defines the content and leaves the format to other standards. In certification, two formats carry it: FHIR APIs, shaped by US Core, and C-CDA documents, shaped by the C-CDA Companion Guide. For USCDI v3, certified modules had to support the data using US Core 6.1.0 and C-CDA Companion Guide R4.1 by January 1, 2026.
The CCD, or Continuity of Care Document, is older than both. HL7 and ASTM released it in 2007 to combine HL7’s Clinical Document Architecture with the content of ASTM’s Continuity of Care Record. Today it’s one of the document types inside C-CDA, so a CCD is one way to send USCDI data. For more on CDA and the rest of the HL7 family, see What is HL7?
Which USCDI version does certification require?
Certified health IT has to support USCDI v3, even though ONC has published four newer versions since. The gap comes from the difference between releasing a version and adopting it.
How a new version gets made
ONC runs USCDI on a yearly cycle. Anyone can propose a new data element through ONC’s New Data Element and Class (ONDEC) system. ONC publishes a draft in January, takes public comments, and releases the final version in July.
A released version isn’t automatically required. It becomes a certification requirement only when ONC adopts it through rulemaking. Until then, developers can choose to move a certified product up to a newer version through the Standards Version Advancement Process (SVAP).
How the versions have grown
USCDI v1 had 52 data elements in 16 classes. v2, released in July 2021, added three classes: Clinical Tests, Diagnostic Imaging and Encounter Information. By v3, released in July 2022, the total had reached 94 data elements in 19 classes. Each version since has added more:
- v4 (July 2023) added 20 data elements and a new Facility Information class.
- v5 (July 2024) added 16 data elements and two classes, Observations and Orders.
- v6 (July 2025) was a smaller update, adding Facility Address and a broader Unique Device Identifier element among others.
- v7 (July 2026) added 30 data elements, revised Smoking Status into Tobacco and Nicotine Product Use, and created two classes, Adverse Events and Healthcare Information Attributes.
ONC is targeting a draft of v8 for January 2027.
What certification requires today
The HTI-1 final rule made v3 the baseline and retired v1 on January 1, 2026. ONC then held off enforcement until March 1, 2026 for developers still finishing their updates.
In March 2025, ONC paused enforcement on certain v3 data elements, then released USCDI v3.1 without them. The HTI-5 proposed rule in December 2025 would have adopted v3.1 in regulation. The HTI-5 final rule, published October 28, 2026, finalized a narrower set of proposals and left the rest under review. v3 is still the version the regulation names, and the HTI-5 rule itself notes that v6 hasn’t been adopted.
Newer versions are optional. Developers have been able to move to v5 through SVAP since August 29, 2025, and to v6 since August 29, 2026. ONC had proposed requiring v4 in the 2024 HTI-2 proposed rule, but withdrew that proposal in December 2025.
For a certified product today, that means building to v3 on US Core 6.1.0. v5 and v6 are there if you need the newer data, and v7 shows where the requirement is likely to go next.
How does USCDI map to US Core?
USCDI names the data, and US Core says how each element sits in a FHIR resource. HL7 publishes US Core as a set of profiles on FHIR R4, with the required fields, terminology bindings and search operations for each one.
Each US Core release targets one USCDI version. HL7 keeps the current map on its USCDI page:
| USCDI version | US Core version |
|---|---|
| v1 | 3.1.1, 4.0.0 |
| v2 | 5.0.1 |
| v3 and v3.1 | 6.1.0 |
| v4 | 7.0.0 |
| v5 | 8.0.1 |
| v6 | 9.0.0 |
US Core 6.1.0 is the one certification uses. US Core 9.0.0 is the latest published release. The next one, US Core 10.0.0, targets USCDI v7 and is heading to ballot in January 2027.
USCDI v3 classes and their US Core profiles
The table below covers the classes most implementations start with, from the US Core 6.1.0 USCDI page. Profile names drop the “US Core” prefix.
| USCDI v3 data class | US Core 6.1.0 profiles |
|---|---|
| Patient Demographics | Patient, RelatedPerson, Observation Occupation |
| Allergies and Intolerances | AllergyIntolerance |
| Problems | Condition Problems and Health Concerns |
| Medications | MedicationRequest, MedicationDispense, Medication |
| Immunizations | Immunization |
| Laboratory | Laboratory Result Observation, DiagnosticReport for Laboratory Results Reporting, Specimen |
| Vital Signs | Vital Signs and its child profiles (Blood Pressure, Body Weight, Pulse Oximetry and others) |
| Clinical Notes | DocumentReference, DiagnosticReport for Report and Note Exchange |
| Procedures | Procedure, ServiceRequest |
| Care Team Members | CareTeam |
| Encounter Information | Encounter, Condition Encounter Diagnosis |
| Health Insurance Information | Coverage |
| Goals | Goal |
| Provenance | Provenance |
| Unique Device Identifiers | Implantable Device |
The mapping isn’t always one class to one resource. Laboratory data spreads across an Observation for each result, a DiagnosticReport that groups them, and a Specimen. Clinical notes can arrive as a DocumentReference, a DiagnosticReport, or both, which is why US Core has separate clinical notes guidance.
Where SDOH data went in v7
Earlier versions gave social determinants of health their own elements: SDOH Goals, SDOH Problems/Health Concerns and SDOH Interventions. In US Core 6.1.0 these map to Goal, Condition Problems and Health Concerns, and ServiceRequest or Procedure. USCDI v7 folded them into the broader elements Patient Goal, Problem and Procedure as examples. Those are the same profiles the SDOH elements already used in US Core 6.1.0.
How do you build and test for USCDI?
For certified EHRs, USCDI support is tested mostly through §170.315(g)(10), the standardized API for patient and population services. It requires read access to USCDI data over FHIR, for a single patient and in bulk for a population. ONC’s test method for (g)(10) lists the required standards as USCDI v3, US Core 6.1.0, SMART App Launch 2.0.0 and Bulk Data Access 1.0.0.
A build that holds up in testing usually goes in this order:
- Pin your versions: USCDI v3, US Core 6.1.0, SMART App Launch v2 and Bulk Data 1.0.0. Inferno tests against one US Core version at a time.
- Map your data model to the profiles. One record in your database can become several resources, as with a lab panel that becomes a DiagnosticReport, several Observations and a Specimen.
- Populate every Must Support element you hold. When data is missing, follow the US Core rules for saying so rather than leaving the field out.
- Bind codes to the required terminologies, such as SNOMED CT for problems, LOINC for lab tests and RxNorm for medications. Our guide to terminologies in FHIR covers how to serve them.
- Support the searches each profile requires, and declare them in your CapabilityStatement.
- Add Provenance, with at least the author time stamp and author organization.
- Validate against the profiles. A default HAPI FHIR server won’t validate profiles even when
meta.profileis set, so turn validation on before you trust a pass. - Test with Inferno, then certify. An ONC-Authorized Testing Lab runs the tests and an ONC-Authorized Certification Body lists the product on the Certified Health IT Product List (CHPL). Our HTI-4 guide walks through that process in more detail.
What Inferno checks
The Inferno US Core Test Kit tests servers against US Core 3.1.1 through 8.0.0. Its server suites check the CapabilityStatement, every US Core profile, the required searches, Must Support elements, profile and reference validation, and the clinical notes and missing data guidance.
Each of those checks is a place an implementation can fail. Resources that validate but can’t be found through the required searches fail. So do clinical notes that only arrive one way, and empty fields that should have carried a missing-data marker. For the formal certification run, ONC uses the separate (g)(10) test kit. Inferno and the other tools we use are covered in our list of FHIR developer tools.
USCDI and information blocking
USCDI sets the minimum your API has to serve. What you have to share is wider. The information blocking rules were limited to USCDI v1 data until October 6, 2022, and now apply to all electronic health information. We cover what that means for a FHIR implementation in our guide to the 21st Century Cures Act in 2026.
Where else does USCDI apply?
USCDI started as a certification standard, but other federal and state programs now point to it when they need a common data set. If your product touches any of them, the same USCDI and US Core work carries over.
Patient apps are the most visible case. The (g)(10) API is what lets a patient connect an app to their hospital through SMART on FHIR and pull their records as US Core resources. Apple Health is one example, and we walk through how it works in How Apple Health pulls your medical records.
On the payer side, CMS’s Interoperability and Prior Authorization Final Rule (CMS-0057-F) requires the ability to exchange USCDI data elements, and so does the Trusted Exchange Framework and Common Agreement (TEFCA) for network-to-network exchange. What CMS-0057-F asks of health plans by 2027 is covered in What is prior authorization? States use it too. California’s Data Exchange Framework references USCDI for its exchange requirements.
USCDI+ is ONC’s program for data sets that go beyond the core for a specific program or use case. HRSA’s UDS+ reporting for health centers, for example, uses USCDI elements as the base and USCDI+ elements on top. Elements that prove mature in USCDI+ can move into the core. Several of the elements added in USCDI v7 came from USCDI+, including Medication Administration and Healthcare Agent.
Key takeaways
- USCDI decides what data has to be shareable. US Core and the C-CDA Companion Guide decide its format.
- Certification still requires USCDI v3 on US Core 6.1.0. USCDI v3.1 hasn’t been adopted in regulation.
- v5 and v6 are optional upgrades through SVAP, and v7, released in July 2026, is the newest version.
- The (g)(10) criterion is where USCDI support gets tested, and Inferno’s test kits let you run the checks before a lab does.
- The same data set now underpins patient apps, payer APIs under CMS-0057-F, TEFCA and state exchange frameworks.
If you’re working out how to map your data to US Core or support USCDI in your product, talk to us.
Frequently asked questions
What is USCDI?
USCDI, the United States Core Data for Interoperability, is the set of health data classes and data elements that certified health IT in the US has to be able to share. ONC maintains it and publishes a new version every July.
Which USCDI version is required for certification?
USCDI v3, with 94 data elements. The HTI-1 final rule made it the baseline from January 1, 2026, and retired v1 on the same date. Later versions are optional until ONC adopts them through rulemaking.
What is the difference between USCDI and US Core?
USCDI defines which data has to be shareable. US Core is the HL7 implementation guide that maps that data onto FHIR R4 profiles, with required fields, terminologies and searches. Certification uses US Core 6.1.0 for USCDI v3.
What is USCDI v3.1?
USCDI v3.1 is USCDI v3 with certain data elements removed after ONC paused enforcement on them in March 2025. The HTI-5 proposed rule would have adopted it in regulation, but the HTI-5 final rule in October 2026 did not, so v3 is still the version named in the regulation.
What changed in USCDI v7?
USCDI v7, released on July 23, 2026, added 30 data elements and revised Smoking Status into Tobacco and Nicotine Product Use. It also created two data classes, Adverse Events and Healthcare Information Attributes.
How do I test USCDI support in a FHIR API?
Use the Inferno US Core Test Kit to check your server against US Core, including profiles, required searches, Must Support elements and missing data guidance. Formal certification testing for the (g)(10) criterion uses ONC's (g)(10) test kit, run by an ONC-Authorized Testing Lab.
Related articles
View all
Couchbase x Medblocks - Building a NoSQL FHIR Server
We walk you through building a FHIR server on top of Couchbase's NoSQL database, covering challenges, technical decisions, architecture, and local setup.
Three Ways to Build a FHIR Server: Facade, Sync & Hybrid
Explore three approaches to building RESTful FHIR servers: Facade, Synchronization, & Hybrid. Understand where REST APIs, Documents, and Messaging fit in FHIR.
