§170.315(a)(5) Demographics

2015 Edition Cures Update CCG
2015 Edition Cures Update Conformance Method

Updated on 08-25-2021

Revision History

Version #	Description of Change	Version Date
1.0	Final Test Procedure	01-08-2016
1.1	Updated the referenced standards and provided additional links.	04-08-2016
1.2	Added reference to standard §170.207(f)(1) in step (i)1(A) and requirement that the SUT can record and aggregate a min of two races.	07-29-2016
1.3	Added clarification to step (i) that two races and separately two ethnicities must be tested. Updated link to the race and ethnicity standard.	09-19-2016
1.4	Added regulation text detail specifying the demographic details including aggregation requirements. Updated the referenced standards to provide links and download instructions for the enumerated race and ethnicities and a pointer to the aggregation mapping table for race and ethnicity.	05-26-2017
1.5	As of September 21, 2017, Test Procedure has been moved to Attestation/Developer self-declaration only.	09-21-2017
1.6	Changes language from self-declaration to attestation	08-25-2021

Regulation Text

§ 170.315 (a)(5) Demographics—

Enable a user to record, change, and access patient demographic data including race, ethnicity, preferred language, sex, sexual orientation, gender identity, 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)(2) 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)(2) 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).
4. Sexual orientation. Enable sexual orientation to be recorded in accordance with the standard specified in § 170.207(o)(1) and whether a patient declines to specify sexual orientation.
5. Gender identity. Enable gender identity to be recorded in accordance with the standard specified in § 170.207(o)(2) and whether a patient declines to specify gender identity.
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)(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:

Male. M
Female. F
Unknown. UNK

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:

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

§ 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:

Identifies as Male. 446151000124109
Identifies as 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

Resource Documents

Resource Document

Revision History

Version #	Description of Change	Version Date
1.0	Final Test Procedure	01-08-2016
1.1	Updated the referenced standards and provided additional links.	04-08-2016
1.2	Added reference to standard §170.207(f)(1) in step (i)1(A) and requirement that the SUT can record and aggregate a min of two races.	07-29-2016
1.3	Added clarification to step (i) that two races and separately two ethnicities must be tested. Updated link to the race and ethnicity standard.	09-19-2016
1.4	Added regulation text detail specifying the demographic details including aggregation requirements. Updated the referenced standards to provide links and download instructions for the enumerated race and ethnicities and a pointer to the aggregation mapping table for race and ethnicity.	05-26-2017
1.5	As of September 21, 2017, Test Procedure has been moved to Attestation/Developer self-declaration only.	09-21-2017
1.6	Changes language from self-declaration to attestation	08-25-2021

Regulation Text

Regulation Text

§ 170.315 (a)(5) Demographics—

Enable a user to record, change, and access patient demographic data including race, ethnicity, preferred language, sex, sexual orientation, gender identity, 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)(2) 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)(2) 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).
4. Sexual orientation. Enable sexual orientation to be recorded in accordance with the standard specified in § 170.207(o)(1) and whether a patient declines to specify sexual orientation.
5. Gender identity. Enable gender identity to be recorded in accordance with the standard specified in § 170.207(o)(2) and whether a patient declines to specify gender identity.
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

Applies to entire criterion

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

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

§ 170.207(f)(2) CDC Race and Ethnicity Code Set Version 1.0 (March 2000)

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:

Male. M
Female. F
Unknown. UNK

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

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

Identifies as Male. 446151000124109
Identifies as 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

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) Demographics requirements.	The ONC-ACB verifies the health IT developer attests conformance to the §170.315(a)(5) Demographics requirements.

Archived Version:

§170.315(a)(5) Test Procedure

Updated on 06-15-2020

Revision History

