Printer Friendly, PDF & Email

United States Core Data for Interoperability (USCDI)

The United States Core Data for Interoperability (USCDI) is a standardized set of health data classes and constituent data elements for nationwide, interoperable health information exchange. Review the USCDI Fact Sheet to learn more.

A USCDI “Data Class” is an aggregation of various Data Elements by a common theme or use case.

A USCDI “Data Element” is the most granular level at which a piece of data is exchanged.

For example, Date of Birth is a Data Element rather than its component Day, Month, or Year, because Date of Birth is the unit of exchange.

USCDI ONC New Data Element & Class (ONDEC) Submission System

To view applicable standards supporting data elements, click the data element name below.

Allergies and Intolerance Allergies and Intolerances Represents harmful or undesirable physiological response associated with exposure to a substance.

Assessment and Plan of Treatment Assessment and Plan of Treatment Represents a health professional’s conclusions and working assumptions that will guide treatment of the patient.

Care Team Member(s) Care Team Member(s) The specific person(s) who participate or are expected to participate in the care team.

Clinical Notes Clinical Notes Composed of both structured (i.e. obtained via pick-list and/or check the box) and unstructured (free text) data. A clinical note may include the history, Review of Systems (ROS), physical data, assessment, diagnosis, plan of care and evaluation of plan, patient teaching and other relevant data points.

Goals Goals An expressed desired health state to be achieved by a subject of care (or family/group) over a period of time or at a specific point of time

Health Concerns Health Concerns Health related matter that is of interest, importance, or worry to someone who may be the patient, patient’s family or patient’s health care provider.

Immunizations Immunizations Record of an administration of a vaccination or a record of a vaccination as reported by a patient, a clinician, or another party.

Problems Problems Information about a condition, diagnosis, or other event, situation, issue, or clinical concept that is documented.

Procedures Procedures An activity that is performed with or on a patient as part of the provision of care.

Provenance Provenance The metadata, or extra information about data, that can help answer questions such as when and who created the data.

Smoking Status Smoking Status Classification of a patient’s smoking behavior.

Unique Device Identifier Unique Device Identifier(s) for a Patient’s Implantable Device(s) A unique numeric or alphanumeric code that consists of a device identifier (DI) and a production identifier (PI).

The USCDI V2 Draft will be prepared for public comment by early 2021. Level 2 data classes/elements will be considered for USCDI V2 Draft based on ONC assessment of a number of factors, including impacts for potential users, maturity of data and technical standards/implementation specifications, burden for implementation, etc.
In addition to “Comment” and “Level 1” criteria, Level 2 data elements demonstrate extensive existing use in systems and exchange between systems, and use cases that show significant value to current and potential users. These data elements would clearly improve nationwide interoperability. Any burdens or challenges would be reasonable to overcome relative to the overall impact of the data elements.

Care Team Member(s) Care Team Member(s) The specific person(s) who participate or are expected to participate in the care team.

Problems Problems Information about a condition, diagnosis, or other event, situation, issue, or clinical concept that is documented.

Provenance Provenance The metadata, or extra information about data, that can help answer questions such as when and who created the data.

Vital Signs Vital Signs Physiologic measurements of a patient that indicate the status of the body’s life sustaining functions.

In addition to “Comment” level criteria, Level 1 data elements demonstrate limited existing use in electronic systems, limited exchange between systems and more well-defined use cases and value to potential users. There may still be some burdens associated with development and implementation.
A data element designated as "Comment" level is represented by health care standard terminology such as SNOMED CT® or implementation specifications such as HL7® FHIR® 4. It may not have a well-defined use case or value to potential users. There may be significant or unknown burdens associated with development or implementation.

For data class description and applicable standards supporting data elements, click to view the USCDI Version 1 (July 2020 errata) in PDF format below. 

Click to View

Previous USCDI Versions

The USCDI ONC New Data Element and Class (ONDEC) Submission System supports a predictable, transparent, and collaborative process, allowing health IT stakeholders to submit new data elements and classes for future versions of USCDI. Click here for more information and to submit new data elements.

