Printer Friendly, PDF & Email Printer Friendly, PDF & Email

§170.315(a)(5) Patient demographics and observations

Updated on 03-11-2024
Regulation Text
Regulation Text

§ 170.315 (a)(5) Patient demographics and observations—

  1. Enable a user to record, change, and access patient demographic and observations data including race, ethnicity, preferred language, sex, sex parameter for clinical use, sexual orientation, gender identity, name to use, pronouns and date of birth.
    1. Race and ethnicity. 
      1. Enable each one of a patient's races to be recorded in accordance with, at a minimum, the standard specified in § 170.207(f)(3) and whether a patient declines to specify race.
      2. Enable each one of a patient's ethnicities to be recorded in accordance with, at a minimum, the standard specified in § 170.207(f)(3) and whether a patient declines to specify ethnicity.
      3. Aggregate each one of the patient's races and ethnicities recorded in accordance with paragraphs (a)(5)(i)(A)(1) and (2) of this section to the categories in the standard specified in § 170.207(f)(1).
    2. Preferred language. Enable preferred language to be recorded in accordance with the standard specified in § 170.207(g)(2) and whether a patient declines to specify a preferred language.
    3. Sex.  Enable sex to be recorded in accordance with the standard specified in § 170.207(n)(1) for the period up to and including December 31, 2025; or § 170.207(n)(2).
    4. Sexual orientation.  Enable sexual orientation to be recorded in accordance with, at a minimum, the version of the standard specified in § 170.207(o)(1) for the period up to and including December 31, 2025; or § 170.207(o)(3), as well as whether a patient declines to specify sexual orientation.
    5. Gender identity.  Enable gender identity to be recorded in accordance with, at a minimum, the version of the standard specified in § 170.207(o)(2) for the period up to and including December 31, 2025; or § 170.207(o)(3), as well as whether a patient declines to specify gender identity.
    6. Sex Parameter for Clinical Use. Enable at least one sex parameter for clinical use to be recorded in accordance with, at a minimum, the version of the standard specified in § 170.207(n)(3). Conformance with this paragraph is required by January 1, 2026.
    7. Name to Use. Enable at least one preferred name to use to be recorded. Conformance with this paragraph is required by January 1, 2026.
    8. Pronouns. Enable at least one pronoun to be recorded in accordance with, at a minimum, the version of the standard specified in § 170.207(o)(4). Conformance with this paragraph is required by January 1, 2026.
  2. Inpatient setting only. Enable a user to record, change, and access the preliminary cause of death and date of death in the event of mortality.
Standard(s) Referenced

Paragraph (a)(5)(i)(A)

§ 170.207(f)(1) 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

§ 170.207(f)(2) CDC Race and Ethnicity Code Set Version 1.0 (March 2000) (Adoption of this standard expires on January 1, 2026)

§ 170.207(f)(3) CDC Race and Ethnicity Code Set Version 1.2 (July 15, 2021) (This standard is required by December 31, 2025)

Paragraph (a)(5)(i)(B)

§ 170.207(g)(2) Request for Comment (RFC) 5646, “Tags for Identifying Languages”, September 2009

Paragraph (a)(5)(i)(C)

§ 170.207(n)(1) Birth sex must be coded in accordance with HL7® Version 3 Standard, Value Sets for AdministrativeGender and NullFlavor attributed as follows:

  1. Male. M
  2. Female. F
  3. Unknown. UNK

(Adoption of this standard expires on January 1, 2026)

§ 170.207(n)(2) Sex must be coded in accordance with, at a minimum, the version of SNOMED CT® U.S. Edition codes specified in § 170.207(a)(1) (This standard is required by December 31, 2025.) 

Paragraphs (a)(5)(i)(D) and (E)

§ 170.207(o)(1) Sexual orientation must be coded in accordance with, at a minimum, the version of SNOMED CT® codes adopted at paragraph (a)(4) of this section for paragraphs (o)(1)(i) through (iii) of this section and HL7® Version 3 for paragraphs (o)(1)(iv) through (vi) of this section, attributed as follows:

  1. Lesbian, gay or homosexual. 38628009
  2. Straight or heterosexual. 20430005
  3. Bisexual. 42035005
  4. Something else, please describe. nullFlavor OTH
  5. Don’t know. nullFlavor UNK
  6. Choose not to disclose. nullFlavor ASKU

(Adoption of this standard expires on January 1, 2026)

§ 170.207(o)(2) Gender identity must be coded in accordance with, at a minimum, the version of SNOMED CT® codes adopted at paragraph (a)(4) of this section for paragraphs (o)(2)(i) through (v) of this section and HL7® Version 3 for paragraphs (o)(2)(vi) and (vii) of this section, attributed as follows:

  1. Identifies as Male. 446151000124109
  2. Identifies as Female. 446141000124107
  3. Female-to-Male (FTM)/Transgender Male/Trans Man. 407377005
  4. Male-to-Female (MTF)/Transgender Female/Trans Woman. 407376001
  5. Genderqueer, neither exclusively male nor female. 446131000124102
  6. Additional gender category or other, please specify. nullFlavor OTH
  7. Choose not to disclose. nullFlavor ASKU

(Adoption of this standard expires on January 1, 2026)

§ 170.207(o)(3) Sexual Orientation and Gender Identity must be coded in accordance with, at a minimum, the version of SNOMED CT® codes specified in § 170.207(a)(1) (This standard is required by December 31, 2025.)

Paragraph (a)(5)(i)(F)

§ 170.207(n)(3) Sex Parameter for Clinical Use must be coded in accordance with, at a minimum, the version of LOINC® codes specified in § 170.207(c)(1) (This standard is required by December 31, 2025.)

Paragraph (a)(5)(i)(H)

§ 170.207(o)(4) Pronouns must be coded in accordance with, at a minimum, the version of LOINC® codes specified in 170.207(c)(1). (Adoption of this standard is required by December 31, 2025.)

Required Update Deadlines

The following outlines deadlines for required updates for this criterion as they relate to changes published in recent ONC final rules. Developers must update their products to the requirements outlined and provide them to their customers by the stated deadlines. These represent one-time deadlines as set by recent regulatory updates and do not encompass ongoing deadlines related to the Conditions and Maintenance of Certification. Please review those requirements for additional compliance activities related to certification under Certification Dependencies.

Deadline: December 31, 2025

Action to be taken: Developers certified to this criterion must update their use of minimum standards code sets for recording race and ethnicity, sex, sexual orientation, and gender identity as detailed in paragraphs (a)(5)(i)(A) and (C-E). Developers must support recording of data in accordance with paragraphs (a)(5)(i)(F-H).

Certification Dependencies

Design and Performance: The following design and performance certification criteria (adopted in § 170.315(g)) must also be certified in order for the product to be certified.

  • Safety-enhanced design (§ 170.315(g)(3)) must be explicitly demonstrated for this criterion.
  • Quality management system (§ 170.315(g)(4)): When a single quality management system (QMS) is used, the QMS only needs to be identified once. Otherwise, the QMS’ need to be identified for every capability to which it was applied.
  • Accessibility-centered design (§ 170.315(g)(5)): When a single accessibility-centered design standard is used, the standard only needs to be identified once. Otherwise, the accessibility-centered design standards need to be identified for every capability to which they were applied; or, alternatively, the developer must state that no accessibility-centered design was used.
