Patient demographics and observations

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.
• Consistent with Executive Order (EO) 14168 and OPM guidance, Health IT Modules certifying and/or currently certified to the demographics certification criteria at 45 CFR 170.315(a)(5) are only required to demonstrate, for conformance with paragraph (a)(5)(i)(C) (“sex”), that it can record sex in accordance with either the standard specified in § 170.207(n)(1) for the period up to and including December 31, 2025, or the following SNOMED CT® codes found in the standard specified in § 170.207(n)(2):
  • 248152002 |Female (finding)|; and
  • 248153007 |Male (finding)|.
• Health IT Modules certified to § 170.315(a)(5), are not required to demonstrate conformance with paragraphs:
  • (a)(5)(i)(D) (“sexual orientation”);
  • (a)(5)(i)(E) (“gender identity”);
  • (a)(5)(i)(F) (“sex parameters for clinical use”);
  • (a)(5)(i)(G) (“name to use”); and
  • (a)(5)(i)(H) (“pronouns”).

Clarifications:

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

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 CDC Race and Ethnicity (CDCREC) 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;
  • Hispanic or Latino; and
  • Not 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 CDCREC 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 categories. 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 five OMB race categories and two ethnicity categories at once to show multi-race, multi-ethnicity selection, support across the 900+ value set, and ultimately accurate roll-up.
• The Health IT Module must be able to record multiple races and/or ethnicities for a patient. [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.
  • CDCREC 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 CDCREC code system than what is presented in regulation. [see also 80 FR 62612]
• The concepts in the CDCREC code system are 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 granular race and ethnicity values are correctly mapped to the OMB categories. The mapping of these codes uses the hierarchical relationships defined in CDCREC.
• The health IT must be able to represent race and ethnicity categories in the § 170.207(f)(1) The OMB Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity standard using CDCREC. The use of more granular values is permitted, so long as they map to the OMB categories.
• The § 170.207(f)(1) The OMB Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity standard provides two formats for the collection of race and ethnicity data. The first format collects data using two separate questions. The second format, the “combined format”, collects data using a single question. Implementation using either format is acceptable for the purposes of certification.
• A product does not need to display all the race and ethnicity values 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 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 sex according to HL7^® Version 3 as male (M), and female (F), up to and including December 31, 2025, or the SNOMED CT^® U.S. Edition codes specified at § 170.207(a)(1).

Clarifications:

• No additional clarifications

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:

• Consistent with EO 14168, Health IT Modules certified to § 170.315(a)(5) are not required to demonstrate conformance with this paragraph.

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:

• Consistent with EO 14168, Health IT Modules certified to § 170.315(a)(5) are not required to demonstrate conformance with this paragraph.

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

Clarifications:

• Consistent with EO 14168, Health IT Modules certified to § 170.315(a)(5) are not required to demonstrate conformance with this paragraph.

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

Clarifications:

• Consistent with EO 14168, Health IT Modules certified to § 170.315(a)(5) are not required to demonstrate conformance with this paragraph.

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]