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

§170.315(a)(5) Demographics

Version 1.5 Updated on 09-21-2017
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
Regulation Text
Regulation Text

§170.315 (a)(5) Demographics

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

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

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

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

§ 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

Testing components

Self-Declaration: As of September 21, 2017, the testing approach for this criterion is satisfied by self-declaration.

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

 

System Under Test

Test Lab Verification

The health IT developer submits their self-declaration to the ONC-ATL.

The Tester verifies the self-declaration document contains all of the required data elements.

 

 

Archived Version:
Version 1.7 Updated on 09-29-2017
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
Regulation Text
Regulation Text

§170.315 (a)(5) Demographics

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

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

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

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

§ 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

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.
 

 

Certification Requirements

Privacy and Security: This certification criterion was adopted at § 170.315(a)(5). As a result, an ONC-ACB must ensure that a product presented for certification to a § 170.315(a) “paragraph (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) “VDT” and (e)(2) “secure messaging,” which are explicitly stated.

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
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. [FAQ #10]
  • 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 [http://www.loc.gov/standards/iso639-2/php/code_list.php]
  • 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, nor 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)(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., C-CDA and QRDA). We suggest 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 5 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]
  • We provide the following 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 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) Request for Comments (RFC) 5646 standard. The user must be able to record whether the patient declined to specify preferred language.

Clarifications:

  • § 170.207(g)(2) Request for Comments (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]
  • We provide 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 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]

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 (SO)/gender identity (GI) 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 SO/GI are not required to be exchanged using certain standards, only that systems enable a user to record SO/GI. [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 see also 80 FR 62619]

Content last reviewed on September 21, 2018
Was this page helpful?