Clinical quality measures (CQMs) — filter

Clarifications:

• Certain CMS programs require or provide the option for electronic CQM (eCQM) reporting. These programs include the Promoting Interoperability Programs, the Physician Quality Reporting System, the Hospital Inpatient Quality Reporting Program, the Comprehensive Primary Care (CPC) initiative, CPC Plus, and the Value-Based Payment Modifier Program. Each year, CMS issues annual updates to eCQMs (herein referred to as the “CMS annual measure update(s)”) which are published on the Electronic Clinical Quality Improvement (eCQI) Resource Center. The CMS annual measure updates rely upon specific versions of the Quality Reporting Document Architecture (QRDA) Category I and Category III standards. Each year’s QRDA standards are referenced in the corresponding CMS QRDA Implementation Guide (IG) associated with that program year and CMS annual measure update. The CMS QRDA IG also contains additional programmatic form and manner requirements necessary for reporting to CMS programs, which make it necessary for the corresponding testing tool to keep pace with those measure updates and CMS reporting requirements. Thus, health IT developers are permitted to be tested and certified to the applicable CMS annual measure update and use the corresponding versions of QRDA Category I and Category III standards as referenced in the CMS QRDA IG. ONC will evaluate the need for future rulemaking to align the versions of QRDA standards required for this certification criterion with the versions of QRDA standards in the CMS annual measure update.
• For the purposes of automated testing to meet certification requirements, only errors (but not warnings) generated during testing would constitute a failure to meet certification requirements.
• Consistent with Executive Order (EO) 14168 and OPM guidance, Health IT Modules certifying and/or currently certified to this certification criteria at 45 CFR 170.315(c)(4) are only required to demonstrate, for conformance with paragraph (c)(4)(iii)(G) (“patient 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)|
• Further, these Health IT Modules are no longer required to support the following USCDI data elements for purposes of certification:
  • Sexual orientation in USCDI version 4;
  • Gender identity in USCDI version 4;
  • Sex parameter for clinical use in USCDI version 5;
  • Name to use in USCDI version 5;
  • Pronouns in USCDI version 5.

Technical outcome – The health IT can record the data listed in (c)(4)(iii) in accordance with the identified standards where specified.

Clarifications:

• Clarifications for specific data can be found below for paragraph (c)(4)(iii).

Technical outcome – The health IT can filter clinical quality measure (CQM) results at the patient and aggregate levels by each one and any combination of the data listed in (c)(4)(iii). The health IT must be able to create a data file of the filtered data in accordance with:

• HL7® CDA® R2 Implementation Guide: Quality Reporting Document Architecture – Category I (QRDA I); Release 1, DSTU Release 3;
• Quality Reporting Document Architecture Category III, Implementation Guide for CDA Release 2;
• Errata to the HL7® Implementation Guide for CDA® Release 2: Quality Reporting Document Architecture – Category III, DSTU Release 1 (US Realm), September 2014; or
• The corresponding version of the QRDA standard for the CMS annual measure update being certified.

The health IT must also be able to display the filtered data results in human readable format.

Clarifications:

• A Health IT Module must be able to filter by any combination of the proposed data elements (i.e., by any one data element (e.g., provider type) or a combination of any of the data elements). Testing will not cover all possible combinations, but the certification criterion requires all combinations can be demonstrated for certification. The number of combinations tested is at the discretion of the tester. [see also 80 FR 62653]
• No particular workflow must be demonstrated for certification as long as the technical outcome can be achieved. [see also 80 FR 62653]
• eCQMs only use structured data that is electronically documented. Due to the difficulties inherent in successfully mapping unstructured data to their required code sets in a consistent manner and that conforms to required standards, ONC does not require any specific workflow or technical design pertaining to filtering unstructured data as long as the technical outcome of this criterion can be achieved

Clarifications:

• Including TIN in this criterion offers a baseline for filtering by TIN data for certification. We would expect that any programs that may require CQM reporting using TIN would provide additional guidance on the level to use for participation in its programs. [see also 80 FR 62653]

Clarifications:

• Including NPI in this criterion offers a baseline for filtering by NPI data for certification. We would expect that any programs that may require CQM reporting using NPI would provide additional guidance on the level to use for participation in its programs. [see also 80 FR 62653]

Clarifications:

• The CMS Crosswalk: Medicare Provider/Supplier to Healthcare Provider Taxonomy maps the Medicare provider/supplier type to the relevant healthcare provider taxonomy codes. [see also 80 FR 62654]
• When a provider registers for an NPI number, they are required to select at least one provider type code from the code set, but may select more than one code. However, the provider is required to select one code as the primary code. [see also 80 FR 62654]
• The NPI record for a given provider contains all codes a provider selected, and it is expected that CQM results could be filtered by any one of the provider’s selected codes (e.g., primary, secondary, tertiary, etc.). [see also 80 FR 62654]
• Health IT Modules can present for certification to a more recent version of the Crosswalk: Medicare Provider/Supplier to Healthcare Provider Taxonomy than outlined in regulation per ONC’s policy that permits certification to a more recent version of certain vocabulary standards. [see also 80 FR 62612]

Clarifications:

• The testing tool(s) for CQM criteria, including the "CQMfilter" criterion, will test and validate to the HL7^® postal format. Health IT developers and implementers should adhere to the guidance in the QRDA Category I and III standards adopted for this criterion for the HL7^® postal format. [see also 80 FR 62654]
• Note that testing will test for the practice site address where care was provided.

Clarifications:

• No additional clarifications.

Clarifications:

• For this certification criterion, it is intended that “patient age” is derived from the patient’s date of birth, so that a user could query for patients older than a certain age, younger than a certain age, or between a range of ages. [see also 80 FR 62653]

Clarifications:

• No additional clarifications.

Clarifications:

• Note that industry standards (including QRDA) require race and ethnicity be exchanged as separate fields.
• 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]
• 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 outlined in regulation. [see also 80 FR 62612]

Clarifications:

• For testing and certification, a Health IT Module only needs to demonstrate that it can filter by SNOMED CT® codes in the problem list value set referenced in the measure. While ONC indicated in the preamble of the 2015 Edition final rule that testing and certification would focus on the ability of a Health IT Module to filter by the parent level SNOMED CT® codes, ONC did so to address commenters’ concerns about the level of complexity of filtering SNOMED CT® codes for patient problem lists and to lessen the testing and certification burden for health IT developers [80 FR 62655]. After further evaluation and health IT developer feedback, ONC has determined that quality improvement goals can still be achieved and developer burden reduced by testing and certifying the ability of health IT to filter by SNOMED CT® codes in the problem list value set without requiring the mapping of child SNOMED CT® codes to parent SNOMED CT® codes.
• ONC provides the following OID to assist developers in the proper identification and exchange of health information coded to certain vocabulary standards.
  • SNOMED CT® 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 SNOMED CT®, U.S. Edition than the one outlined in regulation per ONC’s policy that permits certification to a more recent version of certain vocabulary standards. [see also 80 FR 62612]