Patient Demographics/Information

Data used to categorize individuals for identification, records matching, and other purposes.

Data Element	Applicable Vocabulary Standard(s)
First Name
Last Name
Middle Name (Including middle initial)
Suffix
Previous Name
Date of Birth
Race	Both standards are required The Office of Management and Budget Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity, Statistical Policy Directive No. 15, as revised, October 30, 1997 CDC Race and Ethnicity Code Set Version 1.0 (March 2000) Adopted at 45 CFR 170.207(f)
Ethnicity	Both standards are required The Office of Management and Budget Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity, Statistical Policy Directive No. 15, as revised, October 30, 1997 CDC Race and Ethnicity Code Set Version 1.0 (March 2000) Adopted at 45 CFR 170.207(f)
Birth Sex	Birth sex must be coded in accordance with HL7 Version 3 (V3) Standard, Value Sets for AdministrativeGender and NullFlavor attributed as follows: Female. F Male. M Unknown. nullFlavor UNK Adopted at 45 CFR 170.207(n)
Preferred Language	Request for Comment (RFC) 5646, “Tags for Identifying Languages”, September 2009 Adopted at 45 CFR 170.207(g)
Current Address Includes street name, number, city/town, state, and zip code.
Previous Address Includes street name, number, city/town, state, and zip code.
Phone Number	Both standards are required ITU-T E.123, Series E: Overall Network Operation, Telephone Service, Service Operation and Human Factors, International operation - General provisions concerning users: Notation for national and international telephone numbers, email addresses and web addresses, February 2001 ITU-T E.164, Series E: Overall Network Operation, Telephone Service, Service Operation and Human Factors, International operation - Numbering plan of the international telephone service, The international public telecommunication numbering plan, November 2010 Adopted at 45 CFR 170.207(q)(1)
Phone Number Type
Email Address

Data Element	Applicable Vocabulary Standard(s)
First Name
Last Name
Middle Name (Including middle initial)
Suffix
Previous Name
Date of Birth
Race	Both standards are required The Office of Management and Budget Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity, Statistical Policy Directive No. 15, as revised, October 30, 1997 CDC Race and Ethnicity Code Set Version 1.0 (March 2000) Adopted at 45 CFR 170.207(f)
Ethnicity	Both standards are required The Office of Management and Budget Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity, Statistical Policy Directive No. 15, as revised, October 30, 1997 CDC Race and Ethnicity Code Set Version 1.0 (March 2000) Adopted at 45 CFR 170.207(f)
Sex (Assigned at Birth)	Birth sex must be coded in accordance with HL7 Version 3 (V3) Standard, Value Sets for AdministrativeGender and NullFlavor attributed as follows: Female. F Male. M Unknown. nullFlavor UNK Adopted at 45 CFR 170.207(n)
Sexual Orientation A person’s identification of their emotional, romantic, sexual, or affectional attraction to another person	Sexual orientation must be coded in accordance with SNOMED CT® and HL7 Version 3 Standard, Value Sets for AdministrativeGender and NullFlavor, attributed as follows: Lesbian, gay or homosexual. 38628009 Straight or heterosexual. 20430005 Bisexual. 42035005 Something else, please describe. nullFlavor OTH Don't know. nullFlavor UNK Choose not to disclose. nullFlavor ASKU Adopted at 45 CFR 170.207(o)(1)
Gender Identity A person’s internal sense of being a man, woman, both, or neither.	Gender Identify must be coded in accordance with SNOMED CT® and HL7 Version 3 Standard, Value Sets for AdministrativeGender and NullFlavor, attributed as follows: Male. 446151000124109 Female. 446141000124107 Female-to-Male (FTM)/Transgender Male/Trans Man. 407377005 Male-to-Female (MTF)/Transgender Female/Trans Woman. 407376001 Genderqueer, neither exclusively male nor female. 446131000124102 Additional gender category or other, please specify. nullFlavor OTH Choose not to disclose. nullFlavor ASKU Adopted at 45 CFR 170.207(o)(2)
Preferred Language	Request for Comment (RFC) 5646, “Tags for Identifying Languages”, September 2009 Adopted at 45 CFR 170.207(g)
Current Address Includes street name, number, city/town, state, and zip code.
Previous Address Includes street name, number, city/town, state, and zip code.
Phone Number	Both standards are required ITU-T E.123, Series E: Overall Network Operation, Telephone Service, Service Operation and Human Factors, International operation - General provisions concerning users: Notation for national and international telephone numbers, email addresses and web addresses, February 2001 ITU-T E.164, Series E: Overall Network Operation, Telephone Service, Service Operation and Human Factors, International operation - Numbering plan of the international telephone service, The international public telecommunication numbering plan, November 2010 Adopted at 45 CFR 170.207(q)(1)
Phone Number Type
Email Address