Privacy & Security Requirements

This certification criterion was adopted at § 170.315(a)(5). As a result, an ONC Authorized Certification Body (ONC-ACB) must ensure that a product presented for certification to a § 170.315(a) criterion includes the privacy and security criteria (adopted in § 170.315(d)) within the overall scope of the certificate issued to the product.

  • The privacy and security criteria (adopted in § 170.315(d)) do not need to be explicitly tested with this specific paragraph (a) criterion unless it is the only criterion for which certification is requested.
  • As a general rule, a product presented for certification only needs to be presented once to each applicable privacy and security criterion (adopted in § 170.315(d)) so long as the health IT developer attests that such privacy and security capabilities apply to the full scope of capabilities included in the requested certification. However, exceptions exist for § 170.315(e)(1) “View, download, and transmit to 3rd party (VDT)” and (e)(2) “Secure messaging,” which are explicitly stated.
  • § 170.315(d)(2)(i)(C) is not required if the scope of the Health IT Module does not have end-user device encryption features.

For more information on the approaches to meet these Privacy and Security requirements, please review the Privacy and Security CCG.

Version # Description of Change Version Date
1.0

Initial publication
03-11-2024
Regulation Text
Regulation Text

§ 170.315 (a)(5) Patient demographics and observations—

  1. Enable a user to record, change, and access patient demographic and observations data including race, ethnicity, preferred language, sex, sex parameter for clinical use, sexual orientation, gender identity, name to use, pronouns and date of birth.
    1. Race and ethnicity. 
      1. Enable each one of a patient's races to be recorded in accordance with, at a minimum, the standard specified in § 170.207(f)(3) and whether a patient declines to specify race.
      2. Enable each one of a patient's ethnicities to be recorded in accordance with, at a minimum, the standard specified in § 170.207(f)(3) and whether a patient declines to specify ethnicity.
      3. Aggregate each one of the patient's races and ethnicities recorded in accordance with paragraphs (a)(5)(i)(A)(1) and (2) of this section to the categories in the standard specified in § 170.207(f)(1).
    2. Preferred language. Enable preferred language to be recorded in accordance with the standard specified in § 170.207(g)(2) and whether a patient declines to specify a preferred language.
    3. Sex.  Enable sex to be recorded in accordance with the standard specified in § 170.207(n)(1) for the period up to and including December 31, 2025; or § 170.207(n)(2).
    4. Sexual orientation.  Enable sexual orientation to be recorded in accordance with, at a minimum, the version of the standard specified in § 170.207(o)(1) for the period up to and including December 31, 2025; or § 170.207(o)(3), as well as whether a patient declines to specify sexual orientation.
    5. Gender identity.  Enable gender identity to be recorded in accordance with, at a minimum, the version of the standard specified in § 170.207(o)(2) for the period up to and including December 31, 2025; or § 170.207(o)(3), as well as whether a patient declines to specify gender identity.
    6. Sex Parameter for Clinical Use. Enable at least one sex parameter for clinical use to be recorded in accordance with, at a minimum, the version of the standard specified in § 170.207(n)(3). Conformance with this paragraph is required by January 1, 2026.
    7. Name to Use. Enable at least one preferred name to use to be recorded. Conformance with this paragraph is required by January 1, 2026.
    8. Pronouns. Enable at least one pronoun to be recorded in accordance with, at a minimum, the version of the standard specified in § 170.207(o)(4). Conformance with this paragraph is required by January 1, 2026.
  2. Inpatient setting only. Enable a user to record, change, and access the preliminary cause of death and date of death in the event of mortality.
Standard(s) Referenced

Paragraph (a)(5)(i)(A)

§ 170.207(f)(1) 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

§ 170.207(f)(2) CDC Race and Ethnicity Code Set Version 1.0 (March 2000) (Adoption of this standard expires on January 1, 2026)

§ 170.207(f)(3) CDC Race and Ethnicity Code Set Version 1.2 (July 15, 2021) (This standard is required by December 31, 2025)

Paragraph (a)(5)(i)(B)

§ 170.207(g)(2) Request for Comment (RFC) 5646, “Tags for Identifying Languages”, September 2009

Paragraph (a)(5)(i)(C)

§ 170.207(n)(1) Birth sex must be coded in accordance with HL7® Version 3 Standard, Value Sets for AdministrativeGender and NullFlavor attributed as follows:

  1. Male. M
  2. Female. F
  3. Unknown. UNK

(Adoption of this standard expires on January 1, 2026)

§ 170.207(n)(2) Sex must be coded in accordance with, at a minimum, the version of SNOMED CT® U.S. Edition codes specified in § 170.207(a)(1) (This standard is required by December 31, 2025.) 

Paragraphs (a)(5)(i)(D) and (E)

§ 170.207(o)(1) Sexual orientation must be coded in accordance with, at a minimum, the version of SNOMED CT® codes adopted at paragraph (a)(4) of this section for paragraphs (o)(1)(i) through (iii) of this section and HL7® Version 3 for paragraphs (o)(1)(iv) through (vi) of this section, attributed as follows:

  1. Lesbian, gay or homosexual. 38628009
  2. Straight or heterosexual. 20430005
  3. Bisexual. 42035005
  4. Something else, please describe. nullFlavor OTH
  5. Don’t know. nullFlavor UNK
  6. Choose not to disclose. nullFlavor ASKU

(Adoption of this standard expires on January 1, 2026)

§ 170.207(o)(2) Gender identity must be coded in accordance with, at a minimum, the version of SNOMED CT® codes adopted at paragraph (a)(4) of this section for paragraphs (o)(2)(i) through (v) of this section and HL7® Version 3 for paragraphs (o)(2)(vi) and (vii) of this section, attributed as follows:

  1. Identifies as Male. 446151000124109
  2. Identifies as Female. 446141000124107
  3. Female-to-Male (FTM)/Transgender Male/Trans Man. 407377005
  4. Male-to-Female (MTF)/Transgender Female/Trans Woman. 407376001
  5. Genderqueer, neither exclusively male nor female. 446131000124102
  6. Additional gender category or other, please specify. nullFlavor OTH
  7. Choose not to disclose. nullFlavor ASKU

(Adoption of this standard expires on January 1, 2026)

§ 170.207(o)(3) Sexual Orientation and Gender Identity must be coded in accordance with, at a minimum, the version of SNOMED CT® codes specified in § 170.207(a)(1) (This standard is required by December 31, 2025.)

Paragraph (a)(5)(i)(F)

§ 170.207(n)(3) Sex Parameter for Clinical Use must be coded in accordance with, at a minimum, the version of LOINC® codes specified in § 170.207(c)(1) (This standard is required by December 31, 2025.)

Paragraph (a)(5)(i)(H)

§ 170.207(o)(4) Pronouns must be coded in accordance with, at a minimum, the version of LOINC® codes specified in 170.207(c)(1). (Adoption of this standard is required by December 31, 2025.)

