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

USCDI V1

Please reference the USCDI version 1 document to the left for applicable standards versions associated with USCDI v1.

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.

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 Representing 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).

USCDI V2

The USCDI v2 contains data classes and elements from USCDI v1 and new data classes and elements submitted through the ONDEC system. Please reference the USCDI Version 2 document to the left for applicable vocabulary standards versions associated with USCDI v2 and to the ONC Standards Bulletin 21-3 for more information about the process to develop USCDI v2 and future versions.

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 Represents narrative patient data relevant to the respective note types.

Clinical Tests Includes non-imaging and non-laboratory tests performed on a patient that results in structured or unstructured (narrative) findings specific to the patient, such as electrocardiogram (ECG), visual acuity exam, macular exam, or graded exercise testing (GXT), to facilitate the diagnosis and management of conditions.

Diagnostic Imaging Tests that result in visual images requiring interpretation by a credentialed professional.

Encounter Information An episode defined by an interaction between a healthcare provider and the subject of care in which healthcare-related activities take place.

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 Representing 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).

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.

Level 2

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

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

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.

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.

Level 1

Biologically Derived Product Material substance originating from a biological entity intended to be transplanted or infused into another (possibly the same) biological entity.

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.

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.

Comment

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.

Biologically Derived Product Material substance originating from a biological entity intended to be transplanted or infused into another (possibly the same) biological entity.

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

Diagnostic Imaging Tests that result in visual images requiring interpretation by a credentialed professional.

Encounter Information An episode defined by an interaction between a healthcare provider and the subject of care in which healthcare-related activities take place.

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

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.

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

uscdi-v1

Click to View USCDI V1

Previous USCDI Versions

uscdi-previous-version

Click to View USCDI V2

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

Do you intend the USCDI to support a multiaxial heirarchy?

If you make Orders a Data Class, then you need to decide if you will allow notions to be categorized in more than one place or not.  For example, orders for laboratory, pathology, and diagnostic imaging tests, should those data elements be covered in those respective data classes, or should those data elements be shown within the Orders data class?  Or should they show in both places?

Do you intend the USCDI to support a multiaxial heirarchy?

If you make Orders a Data Class, then you need to decide if you will allow notions to be categorized in more than one place or not.  For example, orders for laboratory, pathology, and diagnostic imaging tests, should those data elements be covered in those respective data classes, or should those data elements be shown within the Orders data class?  Or should they show in both places?

Do you intend the USCDI to support a multiaxial heirarchy?

If you make Orders a Data Class, then you need to decide if you will allow notions to be categorized in more than one place or not.  For example, orders for laboratory, pathology, and diagnostic imaging tests, should those data elements be covered in those respective data classes, or should those data elements be shown within the Orders data class?  Or should they show in both places?

Pathology reports

This field is for general comments on the USCDI. I think you should reconsider having Pathology reports as part of this data set.  One part of the elements says that it should be easily read and understood, neither of which a pathology report is.  I know version two is just moving them from clinical notes to their own pathology category, but I feel these are reports that can cause a patient to panic and then maybe not be able to get into their provider right away.  Please reconsider these being part of the set. Thank you.

Allegheny Health Network comments on proposed USCDI v2