The USCDI standard will follow the Standards Version Advancement Process described in the Cures rule to allow health IT developers to update their systems to newer version of USCDI and provide these updates to their customers.


How should ONDEC submitters flag Required vs Preferred?

Submissions will be going to USCDI ONDEC system: How does HHS ONC recommend submitters flag existing FHIR fields for elements, e.g. clinicalStatus for Allergy Intolerance, as recommending a field to be required, rather than preferred? For this Example, see AllergyIntolerance resource and FHIR, and FHIR coding for clinicalStatus: In this example, active = Active, inactive = Inactive, resolved = Resolved. For example, clinically, a significant number of patient labelled as 'penicillin allergic' are not truly allergic to the drug.  As a result, these antibiotics can be withheld unnecessarily.  (ref: ) Thank you. Henry Wei MD Google

flags for submissions

USCDI data elements refer to a system's ability to capture and share a data element.  The referenced flag of "clinical status" would be represented as a unique data element associated with another data element, such as Allergy/Intolerance.  A similar data element, "Medication Usage", has been submitted through ONDEC, to address one aspect of medication status.  ONC would consider a clinical status data element which could be applied to Allergy/Intolerance, but may also be applicable to other classes/elements like Problems, Health Concerns.

Related data suggestion

While we are considering the addition of Ophthalmic Data I would suggest adding the date that a dilated diabetic eye exam was performed.  This is a very important data element for diabetes disease management for individuals and populations as well as for quality reporting.

USCDI to FHIR Resource Mapping Guide

Hi. Will there be a data spec/map be published to show how data elements are mapped to FHIR resources? 

As USCDI v2 develops, we…

As USCDI v2 develops, we anticipate work will be done to update the mapping from USCDI data elements to US Core Profiles and FHIR resources.  The current mapping of these can be found at

Proposal for precise modeling of entities in the USCDI

The USCDI V1 is a landmark specification of core clinical data for nationwide exchange. Recognizing USCDI's significant promise for directing future interoperability efforts, we seek to improve its foundation for continued expansion. In particular, we believe that improving the clarity of USCDI entity definitions (e.g. Data Class, Data Element) are necessary for the industry to interpret them consistently. We seek to add precision to their specifications to enable a principled approach for users to understand, implement, extend, and refine them with future submissions for new USCDI content. To that end, we submit these recommendations, which includes a proposed model that is described in the accompanying appendix.
Proposal for precise modeling of entities in the U.S. Core Data for Interoperability - Version 1.0.pdf

UCSF Center for Digital Health Innovation's Comment on USCDI

Dear Dr. Rucker: The University of California, San Francisco’s Center for Digital Health Innovation provides the attached comments on new data classes and elements for version 2 of the U.S. Core Data for Interoperability.  We appreciate the considerable work that ONC has devoted to the Common Clinical Data Set (CCDS) and its next evolution, the U.S. Core Data for Interoperability version 1.  Version 1, however, was only a “modest expansion” of the Common Clinical Data Set.   As a health care provider, we urge ONC to add numerous additional data elements now so that they, too, become available for better health care, for key national use cases such as COVID-19 and virtual care, and for the nationwide learning health system we need.  According to ONC, technical specifications are already available for 46 of 50 data classes ONC listed for candidate and emerging status, and all 50 are “critical to achieving nationwide interoperability.” To illustrate the importance of adding the missing data elements now, we tested them against two COVID-19 use cases and asked which missing structured data elements are necessary or important now for health care in the midst of the COVID-19 pandemic.  Not surprisingly, most were necessary or important. If you or your staff have any thoughts or questions about these comments, please feel free to contact me at Yours truly,   Mark Savage   Mark Savage Director, Health Policy Center for Digital Health Innovation University of California, San Francisco   E. C. 415.225.1676 W.

Support for the Gravity Project's submission on SDOH

Please see the attached letter for Providence St. Joseph Health's support to the Gravity Project's submission for two approaches for including social determinants of health data in the USCDI.
PSJH Gravity support USCDI 10-23-20.pdf