Required Update Deadlines

The following outlines deadlines for required updates for this criterion as they relate to changes published in recent ONC final rules. Developers must update their products to the requirements outlined and provide them to their customers by the stated deadlines. These represent one-time deadlines as set by recent regulatory updates and do not encompass ongoing deadlines related to the Conditions and Maintenance of Certification. Please review those requirements for additional compliance activities related to certification under Certification Dependencies.

Deadline: December 31, 2025

Action to be taken: Developers certified to this criterion must update their use of minimum standards code sets for recording race and ethnicity, sex, sexual orientation, and gender identity as detailed in paragraphs (a)(5)(i)(A) and (C-E). Developers must support recording of data in accordance with paragraphs (a)(5)(i)(F-H).

Certification Dependencies

Design and Performance: The following design and performance certification criteria (adopted in § 170.315(g)) must also be certified in order for the product to be certified.

  • Safety-enhanced design (§ 170.315(g)(3)) must be explicitly demonstrated for this criterion.
  • Quality management system (§ 170.315(g)(4)): When a single quality management system (QMS) is used, the QMS only needs to be identified once. Otherwise, the QMS’ need to be identified for every capability to which it was applied.
  • Accessibility-centered design (§ 170.315(g)(5)): When a single accessibility-centered design standard is used, the standard only needs to be identified once. Otherwise, the accessibility-centered design standards need to be identified for every capability to which they were applied; or, alternatively, the developer must state that no accessibility-centered design was used.
Privacy & Security Requirements

This certification criterion was adopted at § 170.315(a)(5). As a result, an ONC Authorized Certification Body (ONC-ACB) must ensure that a product presented for certification to a § 170.315(a) criterion includes the privacy and security criteria (adopted in § 170.315(d)) within the overall scope of the certificate issued to the product.

  • The privacy and security criteria (adopted in § 170.315(d)) do not need to be explicitly tested with this specific paragraph (a) criterion unless it is the only criterion for which certification is requested.
  • As a general rule, a product presented for certification only needs to be presented once to each applicable privacy and security criterion (adopted in § 170.315(d)) so long as the health IT developer attests that such privacy and security capabilities apply to the full scope of capabilities included in the requested certification. However, exceptions exist for § 170.315(e)(1) “View, download, and transmit to 3rd party (VDT)” and (e)(2) “Secure messaging,” which are explicitly stated.
  • § 170.315(d)(2)(i)(C) is not required if the scope of the Health IT Module does not have end-user device encryption features.

For more information on the approaches to meet these Privacy and Security requirements, please review the Privacy and Security CCG.

Revision History
Version # Description of Change Version Date
1.0

Initial publication
03-11-2024

Testing components

Attestation: As of September 21, 2017, the testing approach for this criterion is satisfied by attestation.

The archived version of the Test Procedure is attached below for reference.

 

System Under Test

ONC-ACB Verification

The health IT developer will attest directly to the ONC-ACB to conformance with the § 170.315(a)(5) Patient demographics and observations requirements.

The ONC-ACB verifies the health IT developer attests conformance to the § 170.315(a)(5) Patient demographics and observations requirements.

 

 

Archived Version:
§170.315(a)(5) Test Procedure
Updated on 08-12-2024
Regulation Text
Regulation Text

§ 170.315 (a)(5) Patient demographics and observations—

  1. Enable a user to record, change, and access patient demographic and observations data including race, ethnicity, preferred language, sex, sex parameter for clinical use, sexual orientation, gender identity, name to use, pronouns and date of birth.
    1. Race and ethnicity. 
      1. Enable each one of a patient's races to be recorded in accordance with, at a minimum, the standard specified in § 170.207(f)(3) and whether a patient declines to specify race.
      2. Enable each one of a patient's ethnicities to be recorded in accordance with, at a minimum, the standard specified in § 170.207(f)(3) and whether a patient declines to specify ethnicity.
      3. Aggregate each one of the patient's races and ethnicities recorded in accordance with paragraphs (a)(5)(i)(A)(1) and (2) of this section to the categories in the standard specified in § 170.207(f)(1).
    2. Preferred language. Enable preferred language to be recorded in accordance with the standard specified in § 170.207(g)(2) and whether a patient declines to specify a preferred language.
    3. Sex.  Enable sex to be recorded in accordance with the standard specified in § 170.207(n)(1) for the period up to and including December 31, 2025; or § 170.207(n)(2).
    4. Sexual orientation.  Enable sexual orientation to be recorded in accordance with, at a minimum, the version of the standard specified in § 170.207(o)(1) for the period up to and including December 31, 2025; or § 170.207(o)(3), as well as whether a patient declines to specify sexual orientation.
    5. Gender identity.  Enable gender identity to be recorded in accordance with, at a minimum, the version of the standard specified in § 170.207(o)(2) for the period up to and including December 31, 2025; or § 170.207(o)(3), as well as whether a patient declines to specify gender identity.
    6. Sex Parameter for Clinical Use. Enable at least one sex parameter for clinical use to be recorded in accordance with, at a minimum, the version of the standard specified in § 170.207(n)(3). Conformance with this paragraph is required by January 1, 2026.
    7. Name to Use. Enable at least one preferred name to use to be recorded. Conformance with this paragraph is required by January 1, 2026.
    8. Pronouns. Enable at least one pronoun to be recorded in accordance with, at a minimum, the version of the standard specified in § 170.207(o)(4). Conformance with this paragraph is required by January 1, 2026.
  2. Inpatient setting only. Enable a user to record, change, and access the preliminary cause of death and date of death in the event of mortality.
Standard(s) Referenced

Paragraph (a)(5)(i)(A)

§ 170.207(f)(1) 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

§ 170.207(f)(2) CDC Race and Ethnicity Code Set Version 1.0 (March 2000) (Adoption of this standard expires on January 1, 2026)

§ 170.207(f)(3) CDC Race and Ethnicity Code Set Version 1.2 (July 15, 2021) (This standard is required by December 31, 2025)

Paragraph (a)(5)(i)(B)

§ 170.207(g)(2) Request for Comment (RFC) 5646, “Tags for Identifying Languages”, September 2009

Paragraph (a)(5)(i)(C)

§ 170.207(n)(1) Birth sex must be coded in accordance with HL7® Version 3 Standard, Value Sets for AdministrativeGender and NullFlavor attributed as follows:

  1. Male. M
  2. Female. F
  3. Unknown. UNK

(Adoption of this standard expires on January 1, 2026)

§ 170.207(n)(2) Sex must be coded in accordance with, at a minimum, the version of SNOMED CT® U.S. Edition codes specified in § 170.207(a)(1) (This standard is required by December 31, 2025.) 

Paragraphs (a)(5)(i)(D) and (E)

§ 170.207(o)(1) Sexual orientation must be coded in accordance with, at a minimum, the version of SNOMED CT® codes adopted at paragraph (a)(4) of this section for paragraphs (o)(1)(i) through (iii) of this section and HL7® Version 3 for paragraphs (o)(1)(iv) through (vi) of this section, attributed as follows:

  1. Lesbian, gay or homosexual. 38628009
  2. Straight or heterosexual. 20430005
  3. Bisexual. 42035005
  4. Something else, please describe. nullFlavor OTH
  5. Don’t know. nullFlavor UNK
  6. Choose not to disclose. nullFlavor ASKU

