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 on a person who participates or is expected to participate in the care of 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.

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.

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 on 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.

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.

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.

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 on 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.

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.

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.

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.

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 on 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.

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.

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.

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.

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.

Draft USCDI V5

Draft USCDI v5 includes 13 new data elements and two new data classes. Please reference the Draft USCDI v5 standard document and the Standards Bulletin 2024-1 for details. ONC is accepting feedback on the proposed new data elements on the Draft USCDI v5 website until Monday, April 15, 2024 at 11:59 p.m. ET. Feedback will be considered as ONC develops the final version of USCDI v5, which we anticipate publishing in July 2024.

Harmful or undesired physiological responses associated with exposure to a substance.

Information on a person who participates or is expected to participate in the care of a patient.

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.

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.

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 directive for the delivery of patient care services.

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.

Level 2 data elements meet the following criteria:
  • 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.

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.

Findings or other clinical data collected about a patient during care.

Provider-authored directive for the delivery of patient care services.

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.

Level 1 data elements meet the following criteria:
  • 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.

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.

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.

Level 0 data elements meet the following criteria:
  • 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

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

Information on a person who participates or is expected to participate in the care of a patient.

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

Desired state to be achieved by a patient.

Desired state to be achieved by a person or a person’s elections to guide care.

Analysis of clinical specimens to obtain information about the health of a patient.

Findings or other clinical data collected about a patient during care.

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.

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

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.

Comment

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.

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  

 

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

 

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.

USCDI Public Comment_4_11_Draft.docx

General comments on SOGI v5

Provide an overview of your healthcare facility/system, your patient demographics (including SOGI if possible), and the SOGI data you collect 

Nuvance Health is a regional health system comprised of hospitals, medical practices, care centers and telehealth care located throughout New York’s Hudson Valley and Western Connecticut. We have seven campuses with 1433 licensed beds and over 110 outpatient facilities that employ over 1,300 physicians and almost 14,000 people.  We serve over 1.2 million and provided $96 million in charity care last fiscal year. 

Collecting and using SOGI data is important—improve quality of care, provide culturally responsive care:

• An Important aspect of a patient’s identity, life & well-being

• Honest communication and trust between patient and provider are essential for satisfaction and outcomes

• Conveys cultural responsiveness, that a practice values SGM patients 

• SOGI also relates to a patient’s family structure, support system 

• Part of a patient-centered approach to care for SGM patients 

• Can inform therapeutic and preventive services and screenings

 

Collecting pronouns and name to use will improve care for gender diverse patients:

• SOGI correlates with health disparities in disease burden, risk behaviors, access to care, insurance coverage i.e.: sexual minority women, nulliparity, and cancer 

• SGM disparities in diabetes, cardiovascular disease; SUD, tobacco use 

• Collecting SOGI data a first step toward understanding, addressing, eliminating disparities 

• SDOH affect SGM people in particular ways, especially POC and transgender people 

• SGM people experience widespread social discrimination, which has negative effects on physical and mental health, causes people to avoid or delay seeking health care

In addressing people in the way that they want to be named, it is a step toward addressing past disparities as well as working to practicing person-centered healthcare for all of our colleagues and the communities we serve.

Be well and keep safe,

Mary Shah 

Mary Shah, MLS AHIP

Medical Librarian & Archivist

Medical Library/Norwalk Hospital

 

pronouns: she/her/hers

Hartford Healthcare Comments on Draft USCDI v

On behalf of Hartford Healthcare, please see the attached comments. 

SOGI ONC Public Comment.pdf

Comments on Draft USCDI Version 5

Please see attached for public comments on Draft USCDI v5 submitted by Whitman-Walker Institute, The Fenway Institute, and other healthcare partners. Thank you for your consideration.

WWI USCDI v5 Comment .docx.pdf

duplicate - disregard

duplicate - disregard

Epic's Comments on the Draft USCDI v5

Please see the attached document with Epic's feedback on the Draft USCDI v5. Thank you for your consideration. 

Comments on Draft USCDI v5 - Epic.pdf