Version #	Description of Change	Version Date
1.0	Initial Publication	10-22-2015
1.1	Made a technical correction to the SNOMED CT® code for “straight or heterosexual”. Provided a clarification regarding the mapping of the concepts in the “Race & Ethnicity” – CDC code system to the race and ethnicity categories in the § 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.	12-18-2015
1.2	Added clarification for scope of testing to RFC 5646.	03-24-2016
1.3	Corrected the gender descriptors for "male" and "female" to "identifies as male" and "identifies as female" in § 170.207(o)(2).	06-20-2016
1.4	Updated link to the race and ethnicity standard.	09-16-2016
1.5	Provided link instructions for both the detailed CDC Race and Ethnicity coded values and the CDCREC Roll-up codes.	05-26-2017
1.6	Added clarification that the health IT must support recording each one of a patient’s races and ethnicities and that all the recorded races and ethnicities must be aggregated to the appropriate OMB codes.	07-28-2017
1.7	Provided instructions for accessing and navigating to the appropriate CDCREC Roll-up Codes (paragraph (i)(A) of the criterion).	09-29-2017
1.8	Updated the Security requirements per 21st Century Cures Act.	06-15-2020

Regulation Text

§ 170.315 (a)(5) Demographics—

Enable a user to record, change, and access patient demographic data including race, ethnicity, preferred language, sex, sexual orientation, gender identity, 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)(2) 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)(2) 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).
4. Sexual orientation. Enable sexual orientation to be recorded in accordance with the standard specified in § 170.207(o)(1) and whether a patient declines to specify sexual orientation.
5. Gender identity. Enable gender identity to be recorded in accordance with the standard specified in § 170.207(o)(2) and whether a patient declines to specify gender identity.
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

Applies to entire criterion

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

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

§ 170.207(f)(2) CDC Race and Ethnicity Code Set Version 1.0 (March 2000)

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:

Male. M
Female. F
Unknown. UNK

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

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

Identifies as Male. 446151000124109
Identifies as 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

Resource Documents

Resource Document

Revision History

Version #	Description of Change	Version Date
1.0	Initial Publication	10-22-2015
1.1	Made a technical correction to the SNOMED CT® code for “straight or heterosexual”. Provided a clarification regarding the mapping of the concepts in the “Race & Ethnicity” – CDC code system to the race and ethnicity categories in the § 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.	12-18-2015
1.2	Added clarification for scope of testing to RFC 5646.	03-24-2016
1.3	Corrected the gender descriptors for "male" and "female" to "identifies as male" and "identifies as female" in § 170.207(o)(2).	06-20-2016
1.4	Updated link to the race and ethnicity standard.	09-16-2016
1.5	Provided link instructions for both the detailed CDC Race and Ethnicity coded values and the CDCREC Roll-up codes.	05-26-2017
1.6	Added clarification that the health IT must support recording each one of a patient’s races and ethnicities and that all the recorded races and ethnicities must be aggregated to the appropriate OMB codes.	07-28-2017
1.7	Provided instructions for accessing and navigating to the appropriate CDCREC Roll-up Codes (paragraph (i)(A) of the criterion).	09-29-2017
1.8	Updated the Security requirements per 21st Century Cures Act.	06-15-2020

Regulation Text

Regulation Text

§ 170.315 (a)(5) Demographics—

Enable a user to record, change, and access patient demographic data including race, ethnicity, preferred language, sex, sexual orientation, gender identity, 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)(2) 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)(2) 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).
4. Sexual orientation. Enable sexual orientation to be recorded in accordance with the standard specified in § 170.207(o)(1) and whether a patient declines to specify sexual orientation.
5. Gender identity. Enable gender identity to be recorded in accordance with the standard specified in § 170.207(o)(2) and whether a patient declines to specify gender identity.
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

Applies to entire criterion

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

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

§ 170.207(f)(2) CDC Race and Ethnicity Code Set Version 1.0 (March 2000)

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:

Male. M
Female. F
Unknown. UNK

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

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

Identifies as Male. 446151000124109
Identifies as 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

Certification Companion Guide: Demographics

This Certification Companion Guide (CCG) is an informative document designed to assist with health IT product development. The CCG is not a substitute for the 2015 Edition final regulation. It extracts key portions of the rule’s preamble and includes subsequent clarifying interpretations. To access the full context of regulatory intent please consult the 2015 Edition final rule or other included regulatory reference. The CCG is for public use and should not be sold or redistributed.