(Adoption of this standard expires on January 1, 2026)

§ 170.207(o)(2) Gender identity must be coded in accordance with, at a minimum, the version of SNOMED CT® codes adopted at paragraph (a)(4) of this section for paragraphs (o)(2)(i) through (v) of this section and HL7® Version 3 for paragraphs (o)(2)(vi) and (vii) of this section, attributed as follows:

  1. Identifies as Male. 446151000124109
  2. Identifies as Female. 446141000124107
  3. Female-to-Male (FTM)/Transgender Male/Trans Man. 407377005
  4. Male-to-Female (MTF)/Transgender Female/Trans Woman. 407376001
  5. Genderqueer, neither exclusively male nor female. 446131000124102
  6. Additional gender category or other, please specify. nullFlavor OTH
  7. Choose not to disclose. nullFlavor ASKU

(Adoption of this standard expires on January 1, 2026)

§ 170.207(o)(3) Sexual Orientation and Gender Identity must be coded in accordance with, at a minimum, the version of SNOMED CT® codes specified in § 170.207(a)(1) (This standard is required by December 31, 2025.)

Paragraph (a)(5)(i)(F)

§ 170.207(n)(3) Sex Parameter for Clinical Use must be coded in accordance with, at a minimum, the version of LOINC® codes specified in § 170.207(c)(1) (This standard is required by December 31, 2025.)

Paragraph (a)(5)(i)(H)

§ 170.207(o)(4) Pronouns must be coded in accordance with, at a minimum, the version of LOINC® codes specified in 170.207(c)(1). (Adoption of this standard is required by December 31, 2025.)

Required Update Deadlines

The following outlines deadlines for required updates for this criterion as they relate to changes published in recent ONC final rules. Developers must update their products to the requirements outlined and provide them to their customers by the stated deadlines. These represent one-time deadlines as set by recent regulatory updates and do not encompass ongoing deadlines related to the Conditions and Maintenance of Certification. Please review those requirements for additional compliance activities related to certification under Certification Dependencies.

Deadline: December 31, 2025

Action to be taken: Developers certified to this criterion must update their use of minimum standards code sets for recording race and ethnicity, sex, sexual orientation, and gender identity as detailed in paragraphs (a)(5)(i)(A) and (C-E). Developers must support recording of data in accordance with paragraphs (a)(5)(i)(F-H).

Certification Dependencies

Design and Performance: The following design and performance certification criteria (adopted in § 170.315(g)) must also be certified in order for the product to be certified.

  • Safety-enhanced design (§ 170.315(g)(3)) must be explicitly demonstrated for this criterion.
  • Quality management system (§ 170.315(g)(4)): When a single quality management system (QMS) is used, the QMS only needs to be identified once. Otherwise, the QMS’ need to be identified for every capability to which it was applied.
  • Accessibility-centered design (§ 170.315(g)(5)): When a single accessibility-centered design standard is used, the standard only needs to be identified once. Otherwise, the accessibility-centered design standards need to be identified for every capability to which they were applied; or, alternatively, the developer must state that no accessibility-centered design was used.
Privacy & Security Requirements

This certification criterion was adopted at § 170.315(a)(5). As a result, an ONC Authorized Certification Body (ONC-ACB) must ensure that a product presented for certification to a § 170.315(a) criterion includes the privacy and security criteria (adopted in § 170.315(d)) within the overall scope of the certificate issued to the product.

  • The privacy and security criteria (adopted in § 170.315(d)) do not need to be explicitly tested with this specific paragraph (a) criterion unless it is the only criterion for which certification is requested.
  • As a general rule, a product presented for certification only needs to be presented once to each applicable privacy and security criterion (adopted in § 170.315(d)) so long as the health IT developer attests that such privacy and security capabilities apply to the full scope of capabilities included in the requested certification. However, exceptions exist for § 170.315(e)(1) “View, download, and transmit to 3rd party (VDT)” and (e)(2) “Secure messaging,” which are explicitly stated.
  • § 170.315(d)(2)(i)(C) is not required if the scope of the Health IT Module does not have end-user device encryption features.

For more information on the approaches to meet these Privacy and Security requirements, please review the Privacy and Security CCG.

Version # Description of Change Version Date
1.0

Initial publication
03-11-2024
Regulation Text
Regulation Text

§ 170.315 (a)(5) Patient demographics and observations—

  1. Enable a user to record, change, and access patient demographic and observations data including race, ethnicity, preferred language, sex, sex parameter for clinical use, sexual orientation, gender identity, name to use, pronouns and date of birth.
    1. Race and ethnicity. 
      1. Enable each one of a patient's races to be recorded in accordance with, at a minimum, the standard specified in § 170.207(f)(3) and whether a patient declines to specify race.
      2. Enable each one of a patient's ethnicities to be recorded in accordance with, at a minimum, the standard specified in § 170.207(f)(3) and whether a patient declines to specify ethnicity.
      3. Aggregate each one of the patient's races and ethnicities recorded in accordance with paragraphs (a)(5)(i)(A)(1) and (2) of this section to the categories in the standard specified in § 170.207(f)(1).
    2. Preferred language. Enable preferred language to be recorded in accordance with the standard specified in § 170.207(g)(2) and whether a patient declines to specify a preferred language.
    3. Sex.  Enable sex to be recorded in accordance with the standard specified in § 170.207(n)(1) for the period up to and including December 31, 2025; or § 170.207(n)(2).
    4. Sexual orientation.  Enable sexual orientation to be recorded in accordance with, at a minimum, the version of the standard specified in § 170.207(o)(1) for the period up to and including December 31, 2025; or § 170.207(o)(3), as well as whether a patient declines to specify sexual orientation.
    5. Gender identity.  Enable gender identity to be recorded in accordance with, at a minimum, the version of the standard specified in § 170.207(o)(2) for the period up to and including December 31, 2025; or § 170.207(o)(3), as well as whether a patient declines to specify gender identity.
    6. Sex Parameter for Clinical Use. Enable at least one sex parameter for clinical use to be recorded in accordance with, at a minimum, the version of the standard specified in § 170.207(n)(3). Conformance with this paragraph is required by January 1, 2026.
    7. Name to Use. Enable at least one preferred name to use to be recorded. Conformance with this paragraph is required by January 1, 2026.
    8. Pronouns. Enable at least one pronoun to be recorded in accordance with, at a minimum, the version of the standard specified in § 170.207(o)(4). Conformance with this paragraph is required by January 1, 2026.
  2. Inpatient setting only. Enable a user to record, change, and access the preliminary cause of death and date of death in the event of mortality.
Standard(s) Referenced

Paragraph (a)(5)(i)(A)

§ 170.207(f)(1) 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

§ 170.207(f)(2) CDC Race and Ethnicity Code Set Version 1.0 (March 2000) (Adoption of this standard expires on January 1, 2026)

§ 170.207(f)(3) CDC Race and Ethnicity Code Set Version 1.2 (July 15, 2021) (This standard is required by December 31, 2025)