Data Element	Applicable Vocabulary Standard(s)
First Name
Last Name
Middle Name (Including middle initial)
Name Suffix Name component following family name that may be used to describe a person's position in a family.
Previous Name
Date of Birth
Date of Death Known or estimated year, month, and day of the patient's death.
Race	Both standards are required The Office of Management and Budget Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity, Statistical Policy Directive No. 15, as revised, October 30, 1997 CDC Race and Ethnicity Code Set Version 1.2 (July 2021)
Ethnicity	Both standards are required The Office of Management and Budget Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity, Statistical Policy Directive No. 15, as revised, October 30, 1997 CDC Race and Ethnicity Code Set Version 1.2 (July 2021)
Tribal Affiliation
Sex Documentation of a specific instance of sex.	SNOMED International, Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®) U.S. Edition, March 2022 Release
Sexual Orientation A person’s identification of their emotional, romantic, sexual, or affectional attraction to another person	SNOMED International, Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®) U.S. Edition, March 2022 Release
Gender Identity A person’s internal sense of being a man, woman, both, or neither.	Gender Identify must be coded in accordance with SNOMED CT® and HL7 Version 3 Standard, Value Sets for AdministrativeGender and NullFlavor, attributed as follows: Male. 446151000124109 Female. 446141000124107 Female-to-Male (FTM)/Transgender Male/Trans Man. 407377005 Male-to-Female (MTF)/Transgender Female/Trans Woman. 407376001 Genderqueer, neither exclusively male nor female. 446131000124102 Additional gender category or other, please specify. nullFlavor OTH Choose not to disclose. nullFlavor ASKU Adopted at 45 CFR 170.207(o)(2)
Preferred Language	Request for Comment (RFC) 5646, “Tags for Identifying Languages”, September 2009 Adopted at 45 CFR 170.207(g)
Current Address Place where a person is located or may be contacted.	Project US@ Technical Specification for Patient Addresses, Final Version 1.0
Previous Address Prior place where a person may have been located or could have been contacted.	Project US@ Technical Specification for Patient Addresses, Final Version 1.0
Phone Number Numbers and symbols to contact an individual when using a phone.	Both standards are required: ITU-T E.123, Series E: Overall Network Operation, Telephone Service, Service Operation and Human Factors, International operation - General provisions concerning users: Notation for national and international telephone numbers, email addresses and web addresses, February 2001 ITU-T E.164, Series E: Overall Network Operation, Telephone Service, Service Operation and Human Factors, International operation - Numbering plan of the international telephone service, The international public telecommunication numbering plan, November 2010 Adopted at 45 CFR 170.207(q)(1)
Phone Number Type Contact point when using a phone (e.g., home, work, mobile).
Email Address Unique identifier of an individual's email account that is used to send and receive email messages.
Related Person's Name Name of a person with a legal or familial relationship to a patient.
Related Person's Relationship Relationship of a person to a patient. (e.g., parent, next-of-kin, guardian, custodian)
Occupation Type of work of a person. (e.g., infantry, business analyst, social worker)	Occupational Data for Health, version 20201030
Occupation Industry Type of business that compensates for work or assigns work to an unpaid worker or volunteer. (e.g., U.S. Army, cement manufacturing, children and youth services)	Occupational Data for Health, version 20201030

Data Element	Applicable Vocabulary Standard(s)
First Name
Last Name
Middle Name (Including middle initial)
Name Suffix Name component following family name that may be used to describe a person's position in a family.
Previous Name
Date of Birth Known or estimated year, month, and day of the patient's birth.
Date of Death Known or estimated year, month, and day of the patient's death.
Race	Both standards are required The Office of Management and Budget Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity, Statistical Policy Directive No. 15, as revised, October 30, 1997 CDC Race and Ethnicity Code Set Version 1.2 (July 2021)
Ethnicity	Both standards are required The Office of Management and Budget Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity, Statistical Policy Directive No. 15, as revised, October 30, 1997 CDC Race and Ethnicity Code Set Version 1.2 (July 2021)
Tribal Affiliation Tribe or band with which an individual associates.
Sex Documentation of a specific instance of sex.	Both values must be supported: SNOMED CT U.S. Edition: 248152002 (Female) SNOMED CT U.S. Edition: 248153007 (Male)
Preferred Language	IETF (Internet Engineering Task Force) Request for Comment (RFC) 5646, “Tags for Identifying Languages”, September 2009 Adopted at 45 CFR 170.207(g)(2)
Current Address Place where a person is located or may be contacted	Project US@ Technical Specification for Patient Addresses, Final Version 1.0
Previous Address Prior place where a person may have been located or could have been contacted.	Project US@ Technical Specification for Patient Addresses, Final Version 1.0
Phone Number Numbers and symbols to contact an individual when using a phone.	Both standards are required: ITU-T E.123, Series E: Overall Network Operation, Telephone Service, Service Operation and Human Factors, International operation - General provisions concerning users: Notation for national and international telephone numbers, email addresses and web addresses, February 2001 ITU-T E.164, Series E: Overall Network Operation, Telephone Service, Service Operation and Human Factors, International operation - Numbering plan of the international telephone service, The international public telecommunication numbering plan, November 2010 Adopted at 45 CFR 170.207(q)(1)
Phone Number Type Contact point when using a phone (e.g., home, work, mobile).
Email Address Unique identifier of an individual's email account that is used to send and receive email messages.
Related Person's Name Name of a person with a legal or familial relationship to a patient.
Related Person's Relationship Relationship of a person to a patient. (e.g., parent, next-of-kin, guardian, custodian)
Occupation Type of work of a person. (e.g., infantry, business analyst, social worker)	Occupational Data for Health, version 20201030
Occupation Industry Type of business that compensates for work or assigns work to an unpaid worker or volunteer. (e.g., U.S. Army, cement manufacturing, children and youth services)	Occupational Data for Health, version 20201030