Link to Final Rule Preamble

Link to Correction Notice Preamble

Base EHR Definition	In Scope for CEHRT Definition	Real World Testing	USCDI	SVAP
Included	Yes	No	No	No

Certification Requirements

Privacy and Security: 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.

Table for Privacy and Security

If choosing Approach 1:
If choosing Approach 2:
- For each applicable privacy and security certification criterion not certified for Approach 1, the health IT developer may certify using system documentation which is sufficiently detailed to enable integration such that the Health IT Module has implemented service interfaces the Health IT Module to access external services necessary to meet the requirements of the privacy and security certification criterion. Please see the 21^st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Final Rule at 85 FR 25710 for additional clarification.

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

Table for Design and Performance

Certification Requirements

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.

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

Table for Privacy and Security

If choosing Approach 1:
If choosing Approach 2:
- For each applicable privacy and security certification criterion not certified for Approach 1, the health IT developer may certify using system documentation which is sufficiently detailed to enable integration such that the Health IT Module has implemented service interfaces the Health IT Module to access external services necessary to meet the requirements of the privacy and security certification criterion. Please see the 21^st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Final Rule at 85 FR 25710 for additional clarification.

Table for Design and Performance

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

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

Paragraph (a)(5)(i)

Clarifications:

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

Paragraph (a)(5)(i)

Clarifications:

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

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

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.0.
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.
- “Race & Ethnicity” - CDC code system 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 Version 1.0. [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)(A)

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.0.
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.
- “Race & Ethnicity” - CDC code system 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 Version 1.0. [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)

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)(B)

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)

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

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]

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

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

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]

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. The user must be able to record whether the patient declined to specify sexual orientation and/or gender identity.

Clarifications:

Note that while sexual orientation/gender identity are included in this 2015 Edition “Demographics” certification criterion and the 2015 Edition Base EHR definition, it is not included in the Common Clinical Data Set definition. This means that sexual orientation and gender identity are not required to be exchanged using certain standards, only that systems enable a user to record sexual orientation and gender identity. [see also 80 FR 62619]
While we are not requiring certification to structured and coded questions for soliciting SO/GI, we suggested that health care providers and institutions decide whether to include these questions in the collection of SO/GI information as “best practices”:
- Do you think of yourself as:
  - [Straight or heterosexual;
  - Lesbian, gay, or homosexual;
  - Bisexual;
  - Something else, please describe;
  - Don’t know.]
- What is your current gender identity? (Check all that apply.)
  - [Male;
  - Female;
  - Transgender male/Trans man/Female-to-male;
  - Transgender female/Trans woman/Male-to-female;
  - Genderqueer, neither exclusively male nor female;
  - Additional gender category/(or other), please specify;
  - Decline to answer.] [see also 80 FR 62620]
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]

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

Clarifications:

Note that while sexual orientation/gender identity are included in this 2015 Edition “Demographics” certification criterion and the 2015 Edition Base EHR definition, it is not included in the Common Clinical Data Set definition. This means that sexual orientation and gender identity are not required to be exchanged using certain standards, only that systems enable a user to record sexual orientation and gender identity. [see also 80 FR 62619]
While we are not requiring certification to structured and coded questions for soliciting SO/GI, we suggested that health care providers and institutions decide whether to include these questions in the collection of SO/GI information as “best practices”:
- Do you think of yourself as:
  - [Straight or heterosexual;
  - Lesbian, gay, or homosexual;
  - Bisexual;
  - Something else, please describe;
  - Don’t know.]
- What is your current gender identity? (Check all that apply.)
  - [Male;
  - Female;
  - Transgender male/Trans man/Female-to-male;
  - Transgender female/Trans woman/Male-to-female;
  - Genderqueer, neither exclusively male nor female;
  - Additional gender category/(or other), please specify;
  - Decline to answer.] [see also 80 FR 62620]
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]

Paragraph (a)(5)(ii)

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]

Paragraph (a)(5)(ii)

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]