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 Intolerances
Represents harmful or undesirable physiological response associated with exposure to a substance.
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)
The specific person(s) who participate or are expected to participate in the care team.
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
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 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
Record of an administration of a vaccination or a record of a vaccination as reported by a patient, a clinician, or another party.
Problems
Information about a condition, diagnosis, or other event, situation, issue, or clinical concept that is documented.
Procedures
An activity that is performed with or on a patient as part of the provision of care.
Provenance
The metadata, or extra information about data, that can help answer questions such as when and who created the data.
Smoking Status
Classification of a patient’s smoking behavior.
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).
Vital Signs
Physiologic measurements of a patient that indicate the status of the body’s life sustaining functions.
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)
The specific person(s) who participate or are expected to participate in the care team.
Problems
Information about a condition, diagnosis, or other event, situation, issue, or clinical concept that is documented.
Provenance
The metadata, or extra information about data, that can help answer questions such as when and who created the data.
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.
Problems
Information about a condition, diagnosis, or other event, situation, issue, or clinical concept that is documented.
For data class description and applicable standards supporting data elements, click to view the USCDI Version 1 (July 2020 errata) in PDF format below.
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.
Comment
Submitted by Albert Taylor 
on 2020-10-21
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.Submitted by Steven.Lane on 2020-09-10
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.Submitted by Seikh Bahar on 2020-10-20
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?Submitted by Albert Taylor
on 2020-10-20
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 https://www.hl7.org/fhir/us/core/general-guidance.html.Submitted by dvreeman on 2020-10-23
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.Submitted by Mark Savage on 2020-10-23
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 Mark.Savage@ucsf.edu. Yours truly, Mark Savage Mark Savage Director, Health Policy Center for Digital Health Innovation University of California, San Francisco E. Mark.Savage@ucsf.edu C. 415.225.1676 W. www.CenterforDigitalHealthInnovation.orgSubmitted by sbzemel on 2020-10-23
Submitted by ondec@google.com on 2020-08-31
How should ONDEC submitters flag Required vs Preferred?
Submissions will be going to USCDI ONDEC system: https://healthit.gov/ONDEC 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: https://www.hl7.org/fhir/allergyintolerance.html http://hl7.org/fhir/R4/valueset-allergyintolerance-clinical.html 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: https://www.pharmaceutical-journal.com/learning/learning-article/penicillin-allergy-identification-and-management/20069170.article ) Thank you. Henry Wei MD Google