Paragraph (a)(5)(i)(B)

§ 170.207(g)(2) Request for Comment (RFC) 5646, “Tags for Identifying Languages”, September 2009

Paragraph (a)(5)(i)(C)

§ 170.207(n)(1) Birth sex must be coded in accordance with HL7® Version 3 Standard, Value Sets for AdministrativeGender and NullFlavor attributed as follows:

  1. Male. M
  2. Female. F
  3. Unknown. UNK

(Adoption of this standard expires on January 1, 2026)

§ 170.207(n)(2) Sex must be coded in accordance with, at a minimum, the version of SNOMED CT® U.S. Edition codes specified in § 170.207(a)(1) (This standard is required by December 31, 2025.) 

Paragraphs (a)(5)(i)(D) and (E)

§ 170.207(o)(1) Sexual orientation must be coded in accordance with, at a minimum, the version of SNOMED CT® codes adopted at paragraph (a)(4) of this section for paragraphs (o)(1)(i) through (iii) of this section and HL7® Version 3 for paragraphs (o)(1)(iv) through (vi) of this section, attributed as follows:

  1. Lesbian, gay or homosexual. 38628009
  2. Straight or heterosexual. 20430005
  3. Bisexual. 42035005
  4. Something else, please describe. nullFlavor OTH
  5. Don’t know. nullFlavor UNK
  6. Choose not to disclose. nullFlavor ASKU

(Adoption of this standard expires on January 1, 2026)

§ 170.207(o)(2) Gender identity must be coded in accordance with, at a minimum, the version of SNOMED CT® codes adopted at paragraph (a)(4) of this section for paragraphs (o)(2)(i) through (v) of this section and HL7® Version 3 for paragraphs (o)(2)(vi) and (vii) of this section, attributed as follows:

  1. Identifies as Male. 446151000124109
  2. Identifies as Female. 446141000124107
  3. Female-to-Male (FTM)/Transgender Male/Trans Man. 407377005
  4. Male-to-Female (MTF)/Transgender Female/Trans Woman. 407376001
  5. Genderqueer, neither exclusively male nor female. 446131000124102
  6. Additional gender category or other, please specify. nullFlavor OTH
  7. Choose not to disclose. nullFlavor ASKU

(Adoption of this standard expires on January 1, 2026)

§ 170.207(o)(3) Sexual Orientation and Gender Identity must be coded in accordance with, at a minimum, the version of SNOMED CT® codes specified in § 170.207(a)(1) (This standard is required by December 31, 2025.)

Paragraph (a)(5)(i)(F)

§ 170.207(n)(3) Sex Parameter for Clinical Use must be coded in accordance with, at a minimum, the version of LOINC® codes specified in § 170.207(c)(1) (This standard is required by December 31, 2025.)

Paragraph (a)(5)(i)(H)

§ 170.207(o)(4) Pronouns must be coded in accordance with, at a minimum, the version of LOINC® codes specified in 170.207(c)(1). (Adoption of this standard is required by December 31, 2025.)

Required Update Deadlines

The following outlines deadlines for required updates for this criterion as they relate to changes published in recent ONC final rules. Developers must update their products to the requirements outlined and provide them to their customers by the stated deadlines. These represent one-time deadlines as set by recent regulatory updates and do not encompass ongoing deadlines related to the Conditions and Maintenance of Certification. Please review those requirements for additional compliance activities related to certification under Certification Dependencies.

Deadline: December 31, 2025

Action to be taken: Developers certified to this criterion must update their use of minimum standards code sets for recording race and ethnicity, sex, sexual orientation, and gender identity as detailed in paragraphs (a)(5)(i)(A) and (C-E). Developers must support recording of data in accordance with paragraphs (a)(5)(i)(F-H).

Certification Dependencies

Design and Performance: The following design and performance certification criteria (adopted in § 170.315(g)) must also be certified in order for the product to be certified.

  • Safety-enhanced design (§ 170.315(g)(3)) must be explicitly demonstrated for this criterion.
  • Quality management system (§ 170.315(g)(4)): When a single quality management system (QMS) is used, the QMS only needs to be identified once. Otherwise, the QMS’ need to be identified for every capability to which it was applied.
  • Accessibility-centered design (§ 170.315(g)(5)): When a single accessibility-centered design standard is used, the standard only needs to be identified once. Otherwise, the accessibility-centered design standards need to be identified for every capability to which they were applied; or, alternatively, the developer must state that no accessibility-centered design was used.
Privacy & Security Requirements

This certification criterion was adopted at § 170.315(a)(5). As a result, an ONC Authorized Certification Body (ONC-ACB) must ensure that a product presented for certification to a § 170.315(a) criterion includes the privacy and security criteria (adopted in § 170.315(d)) within the overall scope of the certificate issued to the product.

  • The privacy and security criteria (adopted in § 170.315(d)) do not need to be explicitly tested with this specific paragraph (a) criterion unless it is the only criterion for which certification is requested.
  • As a general rule, a product presented for certification only needs to be presented once to each applicable privacy and security criterion (adopted in § 170.315(d)) so long as the health IT developer attests that such privacy and security capabilities apply to the full scope of capabilities included in the requested certification. However, exceptions exist for § 170.315(e)(1) “View, download, and transmit to 3rd party (VDT)” and (e)(2) “Secure messaging,” which are explicitly stated.
  • § 170.315(d)(2)(i)(C) is not required if the scope of the Health IT Module does not have end-user device encryption features.

For more information on the approaches to meet these Privacy and Security requirements, please review the Privacy and Security CCG.

Revision History
Version # Description of Change Version Date
1.0

Initial publication
03-11-2024
1.1
  • For the entire criterion, added clarification regarding updates to safety-enhanced design testing to comply with HTI-1 Final Rule requirements.
  • For Paragraph (a)(5)(i)(F), added clarification regarding requirements for coding Sex Parameter for Clinical Use.
  • For Paragraphs (a)(5)(i)(D) and (E), removed a clarification and revised a clarification regarding use of expiring standards.
08-12-2024

Certification Companion Guide: Patient demographics and observations

This Certification Companion Guide (CCG) is an informative document designed to assist with health IT product certification. The CCG is not a substitute for the requirements outlined in regulation and related ONC final rules. It extracts key portions of ONC final rules’ preambles and includes subsequent clarifying interpretations. To access the full context of regulatory intent please consult the Certification Regulations page for links to all ONC final rules or consult other regulatory references as noted. The CCG is for public use and should not be sold or redistributed.

The below table outlines whether this criterion has additional Maintenance of Certification dependencies, update requirements and/or eligibility for standards updates via SVAP. Review the Certification Dependencies and Required Update Deadline drop-downs above if this table indicates “yes” for any field.

 

Base EHR Definition Real World Testing Insights Condition SVAP Requires Updates
Included No No No Yes
Certification Requirements
Technical Explanations and Clarifications

Applies to entire criterion