Data Element	Applicable Vocabulary Standard(s)
First Name
Last Name
Middle Name (Including middle initial)
Name Suffix Name component following family name that may be used to describe a person's position in a family.
Previous Name
Date of Birth Known or estimated year, month, and day of the patient's birth.
Date of Death Known or estimated year, month, and day of the patient's death.
Race	Both standards are required The Office of Management and Budget Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity, Statistical Policy Directive No. 15, as revised, October 30, 1997 CDC Race and Ethnicity Code Set Version 1.2 (July 2021)
Ethnicity	Both standards are required The Office of Management and Budget Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity, Statistical Policy Directive No. 15, as revised, October 30, 1997 CDC Race and Ethnicity Code Set Version 1.2 (July 2021)
Tribal Affiliation Tribe or band with which an individual associates.
Sex Documentation of a specific instance of sex.	Both values must be supported: SNOMED CT U.S. Edition: 248152002 (Female) SNOMED CT U.S. Edition: 248153007 (Male)
Preferred Language	IETF (Internet Engineering Task Force) Request for Comment (RFC) 5646, “Tags for Identifying Languages”, September 2009 Adopted at 45 CFR 170.207(g)(2)
Current Address Place where a person is located or may be contacted	Project US@ Technical Specification for Patient Addresses, Final Version 1.0
Previous Address Prior place where a person may have been located or could have been contacted.	Project US@ Technical Specification for Patient Addresses, Final Version 1.0
Phone Number Numbers and symbols to contact an individual when using a phone.	Both standards are required ITU-T E.123, Series E: Overall Network Operation, Telephone Service, Service Operation and Human Factors, International operation - General provisions concerning users: Notation for national and international telephone numbers, email addresses and web addresses, February 2001 ITU-T E.164, Series E: Overall Network Operation, Telephone Service, Service Operation and Human Factors, International operation - Numbering plan of the international telephone service, The international public telecommunication numbering plan, November 2010 Adopted at 45 CFR 170.207(q)(1)
Phone Number Type Contact point when using a phone. Examples include but are not limited to home, work, and mobile.
Email Address Unique identifier of an individual's email account that is used to send and receive email messages.
Related Person's Name Name of a person with a legal or familial relationship to a patient.
Relationship Type Relationship of a person to a patient. Examples include but are not limited to parent, next-of-kin, guardian, and custodian.
Occupation Type of work of a person. Examples include but are not limited to infantry, business analyst, and social worker.	Occupational Data for Health, version 20201030
Occupation Industry Type of business that compensates for work or assigns work to an unpaid worker or volunteer. Examples include but are not limited to U.S. Army, cement manufacturing, and children and youth services.	Occupational Data for Health, version 20201030

Data Element	Applicable Vocabulary Standard(s)
First Name
Last Name
Middle Name (Including middle initial)
Name Suffix Name component following family name that may be used to describe a person's position in a family.
Previous Name
Date of Birth Known or estimated year, month, and day of the patient’s birth.
Date of Death Known or estimated year, month, and day of the patient’s death.
Race	Both standards are required The Office of Management and Budget Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity, Statistical Policy Directive No. 15, as revised, October 30, 1997 CDC Race and Ethnicity Code Set Version 1.2 (July 2021)
Ethnicity	Both standards are required The Office of Management and Budget Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity, Statistical Policy Directive No. 15, as revised, October 30, 1997 CDC Race and Ethnicity Code Set Version 1.2 (July 2021)
Tribal Affiliation Tribe or band with which an individual associates.
Sex Documentation of a specific instance of sex.	Both values must be supported: SNOMED CT U.S. Edition: 248152002 (Female) SNOMED CT U.S. Edition: 248153007 (Male)
Preferred Language	IETF (Internet Engineering Task Force) Request for Comment (RFC) 5646, “Tags for Identifying Languages”, September 2009 Adopted at 45 CFR 170.207(g)(2)
Interpreter Needed Indication of whether a person needs language interpretation services.	Logical Observation Identifiers Names and Codes (LOINC) version 2.77 SNOMED Clinical Terms® (SNOMED CT®) U.S. Edition, March 2024 Release
Current Address Place where a person is located or may be contacted. Usage note: If the address pattern is not supported in the standard, implementations should align as closely as possible and avoid truncating any values.	Project US@ Technical Specification for Patient Addresses, Final Version 1.0
Previous Address Prior place where a person may have been located or could have been contacted. Usage note: If the address pattern is not supported in the standard, implementations should align as closely as possible and avoid truncating any values.	Project US@ Technical Specification for Patient Addresses, Final Version 1.0
Phone Number	Both standards are required ITU-T E.123, Series E: Overall Network Operation, Telephone Service, Service Operation and Human Factors, International operation - General provisions concerning users: Notation for national and international telephone numbers, email addresses and web addresses, February 2001 ITU-T E.164, Series E: Overall Network Operation, Telephone Service, Service Operation and Human Factors, International operation - Numbering plan of the international telephone service, The international public telecommunication numbering plan, November 2010 Adopted at 45 CFR 170.207(q)(1)
Phone Number Type Contact point when using a phone. Examples include but are not limited to home, work, and mobile.
Email Address Unique identifier of an individual's email account that is used to send and receive email messages.
Related Person's Name Name of a person with a legal or familial relationship to a patient.
Relationship Type Relationship of a person to a patient. Examples include but are not limited to parent, next-of-kin, guardian, and custodian.
Occupation Type of work of a person. Examples include but are not limited to infantry, business analyst, and social worker.	Occupational Data for Health, version 20201030
Occupation Industry Type of business that compensates for work or assigns work to an unpaid worker or volunteer. Examples include but are not limited to U.S. Army, cement manufacturing, and children and youth services.	Occupational Data for Health, version 20201030

