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 Data Elements by a common theme or use case.
A USCDI Data Element is a piece of data defined in USCDI for access, exchange or use of electronic health information.
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.
Harmful or undesired physiological responses associated with exposure to a substance.
Health professional’s conclusions and working assumptions that will guide treatment of the patient.
Information about a person who participates or is expected to participate in the care of a patient.
Narrative patient data relevant to the context identified by note types.
-
- Usage note: Clinical Notes data elements are content exchange standard agnostic. They should not be interpreted or associated with the structured document templates that may share the same name.
Desired state to be achieved by a patient.
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.
Record of vaccine administration.
Analysis of clinical specimens to obtain information about the health of a patient.
Pharmacologic agents used in the diagnosis, cure, mitigation, treatment, or prevention of disease.
Data used to categorize individuals for identification, records matching, and other purposes.
Activity performed for or on a patient as part of the provision of care.
The metadata, or extra information about data, regarding who created the data and when it was created.
Representing a patient’s smoking behavior.
Unique identifier(s) for a patient's implantable device(s).
Physiologic measurements of a patient that indicate the status of the body’s life sustaining functions.
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.
Harmful or undesired physiological responses associated with exposure to a substance.
Health professional’s conclusions and working assumptions that will guide treatment of the patient.
Information about a person who participates or is expected to participate in the care of a patient.
Narrative patient data relevant to the context identified by note types.
-
- Usage note: Clinical Notes data elements are content exchange standard agnostic. They should not be interpreted or associated with the structured document templates that may share the same name.
Non-imaging and non-laboratory tests performed that result in structured or unstructured findings specific to the patient to facilitate the diagnosis and management of conditions.
Tests that result in visual images requiring interpretation by a credentialed professional.
Information related to interactions between healthcare providers and a patient.
Desired state to be achieved by a patient.
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.
Record of vaccine administration.
Analysis of clinical specimens to obtain information about the health of a patient.
Pharmacologic agents used in the diagnosis, cure, mitigation, treatment, or prevention of disease.
Data used to categorize individuals for identification, records matching, and other purposes.
Condition, diagnosis, or reason for seeking medical attention.
Activity performed for or on a patient as part of the provision of care.
The metadata, or extra information about data, regarding who created the data and when it was created.
Representing a patient’s smoking behavior.
Unique identifier(s) for a patient's implantable device(s).
Physiologic measurements of a patient that indicate the status of the body’s life sustaining functions.
USCDI V3
USCDI v3 contains data classes and elements from USCDI v2 and new data classes and elements submitted through the ONDEC system. Please reference the USCDI Version 3 document to the left for applicable vocabulary standards versions associated with USCDI v3 and to the ONC Standards Bulletin 22-2 for more information about the process to develop USCDI v3 and future versions.
Harmful or undesired physiological responses associated with exposure to a substance.
Health professional’s conclusions and working assumptions that will guide treatment of the patient.
Information about a person who participates or is expected to participate in the care of a patient.
Narrative patient data relevant to the context identified by note types.
-
- Usage note: Clinical Notes data elements are content exchange standard agnostic. They should not be interpreted or associated with the structured document templates that may share the same name.
Non-imaging and non-laboratory tests performed that result in structured or unstructured findings specific to the patient to facilitate the diagnosis and management of conditions.
Tests that result in visual images requiring interpretation by a credentialed professional.
Information related to interactions between healthcare providers and a patient.
Desired state to be achieved by a patient.
Data related to an individual’s insurance coverage for health care.
Assessments of a health-related matter of interest, importance, or worry to a patient, patient’s family, or patient’s healthcare provider that could identify a need, problem, or condition.
Record of vaccine administration.
Analysis of clinical specimens to obtain information about the health of a patient.
Pharmacologic agents used in the diagnosis, cure, mitigation, treatment, or prevention of disease.
Data used to categorize individuals for identification, records matching, and other purposes.
Condition, diagnosis, or reason for seeking medical attention.
Activity performed for or on a patient as part of the provision of care.
The metadata, or extra information about data, regarding who created the data and when it was created.
Unique identifier(s) for a patient's implantable device(s).
Physiologic measurements of a patient that indicate the status of the body’s life sustaining functions.
USCDI V4
USCDI v4 added 20 data elements and one data class to USCDI v3. Please reference the USCDI v4 standard document and the ONC Standards Bulletin 23-2 for details. To review the prioritization criteria ONC used to select the USCDI v4 data elements, refer to the ONC Standards Bulletin 22-2.
Harmful or undesired physiological responses associated with exposure to a substance.
Information about a person who participates or is expected to participate in the care of a patient.
Narrative patient data relevant to the context identified by note types.
-
- Usage note: Clinical Notes data elements are content exchange standard agnostic. They should not be interpreted or associated with the structured document templates that may share the same name.
Non-imaging and non-laboratory tests performed that result in structured or unstructured findings specific to the patient to facilitate the diagnosis and management of conditions.
Tests that result in visual images requiring interpretation by a credentialed professional.
Information related to interactions between healthcare providers and a patient.
Physical place of available services or resources.
Desired state to be achieved by a person or a person’s elections to guide care.
Data related to an individual’s insurance coverage for health care.
Assessments of a health-related matter of interest, importance, or worry to a patient, patient’s family, or patient’s healthcare provider that could identify a need, problem, or condition.
Record of vaccine administration.
Analysis of clinical specimens to obtain information about the health of a patient.
An instrument, machine, appliance, implant, software or other article intended to be used for a medical purpose.
Pharmacologic agents used in the diagnosis, cure, mitigation, treatment, or prevention of disease.
Data used to categorize individuals for identification, records matching, and other purposes.
Conclusions and working assumptions that will guide treatment of the patient, and recommendations for future treatment.
Condition, diagnosis, or reason for seeking medical attention.
Activity performed for or on a patient as part of the provision of care.
The metadata, or extra information about data, regarding who created the data and when it was created.
Physiologic measurements of a patient that indicate the status of the body’s life sustaining functions.
USCDI V5
USCDI v5 was published on July 16, 2024, and includes 16 new data elements and two new data classes. Please read the USCDI v5 standard document and the ONC Standards Bulletin 24-2 for details.
Harmful or undesired physiological responses associated with exposure to a substance.
Information about a person who participates or is expected to participate in the care of a patient.
Narrative patient data relevant to the context identified by note types.
-
- Usage note: Clinical Notes data elements are content exchange standard agnostic. They should not be interpreted or associated with the structured document templates that may share the same name.
Non-imaging and non-laboratory tests performed that result in structured or unstructured findings specific to the patient to facilitate the diagnosis and management of conditions.
Tests that result in visual images requiring interpretation by a credentialed professional.
Information related to interactions between healthcare providers and a patient.
Physical place of available services or resources.
Desired state to be achieved by a person or a person’s elections to guide care.
Data related to an individual’s insurance coverage for health care.
Assessments of a health-related matter of interest, importance, or worry to a patient, patient’s family, or patient’s healthcare provider that could identify a need, problem, or condition.
Record of vaccine administration.
Analysis of clinical specimens to obtain information about the health of a patient.
An instrument, machine, appliance, implant, software or other article intended to be used for a medical purpose.
Pharmacologic agents used in the diagnosis, cure, mitigation, treatment, or prevention of disease.
Findings or other clinical data collected about a patient during care.
Provider-authored request for the delivery of patient care services.
Data used to categorize individuals for identification, records matching, and other purposes.
Conclusions and working assumptions that will guide treatment of the patient, and recommendations for future treatment.
Condition, diagnosis, or reason for seeking medical attention.
Activity performed for or on a patient as part of the provision of care.
The metadata, or extra information about data, regarding who created the data and when it was created.
Physiologic measurements of a patient that indicate the status of the body’s life sustaining functions.
Draft USCDI V6
ASTP/ONC published Draft USCDI v6 on January 14, 2025, and proposes to add 6 new data elements. Please read the Draft USCDI v6 standard document and the ASTP Standards Bulletin 25-1 for details. ASTP/ONC is accepting comments here through May 12, 2025, at 11:59 PM ET.
Harmful or undesired physiological responses associated with exposure to a substance.
Information about a person who participates or is expected to participate in the care of a patient.
Narrative patient data relevant to the context identified by note types.
-
- Usage note: Clinical Notes data elements are content exchange standard agnostic. They should not be interpreted or associated with the structured document templates that may share the same name.
Non-imaging and non-laboratory tests performed that result in structured or unstructured findings specific to the patient to facilitate the diagnosis and management of conditions.
Tests that result in visual images requiring interpretation by a credentialed professional.
Information related to interactions between healthcare providers and a patient.
Physical place of available services or resources.
Desired state to be achieved by a person or a person’s elections to guide care.
Data related to an individual’s insurance coverage for health care.
Assessments of a health-related matter of interest, importance, or worry to a patient, patient’s family, or patient’s healthcare provider that could identify a need, problem, or condition.
Record of vaccine administration.
Analysis of clinical specimens to obtain information about the health of a patient.
An instrument, machine, appliance, implant, software or other article intended to be used for a medical purpose.
Pharmacologic agents used in the diagnosis, cure, mitigation, treatment, or prevention of disease.
Findings or other clinical data collected about a patient during care.
Provider-authored request for the delivery of patient care services.
Data used to categorize individuals for identification, records matching, and other purposes.
Conclusions and working assumptions that will guide treatment of the patient, and recommendations for future treatment.
Condition, diagnosis, or reason for seeking medical attention.
Activity performed for or on a patient as part of the provision of care.
The metadata, or extra information about data, regarding who created the data and when it was created.
Physiologic measurements of a patient that indicate the status of the body’s life sustaining functions.
- Represented by a terminology standard or SDO-balloted technical specification or implementation guide.
- Data element is captured, stored, or accessed in multiple production EHRs or other HIT modules from more than one developer.
- Data element is electronically exchanged between more than two production EHRs or other HIT modules of different developers using available interoperability standards.
- Use cases apply to most care settings or specialties.
Level 2
Harmful or undesired physiological responses associated with exposure to a substance.
Material substance originating from a biological entity intended to be transplanted or infused into another (possibly the same) biological entity.
Tests that result in visual images requiring interpretation by a credentialed professional.
Physical place of available services or resources.
Data related to an individual’s insurance coverage for health care.
Record of vaccine administration.
An instrument, machine, appliance, implant, software or other article intended to be used for a medical purpose.
Pharmacologic agents used in the diagnosis, cure, mitigation, treatment, or prevention of disease.
Provider-authored request for the delivery of patient care services.
Data used to categorize individuals for identification, records matching, and other purposes.
Conclusions and working assumptions that will guide treatment of the patient, and recommendations for future treatment.
Condition, diagnosis, or reason for seeking medical attention.
Activity performed for or on a patient as part of the provision of care.
Physiologic measurements of a patient that indicate the status of the body’s life sustaining functions.
- Represented by a terminology standard or SDO-balloted technical specification or implementation guide.
- Data element is captured, stored, or accessed in at least one production EHR or HIT module.
- Data element is electronically exchanged between two production EHRs or other HIT modules using available interoperability standards.
- Use cases apply to several care settings or specialties.
Level 1
Material substance originating from a biological entity intended to be transplanted or infused into another (possibly the same) biological entity.
Narrative patient data relevant to the context identified by note types.
-
- Usage note: Clinical Notes data elements are content exchange standard agnostic. They should not be interpreted or associated with the structured document templates that may share the same name.
Physical place of available services or resources.
Assessments of a health-related matter of interest, importance, or worry to a patient, patient’s family, or patient’s healthcare provider that could identify a need, problem, or condition.
Analysis of clinical specimens to obtain information about the health of a patient.
Pharmacologic agents used in the diagnosis, cure, mitigation, treatment, or prevention of disease.
Data used to categorize individuals for identification, records matching, and other purposes.
The metadata, or extra information about data, regarding who created the data and when it was created.
Physiologic measurements of a patient that indicate the status of the body’s life sustaining functions.
- Not represented by a terminology standard or SDO-balloted technical specification or implementation guide.
- Data element is captured, stored, or accessed in limited settings such as a pilot or proof of concept demonstration.
- Data element is electronically exchanged in limited environments, such as connectathons or pilots.
- Use cases apply to a limited number of care settings or specialties, or data element represents a specialization of other, more general data elements.
Level 0
Harmful or undesired physiological responses associated with exposure to a substance.
Material substance originating from a biological entity intended to be transplanted or infused into another (possibly the same) biological entity.
Information about a person who participates or is expected to participate in the care of a patient.
Narrative patient data relevant to the context identified by note types.
-
- Usage note: Clinical Notes data elements are content exchange standard agnostic. They should not be interpreted or associated with the structured document templates that may share the same name.
Non-imaging and non-laboratory tests performed that result in structured or unstructured findings specific to the patient to facilitate the diagnosis and management of conditions.
Tests that result in visual images requiring interpretation by a credentialed professional.
Information related to interactions between healthcare providers and a patient.
Health data as reflected in a patient's Explanation of Benefits (EOB) statements, typically derived from claims and other administrative data.
Desired state to be achieved by a patient.
Desired state to be achieved by a person or a person’s elections to guide care.
Data related to an individual’s insurance coverage for health care.
Assessments of a health-related matter of interest, importance, or worry to a patient, patient’s family, or patient’s healthcare provider that could identify a need, problem, or condition.
Record of vaccine administration.
Analysis of clinical specimens to obtain information about the health of a patient.
An instrument, machine, appliance, implant, software or other article intended to be used for a medical purpose.
Pharmacologic agents used in the diagnosis, cure, mitigation, treatment, or prevention of disease.
Findings or other clinical data collected about a patient during care.
Provider-authored request for the delivery of patient care services.
Data used to categorize individuals for identification, records matching, and other purposes.
Conclusions and working assumptions that will guide treatment of the patient, and recommendations for future treatment.
Condition, diagnosis, or reason for seeking medical attention.
Activity performed for or on a patient as part of the provision of care.
The metadata, or extra information about data, regarding who created the data and when it was created.
Physiologic measurements of a patient that indicate the status of the body’s life sustaining functions.
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 iletoj on
OCHIN Comments on Draft USCDI V5
Please see attached document for OCHIN's comments on the Draft USCDI v5. Thank you for your consideration.
Submitted by kl161 on
DUHS Comments on USCDI v5
April 15, 2024
Micky Tripathi, Ph.D., M.P.P., National Coordinator for Health IT
Steven Posnack, M.S., M.H.S., Deputy National Coordinator for Health IT
Office of the National Coordinator for Health Information Technology
Office of the Secretary, United States Department of Health and Human Services
Re: Request for Public Comment, Draft United States Core Data for Interoperability (USCDI) v5
Submitted electronically to https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi#draft-uscdi-v5
Dear Dr. Tripathi and Mr. Posnack,
Duke University Health System submits the following comment regarding ONC’s Request for Public Comment on the Draft USCDI v5 posted in January, 2024. Duke University Health System is a world-class hospital and health care network supported by outstanding and renowned clinical faculty, nurses and care teams. Duke's services span the full continuum of care, from primary care to medical and surgical specialties and subspecialties, all dedicated to putting our patients at the forefront of everything we do. Our health system includes three hospitals – Duke University Hospital, Duke Regional Hospital and Duke Raleigh Hospital which serves a diverse population providing serving patients from all over the world.
We welcome the opportunity to review and comment on the proposed USCDI v5.
Knowing a patient’s sexual orientation, gender identity, sex assigned at birth, name used, and pronouns, as well as their anatomical inventory, is necessary in order to provide culturally affirming and responsive health care. Everyone deserves to be treated with respect regardless of gender identity and expression, and ensuring that systems and processes treat all genders equally which also means equitable healthcare.
Collecting SOGI data allows us measure disparities and is essential in providing the highest quality of care to our patients.
We are encouraged by the data elements that are included in USCDI v5 and especially like the addition of “name to use.”
Thank you for the opportunity to comment on USCDI v5. We appreciate your support of SOGI data collection, and collection of pronouns and “name to use,” to improve quality of care and to enhance LGBTQIA+ health equity. Should you have any questions, please contact Kirti P Loper, Program Manager, kirti.loper@duke.edu.
Sincerely,
Kirti P Loper
Program Manager, Employee Experience
Duke University Health System
Submitted by minigrrl on
APHL Comments on USCDI Draft V5
The Association of Public Health Laboratories (APHL) thanks you for the opportunity to provide feedback on draft version 5 of the US Core Data for Interoperability (USCDI). Please see attached document.
Submitted by npujara on
Please see the attached…
Please see the attached comments from the American Academy of Pediatrics on the draft USCDI v5.
Submitted by kballantine on
Phreesia's Comments to USCDI V5
April 15, 2024
Micky Tripathi, Ph.D., M.P.P.
Office of the National Coordinator for Health Information Technology (ONC)
U.S. Department of Health and Human Services
330 C Street SW, 7th Floor
Washington, DC 20201
Re: USCDI Version 5
Dear Dr.Tripathi:
Thank you for the opportunity to provide comments and feedback on data elements for inclusion into United States Core Data for Interoperability (USCDI). Phreesia is the trusted leader in patient activation, giving providers, health plans, life sciences companies and other organizations tools to help patients take a more active role in their care. Founded in 2005, Phreesia enabled more than 150 million patient visits in 2023–more than 1 in 10 visits across the U.S.–scale that we believe allows us to make meaningful impact. Offering patient-driven digital solutions for intake, outreach, education and more, Phreesia enhances the patient experience, drives efficiency, and improves healthcare outcomes. As a routine course of business, we integrate with more than 80% of the U.S. electronic health record (EHR) market.
Core to Phreesia is helping patients take a more active role in their care. As such, underpinning our comments is the desire to capture the patient’s voice as an input and source of truth, where appropriate, in their own medical record. Patients can and should be a contributor to their own EHR.
Recommendation 1: Capture Patient Reported Data
Self-reported data is regarded as the gold standard because some data is most accurately captured from the patient directly, including demographics, social drivers of health, symptoms, and outcomes reporting. A recent study highlights the importance of capturing race and ethnicity data specifically from patients given the high rates of missing information, or worse yet, misclassification found in EHRs today.[1] The USCDI does not require that any data be captured from the patient, nor does it designate the patient, or their representative, as the preferred author for select data. We encourage ONC to require that select, relevant data be captured via the patient while designating other, relevant USCDI data as preferred patient authorship. In parallel, we urge that any patient reported data, whether patient authorship is preferred or mandated, be clearly distinguished from other clinical data. Doing so will appropriately amplify the patient’s voice, ensure patients can be partners in healthcare decisions, and active participants in their care.
Phreesia also supports HL7’s ongoing efforts to improve upon the capture of patient reported outcomes. Phreesia remains steadfast in better linking questions and their responses in patient forms consistently, and in a manner that encourages healthcare organizations to include structures that capture trends over time. This is vital to the successful adoption of patient reported outcome performance measures.
Recommendation 2: Promote Inclusivity, Health Equity, and Better Health Outcomes through Pronoun Capture
We support and applaud ONC’s recommendations to include pronouns in patient demographics and information data. Doing so promotes inclusivity, health equity, and improved health outcomes. We recommend that ONC require capture of pronoun data from patients and leverage a standardized, multiple-select, individual pronouns list to enable patients to select, representative pronouns. In the absence of nationally recognized coding systems, we ask ONC to carefully consider the cardinality of pronoun options to ensure representativeness. In addition to inclusive and multi-select selections lists, we recommend that ONC offer manual data entry options, leveraging affirmative statements such as “I identify as _____” or “My pronoun is _____”.
We would be remiss not to highlight the importance of patient reported data via patient-facing apps, like Phreesia, for this very purpose. Capturing pronoun data directly from the patient via a patient facing-app overcomes apprehension and other sensitivities about asking patients for this information in a setting where the patient may feel a lack of privacy, or experience stigma. Phreesia gives patients the ability to comfortably and securely self-identify in a consistent way while affording ease of integration into various systems of records. Given the value of these data for clinical care, we believe every effort should be made to make the process of self-identification safe and seamless for patients.
Recommendation 3: Enhance Medication Data Elements
Phreesia echoes the joint recommendations submitted by the Centers for Disease Control and Prevention (CDC) and the Centers for Medicare and Medicaid Services (CMS) to further differentiate between active, ordered, administered, and prescribed prescription drugs among the universal data elements. Without this distinction, medication management is extraordinarily difficult. We concur with CMS and the CDC that these changes to USCDI will enhance patient safety, quality improvement, and public health and lead to better patient care through appropriate education and engagement. Given Phreesia’s focus on patient reported data, we also recommend capturing patient reported information on adherence and side effects.
We thank ONC for the continued focus on data standardization and interoperability and appreciate the opportunity to comment. Phreesia is committed to collaborating with ONC and other stakeholders on USCDI. We also look forward to continued evolution of the US Core Implementation Guide to not only ensure the USCDI V5 data elements can be effectively and appropriately utilized, but to ensure use cases keep pace with changes in the delivery of, expectations for, and innovations available in, healthcare. Feel free to contact us for more information on these comments or to serve as a resource going forward.
Sincerely,
Kristen Ballantine
Vice President, Public Affairs
[1] A systematic review. Am J Surg. 2023 Oct;226(4):463-470. doi: 10.1016/j.amjsurg.2023.05.011. Epub 2023 May 18. PMID: 37230870
Submitted by Erin_ORourke_AHIP on
AHIP Comments on USCDI v5
Dear Dr. Tripathi:
AHIP[1] appreciates the Office of the National Coordinator for Health Information Technology’s (ONC) ongoing work to advance the interoperability of health information through the United States Core Data for Interoperability (USCDI). We agree that a common set of data classes and elements is essential to achieving interoperability between consumers, doctors, hospitals, health insurance providers, and other stakeholders. Patients deserve high-quality, equitable, and affordable care delivered by health care providers and health insurance providers who are working together— that includes sharing the data patients and their doctors need to make informed health care decisions. We this goal in mind we are pleased to offer the following comments on the draft USCDI v5.
Data Class: Health Insurance Information
We continue to be concerned that data elements in the Health Insurance Information data class risk exposing personally identifiable information without providing value to consumers. The privacy and security of member data is a paramount responsibility and a major concern for health insurance providers and the consumers they serve. While this information may be robustly protected when held by a physician, hospital, or health insurance provider, the data are outside the reach of the Health Insurance Portability and Accountability Act (HIPAA) once shared through the application programming interfaces (APIs) to third-party applications per the ONC Cures Act Rule or the Centers for Medicare & Medicaid Services Interoperability and Patient Access Rule.
These data elements would provide data about a person’s spouse or parent and where they are employed. Consumers already know this information, but third-party apps could use it to identify someone in a different data set or even re-identify a de-identified data set. Moreover, this sort of detailed benefit information is not clinically relevant and is generally held within the practice management systems for claims processing. There is no verified need for this information to be collected at this level within the electronic health record (EHR).
ONC should remove the following data elements to protect consumer privacy:
- Member identifier,
- Subscriber identifier,
- Relationship to subscriber,
- Group identifier.
To remedy the threats to patient privacy, ONC should retool the Health Insurance Information data class to focus on sharing information that can facilitate patient care, help consumers and healthcare providers understand coverage, assess quality, and understand the impacts of social determinants of health. This more streamlined approach could protect patient privacy while ensuring patients and providers have the data they need. We suggest the Health Insurance Information data class should focus on data elements that are at a higher level to enable an understanding of whether a person has insurance coverage, the type of coverage, and what payer(s) are covering the person. These data elements would allow providers to understand if a person has insurance coverage and the potential implications for care and care transitions, support quality and equity efforts, and help consumers and providers connect with health insurance provider tools for up-to-date information on the coverage of specific services.
In addition, we recommend ONC remove the payer identifier data element as there is no broadly used national standard for this data element. The USCDI should not contain elements that have no associated value set or national standard, but rather only include information that is feasible to collect and has a specific use case.
Data Class: Laboratory
We support the addition of the Test Kit Unique Device Identifier (UDI) data element. We support the Food and Drug Administration’s efforts to promote patient safety through the UDI system and agree the addition of this data element would allow the tracking of important information about the materials used to perform diagnostic tests. While this information is also intended to be captured on the claim, there has been an undue delay in its implementation. Incorporating it in the EHR would facilitate providers with recall efforts of devices when needed even if the payers are not able to obtain the information on the claim.
Data Class: Patient Demographics/Information
AHIP strongly supports ONC’s work to improve the standardization, interoperability, and exchange of information on patient demographics and social determinants of health. We encourage ONC to continue supporting and working with standards development organizations (SDOs) to advance appropriate developing, testing, and implementation of SDoH standards.
We also appreciate the Office of Management and Budget’s work to modernize demographic data. ONC should align with OMB as the agency continue to work towards including additional demographic data elements important to an individuals’ identity, such as Sexual Orientation and Gender Identity (SOGI) and disability status, and the agency’s intent to increase the granularity of race and ethnicity data through additional sub-categories to help organizations capture data that accurately reflects the populations they serve. We greatly appreciate OMB aligning with AHIP’s efforts to improve demographic data standards. ONC, OMB, and SDOs should work together to further enhance demographic data by capturing data source to organization can better understand if data is attested to by the attested to by the individual or assigned by a third party. For example, ONC could consider a new data element under the Provenance data class to capture the origin of demographic data.
We support the addition of the Name to Use, Pronouns, and Interpreter Needed data elements. Adding these data elements would support the provision of person-centered care and could improve care coordination and the ability of health insurance providers to address member’s social needs once interoperability is achieved. We appreciate ONC’s efforts to ensure technology supports the provision of care that recognizes how a person wants to be addressed. In particular, we appreciate that the LOINC codes underlying this data element allow for the use of neopronouns and options such as “only use my name” to allow flexibility and adaptation to meet the needs of all.
Data Class: Provenance
We agree with the importance of this data class and support adding author and author role. As health records become more interoperable and widely shared, it will be important to know and understand who added information to ensure only those who have access to valid data are inputting new information. However, ONC should consider expanding these data elements to, for example, data source, to help verify the information is from an authoritative source. As we note above, knowing if demographic data was collected from a consumer versus an alternate data source would be important in assessing its validity. In addition, ONC should consider other data elements to capture other entities that may add or edit data, especially data that may be pulled together from multiple sources, through the Trusted Exchange Framework and Common Agreement (TEFCA).
Future Directions: Support Digital Quality Measurement
We appreciate ONC’s efforts to coordinate with the Core Quality Measures Collaborative (CQMC) and build on the CQMC’s work when developing the USCDI+ Quality. Aligned measures based on interoperable data have the potential to reduce the burden on clinicians and providers while providing all stakeholders more robust information on performance. We strongly encourage ONC to continue to collaborate with the CQMC when updating the USCDI+ Quality in the future and prioritize the data elements necessary to calculate the CQMC core measures for future versions. However, ONC should also add data elements necessary to calculate digital quality measures in the baseline USCDI to ensure they are available for all payers and health care providers to use.
Additionally, we urge ONC to include data elements for high-value measures beyond CMS programs in the USCDI and the USCDI+ Quality. For example, ONC should add data elements to support the exchange of data to support the National Committee for Quality Assurance (NCQA)’s HEDIS measures to support aligned measures across public and private payers. ONC should also prioritize high-value but high burden measures such as patient experience measures, patient-reported outcomes-based performance measures (PRO-PMs), and social needs screening measures where digital measurement could materially advance their use and facilitate the exchange of person-centered data. Promoting the interoperability of patient-generated data could allow for it to be used across the system while reducing the response burden on patients.
AHIP and its members look forward to working with ONC to continue to advance interoperability to empower patients and support patient care. If you have any questions, please contact me at (202) 778-3246 or at dlloyd@ahip.org.
Sincerely,
Danielle A. Lloyd, MPH
Senior Vice President, Private Market Innovations and Quality Initiatives
[1] AHIP is the national association whose members provide health care coverage, services, and solutions to hundreds of millions of Americans every day. We are committed to market-based solutions and public-private partnerships that make health care better and coverage more affordable and accessible for everyone.
Submitted by mseger1234 on
USCDI v 5 Comments
Dear Dr. Tripathi and Mr. Posniak:
On behalf of UW Health, which is the integrated health system of the University of Wisconsin-Madison, we are pleased to submit comments to this proposal.
Governed by the UW Hospitals and Clinics Authority, UW Health partners with the UW School of Medicine and Public Health to fulfill its patient care, research, education, and community service missions. Over 800,000 patients from the Upper Midwest and beyond are served annually by 1,800+ physicians and 24,000 staff at multiple hospitals (in Wisconsin and Illinois) and over 90 primary care and specialty outpatient clinics.
The Human Rights Campaign has awarded UW Health a 100% score on its Healthcare Equality Index, naming us an LGBTQ+ Healthcare Equality Leader.1 UW Health received perfect scores across all categories, including patient non-discrimination, patient services and support, employee benefits and policies, and patient and community engagement. In addition, UW Health is committed to providing high-quality services through our Gender Services Program, which provides care for transgender, gender expansive, and nonbinary adults and children.2 We are committed to providing quality health care for our LGBTQ+ patients.
While we agree that collecting data on sexual orientation and gender identity (SOGI) is important for many reasons, including understanding and documenting a critical aspect of the patient’s life, fostering honest communication between patient and provider, and showing a patient-centered perspective and culturally competent care, we have some concerns with this specific proposal.
As a threshold matter, we want to ensure that any new SOGI data regime can be integrated into currently used electronic health records (EHR). In UW Health’s case, our current EHR provider does not provide us the capability to allow for fields to be customized or changed, which would need to happen to capture SOGI data as described in the proposal. We are concerned that, given this fact, it will be up to the health system to find ways to make these changes outside of the EHR. Instead, we believe it makes more sense for the EHR providers to be responsible for modifying their software to allow this data to be collected rather than placing the onus on the health system.
We urge you to consider these comments as you proceed with this process. Thank you.
Sincerely,
Alan S. Kaplan, MD
CEO, UW Health
Submitted by kballantine on
Phreesia's Comments to USCDI V5
Please see the attached document with Phreesia's feedback on the Draft USCDI v5. Thank you for your consideration.
Phreesia Comments to USCDI V5 04 15 24.pdf
Submitted by Christina Deuschle on
Biologically Derived Product Data Elements in USCDI Version 5
Submission to Support the Biologically Derived Product Data Elements for Inclusion in the USCDI Version 5
Established to guide the efforts toward the development of a nationwide Red Blood Cell Patient Data Exchange (RBCAX), the RBCAX Working Group includes representatives from multiple federal agencies (NIH, FDA) and HHS OASH offices (OMH, OIDP), the Sickle Cell Disease Association of America, the Association for the Advancement of Blood & Biotherapies, the American Red Cross, the American Society of Hematology, patient representatives, and clinicians, among others.
The HHS-sponsored RBCAX Working Group strongly recommends that ONC consider the Biologically Derived Products (BPD) Data Class, currently in discussion under Level 2, in the USCDI version 5. The Working Group believes this information is critical to patient care and safety and furthers ONC’s prioritization of providing and promoting equitable care. Furthermore, it will allow for the eventual development of a nationwide red blood cell antibody patient data exchange, a greatly needed mechanism for preventing avoidable hemolytic transfusion reactions.
Accurate blood transfusion and historical blood bank laboratory testing information is essential to safely provide care to previously transfused or pregnant patients. People living with sickle cell disease and thalassemia, along with people experiencing childbirth complications requiring blood transfusion represent diverse communities, but disproportionately include historically underserved populations in the United States. The inclusion of the BDP Data Class would enable healthcare providers to better identify and track patients' transfusion histories, thereby supporting efforts to address existing health disparities among frequently transfused patient populations. Moreover, integrating the BDP data class into interoperability requirements aligns with the ONC Health IT Standards Bulletin of January 2024, including the provision of equitable care to underserved communities, by improving care to populations most impacted by blood disorders that require transfusions (https://www.healthit.gov/sites/default/files/page/2024-01/Standards_Bulletin_2024-1.pdf).
Background
Recognition of the need for red blood cell (RBC) antibody patient data exchanges in the United States and internationally has grown in recent decades, as such systems can be used to capture and track data associated with patient transfusion histories, including adverse reactions, alloantibodies, antigens, and special transfusion requirements. The RBC antibody patient data exchange was chosen by the HHS Secretary’s “Challenge on Equity Award,” one of 24 projects selected to advance equity in programs, policies, and processes across HHS. In its second stage, this project is steadily progressing toward the development of an RBCAX pilot plan.
Currently, patient transfusion histories are often inaccessible to providers because they exist in disconnected hospital systems and blood bank registries. This limitation reduces the ability of providers to prevent incompatible transfusions and Delayed Hemolytic Transfusion Reactions (DHTRs), especially for patients who seek transfusion treatment from multiple healthcare facilities or systems. Although patients are screened for antibodies at regular intervals before routine transfusions, previously produced antibodies can evanesce (i.e., disappear over time), making them impossible to detect during screening. Individuals with diseases or conditions that require frequent transfusions are at increased risk for antibody formation and hemolytic transfusion reactions. For example, people living with SCD often require multiple transfusions, and this has resulted in high RBC alloimmunization prevalence rates and higher RBC antibody evanescence rates in this population when compared to others who receive frequent transfusions (Harm et al., 2014; Hendrickson, 2020). Additionally, patients with SCD may need to receive transfusions from multiple hospitals, putting them at higher risks for adverse events. Without standardized accessible patient information, the risk of selecting blood for transfusion that contains antigens against which a patient has historical antibodies against increases, putting patient lives at avoidable risk.
The establishment of a national RBCAX that provides access to real-time transfused patient data is a critical step in preventing adverse patient outcomes and improving equitable access to care. The RBCAX Working Group has determined that the first step to establishing an RBCAX is to integrate standardized RBC antibody information into existing electronic health record (EHR) systems. To accomplish this integration, data must be interoperable. Currently, not all RBC essential data are included in the United States Core Data for Interoperability (USCDI). Consequently, the data are not reflected in the diagnostic codes and data elements used in EHRs. Embedding these data elements into EHR systems is key to the establishment of an RBCAX and requires support and collaboration from agencies, industry, and institutional bodies to define and standardize patient antibody data and build interoperability across hospitals, blood banks, and laboratories. Appropriate changes to the USCDI can support this work, by providing the infrastructure to exchange patient RBC antibody data across hospitals, thus furthering the goal of establishing a national RBCAX.
RBCAX Working Group
Members of the group include representatives from several federal agencies (FDA, NIH) office of the secretary (ONC), and HHS OASH offices (OMH, OWH, OIDP), patient representatives, clinicians, and representatives from EHR vendors. The information provided in the current comment has been endorsed by RBCAX Working Group members, in support of the development of a national RBCAX. Please see table in the attached document for the full working group.
Submitted by AndreaP on
Orders and Laboratory Comments
Thank you for the opportunity to provide comments on Orders (focusing on laboratory orders) and Laboratory Data (focusing on UDIs) in the attached document. I also support comments made by Regenstrief Institute and the Association for Pathology Laboratories (APHL) with further detail about many laboratory data elements. APHL includes requirements of these elements in accord with other regulations and standards.
Laboratory is a complex and challenging area, including electronically capturing, encoding, storing, exchanging and maintaining the data associated with the complete computerized meaning of tests across the healthcare ecosystem. ONC and the HITAC Committees and Taskforces are applauded for their efforts to advance interoperability in this and other areas of healthcare.
USCDI v5 Public Comments APitkus 15Apr24.pdf