Clarifications:

  • The demographic data can come from other sources (e.g., a registration system or practice management system) so long as testing demonstrates the Health IT Module can perform all required functions included in the Patient demographics and observations certification criterion. [see also Health IT Certification Program Overview]
  • Testing for preferred language using the standard at § 170.207(g)(2) Request for Comments (RFC) 5646 will focus on all the languages present in ISO 639-2.
  • Consistent with the § 170.207(g)(2) RFC 5646, the shortest alpha code for the language should be used. Testing will only test the primary language tag and not test for extension components specified in § 170.207(g)(2) RFC 5646 such as extended language sub-tags, script tag, or region tag. [see also 80 FR 16817] Specifically:
    • use alpha 2 character code if one exists (ISO 639-1);
    • use alpha 3 character code if an alpha 2 character code does not exist (ISO 639-2); and
    • region extensions (ISO 3166-1) are permitted but not required (however, if a region extension is used, it will be verified for accuracy as part of testing and must be correct).
  • ONC’s adoption of the “Sex Parameter for Clinical Use”, “Name to Use”, and “Pronouns” data elements does not establish a requirement for health care providers or patients to record or disclose this information, or use these capabilities. ONC encourages developers of certified health IT to work with providers to develop appropriate workflows. [see also 89 FR 1296]
  • Certified Health IT Developers must assess user-facing functionality gaps between Health IT Modules currently certified to the § 170.315(a)(5) criterion and the updated § 170.315(a)(5) criterion requirements as specified in the HTI-1 Final Rule. Certified Health IT Developers must assess if updates to the Health IT Module's user-facing functionalities to resolve these gaps necessitate user-centered design processes applied during development and thus must be included as part of summative testing in accordance with the § 170.315(g)(3) criterion. Accordingly and as necessary, Certified Health IT Developers must update their safety-enhanced design (SED) testing for updated § 170.315(a)(5) criterion requirements.

Clarifications:

  • The demographic data can come from other sources (e.g., a registration system or practice management system) so long as testing demonstrates the Health IT Module can perform all required functions included in the Patient demographics and observations certification criterion. [see also Health IT Certification Program Overview]
  • Testing for preferred language using the standard at § 170.207(g)(2) Request for Comments (RFC) 5646 will focus on all the languages present in ISO 639-2.
  • Consistent with the § 170.207(g)(2) RFC 5646, the shortest alpha code for the language should be used. Testing will only test the primary language tag and not test for extension components specified in § 170.207(g)(2) RFC 5646 such as extended language sub-tags, script tag, or region tag. [see also 80 FR 16817] Specifically:
    • use alpha 2 character code if one exists (ISO 639-1);
    • use alpha 3 character code if an alpha 2 character code does not exist (ISO 639-2); and
    • region extensions (ISO 3166-1) are permitted but not required (however, if a region extension is used, it will be verified for accuracy as part of testing and must be correct).
  • ONC’s adoption of the “Sex Parameter for Clinical Use”, “Name to Use”, and “Pronouns” data elements does not establish a requirement for health care providers or patients to record or disclose this information, or use these capabilities. ONC encourages developers of certified health IT to work with providers to develop appropriate workflows. [see also 89 FR 1296]
  • Certified Health IT Developers must assess user-facing functionality gaps between Health IT Modules currently certified to the § 170.315(a)(5) criterion and the updated § 170.315(a)(5) criterion requirements as specified in the HTI-1 Final Rule. Certified Health IT Developers must assess if updates to the Health IT Module's user-facing functionalities to resolve these gaps necessitate user-centered design processes applied during development and thus must be included as part of summative testing in accordance with the § 170.315(g)(3) criterion. Accordingly and as necessary, Certified Health IT Developers must update their safety-enhanced design (SED) testing for updated § 170.315(a)(5) criterion requirements.

Paragraph (a)(5)(i) Enable user to record, change, and access data

Clarifications:

  • There is no standard required for recording date of birth (i.e., any format may be used).

Clarifications:

  • There is no standard required for recording date of birth (i.e., any format may be used).

Paragraph (a)(5)(i)(A) Race and ethnicity

Technical outcome –

  • A user can record each one of a patient’s race(s) and each one of a patient’s ethnicity(ies) according to concepts in the “Race & Ethnicity" – CDC code system Version 1.2.
  • The software must be able to aggregate each one of a patient’s race(s) and each one of a patient’s ethnicity(ies) and record the race(s) and ethnicity(ies) according to the § 170.207(f)(1) The Office of Management and Budget (OMB) Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity. The categories to which race and ethnicity selections must be aggregated and recorded include:
    • American Indian or Alaska Native;
    • Asian;
    • Black or African American;
    • Native Hawaiian or Other Pacific Islander
    • White; and
    • Hispanic or Latino.
  • The user must be able to record whether the patient declined to specify a race, an ethnicity, and both.

Clarifications:

  • Note that while this provision focuses on the capture of race and ethnicity, industry standards require race and ethnicity be exchanged as separate fields (e.g., Consolidated Clinical Document Architecture (C-CDA) and Quality Reporting Document Architecture (QRDA)). ONC suggests developers bear this in mind when developing their health IT systems.
  • The “Race & Ethnicity" – CDC code system includes over 900 concepts for race and ethnicity. [see also 80 FR 16816] A health IT developer is free to determine how the user interface is designed, including how many race and ethnicity values are displayed. No default minimum number of visible selections is expected or implied. During testing, however, any of the concepts for race and ethnicity may be tested. [see also 80 FR 62618]
  • Health IT must be able to record multiple races or ethnicities reported by a patient and be able to be correctly roll them up to the OMB value. While the criterion is not prescriptive in that it does not set a “maximum-minimum” number of multiple entries that must be supported, the criterion supports surveillance that could include detailed race data that would cover up to all five OMB races at once to show multi-race selection, support across the 900+ value set, and ultimately accurate roll-up.
  • The Health IT Module must be able to record multiple, each one of a patient’s races and ethnicities. [see also 80 FR 62618]
  • ONC provides the following object identifier (OID) to assist developers in the proper identification and exchange of health information coded to certain vocabulary standards.
    • CDC Race and Ethnicity Code Set OID: 2.16.840.1.113883.6.238 [see also 80 FR 62612]
  • Health IT Modules can present for certification to a more recent version of the “Race & Ethnicity” – CDC code system than what is presented in regulation. [see also 80 FR 62612]
  • The concepts in the “Race & Ethnicity” – CDC code system are pre-mapped to the race and ethnicity categories in the § 170.207(f)(1) The Office of Management and Budget (OMB) Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity. Testing will verify that the more granular race and ethnicity codes are correctly mapped to the OMB standard. The mapping of these codes uses the CDCREC Roll-up Codes. To access these codes, navigate to the CDCREC Roll-up Codes Tab after signing into the US National Library of Medicine, Value Set Authority Center. Once there, download the appropriate mapping of the detailed race code to the “roll-up” values of “Race” code. For information on mapping detailed ethnicities to the “roll-up” values of the “Ethnicity” code, select the value set defined by the following:
    1. Code System: CDCREC
    2. Version: 1.1 
    3. Code: 2133-7
  • The health IT must be able to represent codes in the § 170.207(f)(1) The OMB Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity standard. The use of more granular codes is permitted, so long as they map to the OMB codes.
  • The § 170.207(f)(1) The OMB Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity standard permits merging the ethnicity and race categories for a “combined format,” which would no longer require “not Hispanic or Latino” to be recorded. This alternative approach is also acceptable.
  • A product does not need to display all of the race and ethnicity codes to meet the certification criterion. The health IT developer has the discretion to create a default selection set or enable customization choices for providers. However, for the purposes of testing and surveillance, a developer should be prepared to show that the product can represent any of the races and ethnicities in the value set created by the standard.