Data Element	Applicable Vocabulary Standard(s)
First Name
Last Name
Middle Name (Including middle initial)
Name Suffix Name component following family name that may be used to describe a person's position in a family.
Previous Name
Date of Birth Known or estimated year, month, and day of the patient’s birth.
Date of Death Known or estimated year, month, and day of the patient’s death.
Race	Both standards are required The Office of Management and Budget Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity, Statistical Policy Directive No. 15, as revised, October 30, 1997 CDC Race and Ethnicity Code Set Version 1.3 May 2025
Ethnicity	Both standards are required The Office of Management and Budget Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity, Statistical Policy Directive No. 15, as revised, October 30, 1997 CDC Race and Ethnicity Code Set Version 1.3 May 2025
Tribal Affiliation Tribe or band with which an individual associates.
Sex Documentation of a specific instance of sex.	SNOMED Clinical Terms (SNOMED CT) U.S. Edition, March 2025 Release Both values must be supported: SNOMED CT U.S. Edition: 248152002 (Female) SNOMED CT U.S. Edition: 248153007 (Male)
Preferred Language	IETF (Internet Engineering Task Force) Request for Comment (RFC) 5646, “Tags for Identifying Languages”, September 2009 Adopted at 45 CFR 170.207(g)(2)
Interpreter Needed Indication of whether a person needs language interpretation services.	Logical Observation Identifiers Names and Codes (LOINC) version 2.80 SNOMED Clinical Terms® (SNOMED CT®) U.S. Edition, March 2025 Release
Current Address Place where a person is located or may be contacted. Usage note: If the address pattern is not supported in the standard, implementations should align as closely as possible and avoid truncating any values.	Project US@ Technical Specification for Patient Addresses, Final Version 1.0
Previous Address Prior place where a person may have been located or could have been contacted. Usage note: If the address pattern is not supported in the standard, implementations should align as closely as possible and avoid truncating any values.	Project US@ Technical Specification for Patient Addresses, Final Version 1.0
Phone Number Numbers and symbols to contact an individual when using a phone.	Both standards are required: ITU-T E.123, Series E: Overall Network Operation, Telephone Service, Service Operation and Human Factors, International operation - General provisions concerning users: Notation for national and international telephone numbers, email addresses and web addresses, February 2001 ITU-T E.164, Series E: Overall Network Operation, Telephone Service, Service Operation and Human Factors, International operation - Numbering plan of the international telephone service, The international public telecommunication numbering plan, November 2010 Adopted at 45 CFR 170.207(q)(1)
Phone Number Type Contact point when using a phone. Examples include but are not limited to home, work, and mobile.
Email Address Unique identifier of an individual's email account that is used to send and receive email messages.
Related Person's Name Name of a person with a legal or familial relationship to a patient.
Relationship Type Relationship of a person to a patient. Examples include but are not limited to parent, next-of-kin, guardian, and custodian.
Occupation Type of work of a person. Examples include but are not limited to infantry, business analyst, and social worker.	Occupational Data for Health, version 20201030
Occupation Industry Type of business that compensates for work or assigns work to an unpaid worker or volunteer. Examples include but are not limited to U.S. Army, cement manufacturing, and children and youth services.	Occupational Data for Health, version 20201030

Data Element
Birth time
Mother's Maiden Name
Identifier
Patient Identifier Type
Deceased Indicator

Data Element
Patient Social Security Number
Patient Marital Status
Patient's Primary Care Provider
Patient Birth Place
Variation in Sex Characteristics

Data Element
Income
Medical Record Number
Multiple Birth Order
Patient Address Use Period
Patient Vital Status
Accommodation
Country of Usual Residence
Organ Donor
Tribal Enrollment
Country of Nationality
HL7-Identifier
<prTag>identifier
<prTag>timestamp
<prTag>status
Rurality

Comment

Submitted by nedragarrett_CDC on 2025-09-29

CDC Supports CMS's Inclusion of a New Veteran Status Element

CDC supports CMS's comment for the inclusion of a new Veteran Status data element to be included in the Patient Demographics and Information data class in Level 2 of USCDI, as it is essential for identifying a high-priority population with unique healthcare needs, supporting care coordination, benefit eligibility, and reducing disparities across care settings.

Submitted by rdillaire on 2025-09-29