General Overview: Allegheny Health Network (www.AHN.org), a Highmark Health company, is an integrated healthcare system serving the greater Western Pennsylvania region. The Network is composed of thirteen hospitals, including Allegheny General Hospital, its flagship academic medical center in Pittsburgh. AHN has several nationally recognized programs, over 20,000 employees and nearly 2500 physicians. Highmark Health is one of the largest Blue Cross Blue Shield providers serving patients in multiple states across the US. AHN respectfully submits comments for the USCDI version 2 edition. Care Team: In a broad sense, a provider of care can be defined as any licensed individual delivering care to patients. As such, our organization lists all independently licensed individuals or appropriately licensed organizations on the "Care Team" only as defined by our technology. We are asking for clarification on the definition of Provider Name as it is related to their licensure status. Additionally, if we presume these are independently licensed providers of care (MD, DO, or others), we would ask the provider identifier be the NPI (National Provider Identifier). Our rationale for this request is that all providers of care on our Care Teams are independently licensed and have a NPI must have their digital address published in their NPPES account. Encounter Information: There are numerous encounter types for which patients interact with our healthcare system. Many of these encounters include brief non-face to face encounters (e.g., telephone or electronic message) for which defining an encounter diagnosis or even an encounter time may be problematic especially in the case of electronic messaging. As well, some of these encounters may not carry information important to the delivery of care and clutter the information gathering for patients. We believe all appropriate encounters should be included in the data collected. Given the broadening of patient care delivery opportunities today to include a multitude of these types of encounters would be difficult. Additionally, the inclusivity of certain clinical note types in these same encounters carries these same concerns as well.  We recommend specific definition around these encounter types where care decisions are made. With this specific definition, we also recommend only the clinical notes generated by these encounters be included in the release to patients for now. Problems: There will seemingly be a debate on the inclusion of problems vs. diagnoses. We do not wish to enter the debate on this but believe there will be elements which are self-limited diagnoses for which some believe these should not be included on the problem list. These are contrasted with those elements where repeated care is delivered for chronic conditions and should be entered on the patient's problem list. If all diagnoses entered by the providers should be on the problem list, then this should be stated and adhered to so patient's data across multiple encounters, across multiple providers, and across multiple health systems will be useful. Therefore clarification from the committee should include this information. Diagnostic Imaging: We applaud the creation of a Diagnostic Imaging section similar to the section on laboratory values. The following subsections create the question. We interpreted the definition of Imaging Narrative in the USCDIv1 which is described under the rule as LOINC 18748-4. LOINC 18748-4 is defined as follows: "Diagnostic Imaging Report (DIR) contains a consulting specialist's interpretation of image data. It conveys the interpretation to the referring (ordering) physician and is for use in Radiology, Endoscopy, Cardiology, and other imaging specialties." The USCDIv2 contains the addition of Diagnostic Imaging Report (LOINC search revealed a panel of codes at 72230-6). We are asking for clarification and specifically the difference in the definitions between Diagnostic Imaging Narrative and Diagnostic Imaging Report and the appropriate LOINC coding between these 2 elements. We also find the LOINC code 18782-3, "Radiology Study observation (narrative) which was not mentioned in any of the imaging reporting elements. Please comment.

Pew Charitable Trusts USCDI V2 Comments

Thank you for soliciting comments on the Office of the National Coordinator for Health Information Technology’s (ONC) standard data set for exchange. The United States Core Data for Interoperability (USCDI) will reduce burdens associated with data exchange, ensure both patients and providers receive standard and complete data in real-time, and has the potential to allow for seamless exchange of vital clinical information to public health agencies during crises like the COVID-19 pandemic. Overall, however, USCDI version 2 represents a missed opportunity by the agency to accelerate the comprehensive, standard exchange of data—including information needed for public health action. When finalizing the proposed version, ONC should ensure the USCDI includes data needed for public health and health equity, which can help public health agencies fight the current pandemic—and be better prepared for future crises.   USCDI version 2 is an opportunity to ensure data needed for patient care and public health activities are included within standards for exchange. The COVID-19 pandemic has highlighted the existing gaps in current mechanisms for data exchange, both between health care facilities and with public health agencies. A comprehensive USCDI could help close these gaps and ensure complete, standardized data can be seamlessly shared with those who need it. Please see the attached letter for further detail.   Thank you.

Pew Letter to ONC on USCDI April 1 2021.pdf

Comments for Draft USCDI V2

Quest Diagnostics, Incorporated collaborated with the American Clinical Laboratory Association (ACLA) to develop USCDI V2 comments (http://www.acla.com/).  We support the comments submitted by ACLA.  Thank you for the opportunity to provide comments.

USCDI v2 comments

GE Healthcare shares the commitment of the goals of Office of the National Coordinator to improve Health IT. We submit the attached comments in support of that shared goal.

USCDI v2 public comment GE Healthcare.pdf

USCDI v2 Comments

Thank you for the opportunity to provide comments. GE Healthcare shares the commitment of the goals of Office of the National Coordinator to improve Health IT. We submit the attached comments in support of that shared goal.

USCDI v2 public comment GE Healthcare_0.pdf

Cerner Corporation USCDI Draft V2 Comments

Please find attached Cerner Corporation's public comments on the USCDI draft version 2. Cerner supports and appreciates ONC's hard work in the creation of the USCDI draft version 2 and the ONC New Data Element and Class (ONDEC) submission system and process for ongoing annual expansion. We believe our experience and position in the health IT industry provides us with valuable insight in this subject area and are grateful for the opportunity to share it.

Cerner Corporation USCDI Draft V2 Public Comments.pdf