Technical outcome –

  • A user can record each one of a patient’s race(s) and each one of a patient’s ethnicity(ies) according to concepts in the “Race & Ethnicity" – CDC code system Version 1.2.
  • The software must be able to aggregate each one of a patient’s race(s) and each one of a patient’s ethnicity(ies) and record the race(s) and ethnicity(ies) according to the § 170.207(f)(1) The Office of Management and Budget (OMB) Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity. The categories to which race and ethnicity selections must be aggregated and recorded include:
    • American Indian or Alaska Native;
    • Asian;
    • Black or African American;
    • Native Hawaiian or Other Pacific Islander
    • White; and
    • Hispanic or Latino.
  • The user must be able to record whether the patient declined to specify a race, an ethnicity, and both.

Clarifications:

  • Note that while this provision focuses on the capture of race and ethnicity, industry standards require race and ethnicity be exchanged as separate fields (e.g., Consolidated Clinical Document Architecture (C-CDA) and Quality Reporting Document Architecture (QRDA)). ONC suggests developers bear this in mind when developing their health IT systems.
  • The “Race & Ethnicity" – CDC code system includes over 900 concepts for race and ethnicity. [see also 80 FR 16816] A health IT developer is free to determine how the user interface is designed, including how many race and ethnicity values are displayed. No default minimum number of visible selections is expected or implied. During testing, however, any of the concepts for race and ethnicity may be tested. [see also 80 FR 62618]
  • Health IT must be able to record multiple races or ethnicities reported by a patient and be able to be correctly roll them up to the OMB value. While the criterion is not prescriptive in that it does not set a “maximum-minimum” number of multiple entries that must be supported, the criterion supports surveillance that could include detailed race data that would cover up to all five OMB races at once to show multi-race selection, support across the 900+ value set, and ultimately accurate roll-up.
  • The Health IT Module must be able to record multiple, each one of a patient’s races and ethnicities. [see also 80 FR 62618]
  • ONC provides the following object identifier (OID) to assist developers in the proper identification and exchange of health information coded to certain vocabulary standards.
    • CDC Race and Ethnicity Code Set OID: 2.16.840.1.113883.6.238 [see also 80 FR 62612]
  • Health IT Modules can present for certification to a more recent version of the “Race & Ethnicity” – CDC code system than what is presented in regulation. [see also 80 FR 62612]
  • The concepts in the “Race & Ethnicity” – CDC code system are pre-mapped to the race and ethnicity categories in the § 170.207(f)(1) The Office of Management and Budget (OMB) Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity. Testing will verify that the more granular race and ethnicity codes are correctly mapped to the OMB standard. The mapping of these codes uses the CDCREC Roll-up Codes. To access these codes, navigate to the CDCREC Roll-up Codes Tab after signing into the US National Library of Medicine, Value Set Authority Center. Once there, download the appropriate mapping of the detailed race code to the “roll-up” values of “Race” code. For information on mapping detailed ethnicities to the “roll-up” values of the “Ethnicity” code, select the value set defined by the following:
    1. Code System: CDCREC
    2. Version: 1.1 
    3. Code: 2133-7
  • The health IT must be able to represent codes in the § 170.207(f)(1) The OMB Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity standard. The use of more granular codes is permitted, so long as they map to the OMB codes.
  • The § 170.207(f)(1) The OMB Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity standard permits merging the ethnicity and race categories for a “combined format,” which would no longer require “not Hispanic or Latino” to be recorded. This alternative approach is also acceptable.
  • A product does not need to display all of the race and ethnicity codes to meet the certification criterion. The health IT developer has the discretion to create a default selection set or enable customization choices for providers. However, for the purposes of testing and surveillance, a developer should be prepared to show that the product can represent any of the races and ethnicities in the value set created by the standard.

Paragraph (a)(5)(i)(B) Preferred language

Technical outcome – A user can record a patient’s preferred language according to the § 170.207(g)(2) RFC 5646 standard. The user must be able to record whether the patient declined to specify preferred language.

Clarifications:

  • § 170.207(g)(2) RFC 5646 is compatible with C-CDA Release 2.1 and ISO 639-1, 639-2, and 639-3 can be mapped to it. [see also 80 FR 62619]
  • ONC provides the following OID to assist developers in the proper identification and exchange of health information coded to certain vocabulary standards.
    • Tags for Identifying Languages – § 170.207(g)(2) RFC 5646 code system OID: 2.16.840.1.113883.6.316 [see also 80 FR 62612]
  • A product does not need to display all of the language codes to meet the certification criterion. The health IT developer has the discretion to create a default selection set or enable customization choices for providers. However, for the purposes of testing, a developer should be prepared to show that the product can record any of languages in the value set created by the standard.

Technical outcome – A user can record a patient’s preferred language according to the § 170.207(g)(2) RFC 5646 standard. The user must be able to record whether the patient declined to specify preferred language.

Clarifications:

  • § 170.207(g)(2) RFC 5646 is compatible with C-CDA Release 2.1 and ISO 639-1, 639-2, and 639-3 can be mapped to it. [see also 80 FR 62619]
  • ONC provides the following OID to assist developers in the proper identification and exchange of health information coded to certain vocabulary standards.
    • Tags for Identifying Languages – § 170.207(g)(2) RFC 5646 code system OID: 2.16.840.1.113883.6.316 [see also 80 FR 62612]
  • A product does not need to display all of the language codes to meet the certification criterion. The health IT developer has the discretion to create a default selection set or enable customization choices for providers. However, for the purposes of testing, a developer should be prepared to show that the product can record any of languages in the value set created by the standard.

Paragraph (a)(5)(i)(C) Sex

Technical outcome – A user can record a patient’s sex according to HL7® Version 3 and a nullFlavor value attributed as male (M), female (F), and unknown (UNK) up to and including December 31, 2025, or the SNOMED CT® U.S. Edition codes specified at § 170.207(a)(1).

Clarifications:

  • The codes required are intended to present birth sex (i.e., the sex recorded on the patient’s birth certificate) and not gender identity or reassigned sex. This criterion requires health IT enable a user to capture sexual orientation and gender identity separately (refer to provisions (i)(D) and (i)(E) below). [see also 80 FR 62618]
  • Adoption of HL7® Version 3 and a nullFlavor value attributed as male (M), female (F) and unknown (UNK) to address patient sex is permissible until the standard expires on January 1, 2026. Developers have flexibility on whether they use HL7® Version 3 or SNOMED CT® before that date, but after December 31, 2025, must use SNOMED CT®.