CMS-CCSQ Recommends Inclusion of a new Veteran Status element

Recommendation: CMS CCSQ recommends the Veteran Status data element be included in the Patient Demographics/Information data class in Level 2 of USCDI (previously submitted in an ONDEC form).

Rationale: CMS CCSQ is requesting that Veteran Status be added to Level 2 of USCDI under the Patient Demographics/Information data class. Veteran Status is a critical data element that identifies a high-priority population that served in active military, naval, or air service under conditions other than dishonorable discharge, as defined by 13 CFR § 125.11. This data is essential for recognizing the unique healthcare needs of Veterans and their eligibility for specialized programs, such as behavioral health screenings and military toxic exposure evaluations under initiatives like the Promise to Address Comprehensive Toxics (PACT) Act. The inclusion of this data in USCDI would ensure that Veterans receive the necessary care and services, particularly when receiving care outside of Veterans Administration (VA) facilities. This is increasingly important as veterans are more frequently seeking care outside of VA facilities, so identifying Veteran Status is critical for facilitating coordination of care and follow-up. Veteran Status can be captured via patient self-declaration or verified in real time through authoritative, standards-based APIs, such as the VA-Developed Veteran Confirmation API.

Including Veteran Status in USCDI aligns with the broader goals of improving care for underserved populations, as it enables clinicians to tailor interventions to the specific needs of Veterans. By incorporating this data into the Patient Demographics category, providers will be able to leverage it for clinical decision support, such as triggering specialized interventions or referrals. Additionally, it supports administrative workflows like benefit eligibility reporting and quality measure assessments.

The ability to track and stratify Veteran Status ensures that Veterans receive appropriate care regardless of their care setting, whether transitioning from a VA facility to a community hospital or receiving care from multiple providers. This inclusion helps reduce the risks veterans may face from receiving fragmented care across various providers and will also enhance interoperability, ensuring that Veteran Status is accurately exchanged across disparate healthcare systems, promoting coordinated care and continuity.

Technically, Veteran Status is supported by established standards, including the “US Veteran” extension in HL7 FHIR, which enhances interoperability and facilitates the exchange of this data across various healthcare systems. This data element has already been implemented in production environments, such as Epic and Oracle Cerner, proving its broad applicability. By formalizing Veteran Status in USCDI, we not only ensure Veterans receive the care they are entitled to but also support the ongoing efforts to reduce healthcare disparities and improve overall care quality for this underserved population.

Submitted by nachcinformatics on 2024-04-16

Patient Identifying Information

NACHC agrees with the comments listed below. Patient Interpreter, Patient Preferred Name and Patient Pronoun are all key patient-centered concepts that support care teams in understanding and being responsive to patient culture and identity. We agree with the more detailed HL7 comments below.

Patient Demographics/Information: Interpreter Needed [New Data Element]

https://www.healthit.gov/isa/taxonomy/term/7903/draft-uscdi-v5

HL7 agrees that interpreters are needed and should be captured in provider electronic systems (i.e. EMR). Interpreters can assist providers with non-English-speaking patients in reviewing charts, scheduling appointments and care management.

HL7 observes that whether a patient needs an interpreter can also vary based on circumstance. For example, a Spanish-speaking patient that has an appointment with a specialist that only speaks English may need an interpreter. However, if that same patient has an appointment with their primary care physician who speaks Spanish, no interpreter would be necessary. Exchanging the patient’s spoken language proficiency allows systems to determine whether a patient needs an interpreter for specific appointments or encounters based on the language proficiency of the other participants. The spoken language proficiency is the proposed alternative, rather than written language proficiency, as the existing “Preferred Language” data element enables systems to determine what language is preferred for written materials.

HL7 recommends that ONC:

adopt “Spoken Language Proficiency” as a patient demographic.
consider/clarify how “Interpreter Needed” should be used in cases where providers may offer different languages.
clarify how “Interpreter Needed” relates to the existing “Preferred Language” data element.

Patient Demographics/Information: Name to Use [New Data Element]

https://www.healthit.gov/isa/taxonomy/term/4586/draft-uscdi-v5

HL7 supports the inclusion of Name to Use in USCDI. We note that existing HL7 standards already support the exchange of this information.

Additionally, HL7 highlights that payer and provider specific systems may or may not have these Name to Use data elements captured currently. There is notable variance.

Patient Demographics /Information: Pronoun [New Data Element]

https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi#draft-uscdi-v5

HL7 supports the inclusion of Pronouns in USCDI. Our additional recommendations on this issue include recommending ONC:

adopt patient pronouns in USCDI as proposed.
delegate the work of identifying and defining vocabulary standards to consensus-based groups, such as US Core, as the vocabulary standards for this element are relatively new.

Lastly, HL7 observes shared data should not replace a person’s name, but may offer a supplement. Both names and pronoun are not widely used nor included within systems. HL7 recommends that Caregiver(s) should also be included as a source of pronoun information.

Submitted by NCQA on 2023-09-20

NCQA Comment on Pronouns: for USCDI v5

Pronouns:

NCQA supports adding the Pronouns element to USCDI (as proposed by Gender Harmony and represented in LOINC through “Observation: 90778-2 Personal Pronouns – Reported” and “Answer list: LL5144-2 Personal pronouns 1.3.6.1.4.1.12009.10.1.4011”). Understanding which pronoun(s) to use when referring to someone is important for providing affirming health care. It is important to reliably exchange personal pronouns that the individual has specifically reported they want used.

Submitted by yale-coredQMRoadmap on 2023-09-19

CMS-CCSQ Support for OMH's Interpreter Needed for USCDI v5

CMS-CCSQ supports "Interpreter Needed" as a new data element submission by OMH to USCDI v5. The addition of the "Interpreter Needed" data element aligns with ONC’s priorities to enhance health equity and support diverse populations, ultimately improving healthcare quality. The inclusion of this data element addresses the language service needs of historically underserved populations and for those with limited English proficiency. In addition, the element allows the patient to provide essential information for proper care and quality measurement. This data element is currently being collected as part of standardized PAC assessments in the Quality Reporting Program (https://del.cms.gov/DELWeb/pubDataEleDetail?asmtId=4&asmtItmId=A1100A) to inform the need for language access services.

By including the "Interpreter Needed" data element, healthcare providers can better tailor their services to meet the unique linguistic needs of each patient. The integration of this data element into USCDI v5 supports the broader objective of capturing and exchanging nuanced information related to language access services. It primarily elevates individualized care by enhancing patient understanding and the quality of care in the hospital, outpatient care, and post-acute care settings. This data feature also streamlines the referral process and care transitions by offering a standardized format for sharing interpretation requirements, optimizing operational workflows, and enriching the patient experience. In public health epidemiology, it can contribute to disease tracking and facilitate contact tracing efforts. This data element also could be instrumental in health equity studies by providing more precise data on language disparities. Finally, its integration could simplify federal data collection mandates, thereby lessening the administrative load on healthcare facilities.

Submitted by Sokhen472@ on 2022-04-29

Adding Related Person's Name to Patient Demographic Class

Unified Comment on behalf of the Maternal Health Consortium, funded by the Office of the Secretary’s Patient-Centered Outcomes Research Trust Fund (OS-PCORTF)

The rates of maternal mortality have been rising in the United States since 1987. Yet this measure does not capture data related to maternal health. Understanding maternal health before, during, and after childbirth is foundational for developing safer, more effective approaches to maternal care. Clinical data relevant to understanding this trend are not standardized, and data exchange is not interoperable across many relevant settings. Furthermore, maternal health and associated child health are inextricably linked – what happens during gestation, delivery, and after informs health outcomes of both mother and child – but relevant data is often held in separate, unconnected records. These issues impede research on maternal morbidity and longitudinal maternal care and associated impacts to infant health. Research on root causes of maternal mortality, poor outcomes, pediatric developmental problems, and effective treatments requires exchange of information stored in disparate sources, such as electronic health record (EHR) systems, disease registries, and public health agencies (PHAs).

Research use case populations as described in the draft Longitudinal Maternal & Infant Health -FHIR Implementation Guide (https://build.fhir.org/ig/HL7/fhir-mmm-ig/):

Pregnancy and subsequent death within a specific time frame: This cohort includes individuals who died within a year (365 days) of a pregnancy regardless of cause of death or pregnancy outcome.
Hypertensive Disorders of pregnancy: This use case focuses on individuals with a diagnosis of hypertensive disorders of pregnancy.

The Consortium strongly supports the addition of the Related Person’s Name data element to the Patient Demographic Class. The related person relationship is an integral part of pairing mother (individuals who give birth) infant dyad. Exposures in utero to environmental factors, infections, medication, etc. are needed to identify if an event is related to an exposure in pregnancy, postpartum or lactation. In the description of the data element (https://www.healthit.gov/isa/taxonomy/term/2696/draft-uscdi-v3) recommend considering providing an example of the mother infant dyad as a critical, common related person situation.

The "Related Person's Relationship" element and reference the MMM IG's approach to this: https://build.fhir.org/ig/HL7/fhir-mmm-ig/RelatedPerson-relatedperson-jane-smith-example.html.

http://hl7.org/fhir/us/vr-common-library/STU1/StructureDefinition-RelatedPerson-mother-gestational.html

Submitted by phil@analoginfo.com on 2025-09-29

Related Persons - Patient Support Network

Related Person information, including their preferred language, relationship, and scope of data to be shared, is essential to support the patient at all phases of their healthcare.

Related Persons are the people who get the patient to and from their appointments, take care of them when they are at home, and are the first line of those to keep the patient compliant with the care orders from providers. A simple walk through a clinic will see that many patients are accompanied by others. Not capturing and sharing this information puts patients at risk in the case of emergencies.

One of the repeated issues with acute patients is their admission to the ER and there being inconsistent or the complete lack of Related Persons information. A non-communicative patient without related person information has no one to speak for them, to assist the care team regarding their baseline condition, or to provide recent historical information that is critical to proper treatment.

At every phase of interactions with the healthcare system, even the dispensing of drugs at a pharmacy, the related person's information is critical, especially with an aging population that proxies must have for their day-to-day care and may be incapable of communicating their needs or be physically incapable of supporting their own care.

One of the greatest contributions to improving care and reducing costs in the US would be the formalization and requirement of capturing related persons' information in a standard form, and providing this information to every corner of the systems managing patient care.

Submitted by Sokhen472@ on 2022-04-29

Adding Birth Time of Neonate to Date of Birth data element

Unified Comment on behalf of the Maternal Health Consortium, funded by the Office of the Secretary’s Patient-Centered Outcomes Research Trust Fund (OS-PCORTF)

The rates of maternal mortality have not improved in the United States since 1987. Yet this measure does not capture data related to maternal health. Understanding maternal health before, during, and after delivery is foundational for developing safer, more effective approaches to care. Clinical data relevant to understanding this trend are not standardized, and data exchange is not interoperable across many relevant settings. Furthermore, maternal health and associated child health are inextricably linked – what happens during gestation, delivery, and after informs health outcomes of both mother and child – but relevant data is often held in separate, unconnected records. These issues impede research on maternal morbidity and longitudinal maternal care and associated impacts to infant health. Research on root causes of maternal mortality, poor outcomes, pediatric developmental problems, and effective treatments requires exchange of information stored in disparate sources, such as electronic health record (EHR) systems, disease registries, and public health agencies (PHAs).

In use cases for either defining when an event occurred relative to a delivery, having infant birth time identified is critical.

The Consortium recommends adding birth time to the Date of Birth data element in the Patient Demographics data class. Our use cases focus on pregnancy and subsequent death within a specific timeframe and hypertensive disorders of pregnancy (pre, ante, and after pregnancy). The intent is to specify the consistent capture of clinical data of interest to maternal health researchers and outline implementing FHIR resources for that capture. Birth time is already supported in the FHIR interface of major EHR systems such as Cerner https://www.healthit.gov/isa/uscdi-data/birth-time, Epic HL7 Standards Product Brief - HL7 FHIR® Implementation Guide: Vital Records Birth and Fetal Death Reporting, Release 1 - US Realm | HL7 International

Current LRI IG (hl7.org), and the FHIR birth time extension https://www.hl7.org/fhir/extension-patient-birthtime.html

Research use case populations as described in the draft Longitudinal Maternal & Infant Health Information for Research FHIR Implementation Guide (https://build.fhir.org/ig/HL7/fhir-mmm-ig/):

Pregnancy and subsequent death within a specific time frame: This cohort includes individuals who died within a year (365 days) of a pregnancy regardless of cause of death or pregnancy outcome.
Hypertensive Disorders of pregnancy: This use case focuses on individuals with a diagnosis of hypertensive disorders of pregnancy.

In both use cases, the neonate time of birth and the delivery time is important in identifying if an event is related and if the event occurred before delivery or after delivery within a defined time frame. This would allow for defining time of abatement (delivery) and the maternal or infant event.

supporting artifacts, e.g., Abhyankar, S., Lloyd-Puryear, M. A., Goodwin, R., Copeland, S., Eichwald, J., Therrell, B. L., Zuckerman, A., Downing, G., & McDonald, C. J. (2010). Standardizing newborn screening results for health information exchange. AMIA ... Annual Symposium proceedings. AMIA Symposium, 2010, 1–5.

Submitted by Barry Hieb on 2022-10-19

Timestamp

It appears that the addition of a general timestamp data type is needed. We recommend using ISO 8601 (UTC) as a way to capture the time at which an event occurs.

Submitted by ravi.kafle@doh… on 2022-04-29

Addition of Previous Phone Numbers and Email

While USCDI V1 does contain Previous Address which can be very helpful for matching patient records together; two other elements would aid in this regard as well. WA DOH recommends adding previous phone number and email address for the purpose of being able to better identify records belonging to the same patient. This could be useful across data systems as well as in use with a master person index.

Form Guide

1. Optional: Background Text / Cover Letter

The "Optional Background Text / Cover Letter" field provides space for additional context or introductory information related to your comment.

If you wish to provide context, explanation, or an introduction to your comment, enter this information in the field labeled "Optional Background Text / Cover Letter." This is entirely optional and is most useful when submitting multiple related comments or when additional background would help reviewers understand your feedback.

If you are only commenting on a single data class or element, you may leave this field blank.

2. Select the Data Class

To specify which data class your comment addresses:

In the "Data Class" drop-down menu, select the appropriate data class you want to comment on.
If you are providing a general comment that is not specific to a data element, select "General" from the options. Comments with this designation will be displayed on the USCDI landing page.
Note that the Data Class field will automatically populate based on your current location in the platform:
1. If you are on a data class page, the field will be set to that specific data class
2. If you are on a data element page, the corresponding data class will be pre-selected

3. Select the Data Element

To specify which data element your comment addresses:

In the "Data Element" drop-down menu, select the specific data element you want to comment on.
The drop-down menu will display only the elements available under the data class you selected in the previous step.
You can use the search function within the drop-down to quickly locate a specific data element.
If you are commenting on the data class itself rather than a specific element, you may leave this field blank.

Note: Comments on a specific data element will appear on the respective data element page, while comments on a data class (without a specific element selected) will appear on the landing page for that data class.

Fig 1 The "Data Class" and "Data Element" dropdown menus allow users to specify the exact content they wish to comment on.

4. Optional: Propose New Data Class or Element

If you cannot find the appropriate data class or element for your comment:

Instead of clicking the "Comment On An Existing Data Class Or Element" button, click the adjacent button labeled "Propose a New Data Class or Data Element."
This will redirect you to the ONDEC (ONC New Data Element and Class) Submission System.
In the ONDEC system, follow the provided instructions to submit your proposal for a new data class or element.
Once your proposal is submitted through ONDEC, it will be reviewed separately from the commenting process.

Fig 2 The "Propose a New Data Class or Data Element" button redirects users to the ONDEC Submission System for proposing new data elements not currently available in the system.

5. Complete the Comment Form

Fill out the required fields in the comment form:

Subject: Enter a brief, descriptive title that summarizes your comment. This helps reviewers quickly understand the nature of your feedback.

Comment: In this field, provide the full details of your comment or feedback. Be as clear and specific as possible about your suggestions, concerns, or observations. Include any relevant details that support your position.

6. Optional: Add Additional Comments

If you need to comment on multiple data classes or elements:

After completing your first comment, click the link labeled "Comment on another data element" at the bottom of the form.
A new comment section will appear, allowing you to enter details for your additional comment.
For each additional comment, you must select the appropriate data class and data element from the drop-down menus.
Complete the Subject and Comment fields for your additional comment.
Repeat this process for each additional comment you wish to submit.

Fig 3 The "Comment on another data element" link enables users to create multiple comments addressing different elements within a single submission.

7. Optional: Upload Supporting Files

The platform allows you to upload supporting documentation to enhance your comment:

Locate the "File Upload" section at the bottom of the comment form.
Click to upload any files (such as PDFs or documents) that provide additional context, evidence, or clarification for your comment.

Important: If you have already entered your comments using the form fields, there is no need to upload duplicate content in PDF format. The file upload feature is intended for supplementary materials only. Please avoid uploading files that contain the same information already provided in your comment text.

Fig 4 The "File Upload" section permits users to attach supporting documentation that supplements their written comments.

8. Optional: Save and Exit

If you need to pause your work and return to complete your comment later:

Click the "Save and Exit" button at the bottom of the form.
Your comment will be saved as a draft that you can access and complete later.
When you return to the platform, you will see a red triangle with an exclamation mark next to the “Return to saved Comment” button, indicating that you have saved comments in draft status.
Click this button to continue working on your draft.
You will be taken to a review page where you can:
1. Select "Submit Comment" to officially submit your feedback.
2. Click "Edit" to return to the comment form and make changes
3. Select "Discard Draft" to delete the saved draft and start fresh

Fig 5 A red triangle with exclamation mark indicator appears next to the “Return to saved Comment” button when draft comments are saved in the system.

9. Review and Submit

Once you have completed your comment:

Click the "Review and Submit" button at the bottom of the form.
This will take you to a review screen displaying your comment(s) in full.
Review all information for accuracy and completeness.
On this review screen, you have three options:
1. Click "Submit Comment" to officially submit your feedback
2. Click "Edit" to return to the comment form and make changes
3. Click "Discard Draft" to delete the comment and start fresh
The review screen also includes a "Print" button that allows you to create a printed copy of your comments for your records.
If you choose to submit, your comment will be recorded in the system and made available for review by the appropriate stakeholders.

Fig 6 The review screen allows users to verify comment content and make any necessary modifications before final submission.

Data Element

Applicable Vocabulary Standard(s)

Data Element

Applicable Vocabulary Standard(s)

Data Element

Applicable Vocabulary Standard(s)

Data Element

Applicable Vocabulary Standard(s)

Data Element

Applicable Vocabulary Standard(s)

Data Element

Applicable Vocabulary Standard(s)

Data Element

Applicable Vocabulary Standard(s)

Data Element

Data Element

Data Element

Comment

CDC Supports CMS's Inclusion of a New Veteran Status Element

CMS-CCSQ Recommends Inclusion of a new Veteran Status element

Patient Identifying Information

NCQA Comment on Pronouns: for USCDI v5

CMS-CCSQ Support for OMH's Interpreter Needed for USCDI v5

Adding Related Person's Name to Patient Demographic Class

Related Persons - Patient Support Network

Adding Birth Time of Neonate to Date of Birth data element

Timestamp

Addition of Previous Phone Numbers and Email

Add a New Comment

Review comment and Submit

Patient Demographics/Information

Data Element

Applicable Vocabulary Standard(s)

Data Element

Applicable Vocabulary Standard(s)

Data Element

Applicable Vocabulary Standard(s)

Data Element

Applicable Vocabulary Standard(s)

Data Element

Applicable Vocabulary Standard(s)

Data Element

Applicable Vocabulary Standard(s)

Data Element

Applicable Vocabulary Standard(s)

Data Element

Data Element

Data Element

Comment

Help

1. Optional: Background Text / Cover Letter

2. Select the Data Class

3. Select the Data Element

4. Optional: Propose New Data Class or Element

5. Complete the Comment Form

6. Optional: Add Additional Comments

7. Optional: Upload Supporting Files

8. Optional: Save and Exit

9. Review and Submit

USCDI Comments

Add a New Comment

Review comment and Submit