Technical outcome – A user can record a patient’s sex according to HL7® Version 3 and a nullFlavor value attributed as male (M), female (F), and unknown (UNK) up to and including December 31, 2025, or the SNOMED CT® U.S. Edition codes specified at § 170.207(a)(1).

Clarifications:

  • The codes required are intended to present birth sex (i.e., the sex recorded on the patient’s birth certificate) and not gender identity or reassigned sex. This criterion requires health IT enable a user to capture sexual orientation and gender identity separately (refer to provisions (i)(D) and (i)(E) below). [see also 80 FR 62618]
  • Adoption of HL7® Version 3 and a nullFlavor value attributed as male (M), female (F) and unknown (UNK) to address patient sex is permissible until the standard expires on January 1, 2026. Developers have flexibility on whether they use HL7® Version 3 or SNOMED CT® before that date, but after December 31, 2025, must use SNOMED CT®.

Paragraphs (a)(5)(i)(D) and (E) Sexual orientation and gender identity 

Technical outcome – A user can record a patient’s sexual orientation and gender identity according to HL7® Version 3 and SNOMED CT® codes specified in the “standard(s) referenced” column up to and including December 31, 2025 or according to the SNOMED CT® U.S. Edition codes specified at § 170.207(a)(1). The user must be able to record whether the patient declined to specify sexual orientation and/or gender identity.

Clarifications:

  • We provide the following OID to assist developers in the proper identification and exchange of health information coded to certain vocabulary standards.
    • SNOMED CT® code system OID: 2.16.840.1.113883.6.96 [see also 80 FR 62612]
      • Health IT Modules can present for certification to a more recent version of the U.S. Edition of SNOMED CT® than the September 2015 version. [see also 80 FR 62612]
  • To meet the requirements at paragraphs (a)(5)(i)(D) and (E), use of HL7® Version 3 and the SNOMED CT® codes as specified at §170.207(o)(1) is permissible until the standards expire for use in the Certification Program on January 1, 2026. However, after December 31, 2025, developers must use SNOMED CT® as specified at § 170.207(o)(3) in fulfilment of the requirements at paragraphs (a)(5)(i)(D) and (E).

Technical outcome – A user can record a patient’s sexual orientation and gender identity according to HL7® Version 3 and SNOMED CT® codes specified in the “standard(s) referenced” column up to and including December 31, 2025 or according to the SNOMED CT® U.S. Edition codes specified at § 170.207(a)(1). The user must be able to record whether the patient declined to specify sexual orientation and/or gender identity.

Clarifications:

  • We provide the following OID to assist developers in the proper identification and exchange of health information coded to certain vocabulary standards.
    • SNOMED CT® code system OID: 2.16.840.1.113883.6.96 [see also 80 FR 62612]
      • Health IT Modules can present for certification to a more recent version of the U.S. Edition of SNOMED CT® than the September 2015 version. [see also 80 FR 62612]
  • To meet the requirements at paragraphs (a)(5)(i)(D) and (E), use of HL7® Version 3 and the SNOMED CT® codes as specified at §170.207(o)(1) is permissible until the standards expire for use in the Certification Program on January 1, 2026. However, after December 31, 2025, developers must use SNOMED CT® as specified at § 170.207(o)(3) in fulfilment of the requirements at paragraphs (a)(5)(i)(D) and (E).

Paragraph (a)(5)(i)(F) Sex parameter for clinical use

Technical outcome – A user can record a patient’s sex parameter for clinical use according to the LOINC® codes specified in the “standard(s) referenced” column.

Clarifications:

  • In fulfillment of this requirement, the Health IT Module must be able to record at least one value for Sex Parameter for Clinical Use for each patient. We note that there may also be multiple values tied to different events, such as requesting a laboratory test or imaging study, allowing for and encouraging more than one. [see also 89 FR 1296]
  • Developers of certified health IT have the flexibility to configure their user interface and to capture and display "Sex Parameter for Clinical Use” data in clinical workflows consistent with their own design decisions. [see also 89 FR 1296]
  • We clarify for the requirements at § 170.315(a)(5)(i)(F) that Sex Parameter for Clinical Use must be coded in accordance with, at a minimum, LOINC® v2.72, as specified in § 170.207(c)(1). As reiterated in the HTI-1 Final Rule (89 FR 1196), health IT developers may certify using newer versions of "minimum standards" code sets on a voluntary basis. Accordingly, health IT developers may use newer versions of LOINC® than v2.72 to code Sex Parameter for Clinical Use, and attribute Sex Parameter for Clinical Use with the LOINC® code 99501-9 and LOINC® answer list ID LL6114-4. Where LOINC® answer list ID LL6114-4 references an externally defined value set from HL7®, the codes from that value set may be used.

Technical outcome – A user can record a patient’s sex parameter for clinical use according to the LOINC® codes specified in the “standard(s) referenced” column.

Clarifications:

  • In fulfillment of this requirement, the Health IT Module must be able to record at least one value for Sex Parameter for Clinical Use for each patient. We note that there may also be multiple values tied to different events, such as requesting a laboratory test or imaging study, allowing for and encouraging more than one. [see also 89 FR 1296]
  • Developers of certified health IT have the flexibility to configure their user interface and to capture and display "Sex Parameter for Clinical Use” data in clinical workflows consistent with their own design decisions. [see also 89 FR 1296]
  • We clarify for the requirements at § 170.315(a)(5)(i)(F) that Sex Parameter for Clinical Use must be coded in accordance with, at a minimum, LOINC® v2.72, as specified in § 170.207(c)(1). As reiterated in the HTI-1 Final Rule (89 FR 1196), health IT developers may certify using newer versions of "minimum standards" code sets on a voluntary basis. Accordingly, health IT developers may use newer versions of LOINC® than v2.72 to code Sex Parameter for Clinical Use, and attribute Sex Parameter for Clinical Use with the LOINC® code 99501-9 and LOINC® answer list ID LL6114-4. Where LOINC® answer list ID LL6114-4 references an externally defined value set from HL7®, the codes from that value set may be used.

Paragraph (a)(5)(i)(G) Name to use

Technical outcome – A user can record at least one preferred name to use.

Clarifications:

  • No additional clarifications. 

Technical outcome – A user can record at least one preferred name to use.

Clarifications:

  • No additional clarifications. 

Paragraph (a)(5)(i)(H) Pronouns

Technical outcome – A user can record at least one pronoun according to the LOINC® codes specified in the “standard(s) referenced” column.

Clarifications:

  • No additional clarifications.

Technical outcome – A user can record at least one pronoun according to the LOINC® codes specified in the “standard(s) referenced” column.

Clarifications:

  • No additional clarifications.

Paragraph (a)(5)(ii) Inpatient setting only

Technical outcome – For inpatient settings only, a user must be able to record, change, and access a patient’s preliminary cause of death and date of death.

Clarifications:

  • No standard is required for recording preliminary cause of death and free text is permitted for certification. [see also 77 FR 54209 and 80 FR 62619]

Technical outcome – For inpatient settings only, a user must be able to record, change, and access a patient’s preliminary cause of death and date of death.

Clarifications:

  • No standard is required for recording preliminary cause of death and free text is permitted for certification. [see also 77 FR 54209 and 80 FR 62619]