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

§170.315(c)(4) Clinical quality measures (CQMs) — filter

Updated on 03-11-2024
Regulation Text
Regulation Text

§ 170.315 (c)(4) Clinical quality measures—filter—

  1. Record the data listed in paragraph (c)(4)(iii) of this section in accordance with the identified standards, where specified.
  2. Filter CQM results at the patient and aggregate levels by each one and any combination of the data listed in paragraph (c)(4)(iii) of this section and be able to:
    1. Create a data file of the filtered data in accordance with the standards adopted in § 170.205(h)(2) and § 170.205(k)(1) and (2); and
    2. Display the filtered data results in human readable format.
  3. Data.
    1. Taxpayer Identification Number.
    2. National Provider Identifier.
    3. Provider type in accordance with, at a minimum, the standard specified in § 170.207(r)(2).
    4. Practice site address.
    5. Patient insurance in accordance with, at a minimum, the standard specified in § 170.207(s)(2).
    6. Patient age.
    7. Patient sex in accordance with, at a minimum, the version of the standard specified in § 170.207(n)(2).
    8. Patient race and ethnicity in accordance with, at a minimum, the version of the standard specified in § 170.207(f)(3).
    9. Patient problem list data in accordance with, at a minimum, the version of the standard specified in § 170.207(a)(1).
Standard(s) Referenced

Paragraph (c)(4)(i)

Refer to paragraph (c)(4)(iii) below for standards where specified.

Paragraph (c)(4)(ii)

§ 170.205(h)(2) Health Level 7 (HL7®) CDA® Release 2 Implementation Guide for: Quality Reporting Document Architecture – Category I (QRDA I); Release 1, DSTU Release 3 (US Realm), Volume 1

§ 170.205(k)(1) Quality Reporting Document Architecture Category III, Implementation Guide for CDA Release 2

§ 170.205(k)(2) Errata to the HL7® Implementation Guide for CDA® Release 2: Quality Reporting Document Architecture—Category III, DSTU Release 1 (US Realm), September 2014

Paragraph (c)(4)(iii)(C) Provider Type

§ 170.207(r)(1) Crosswalk: Medicare Provider/Supplier to Healthcare Provider Taxonomy, April 2, 2015 (Adoption of this standard expires on January 1, 2026)

§ 170.207(r)(2) Medicare Provider and Supplier Taxonomy Crosswalk, October 29, 2021 (This standard is required by December 31, 2025)

Paragraph (c)(4)(iii)(E) Patient insurance

§ 170.207(s)(1) Public Health Data Standards Consortium Source of Payment Typology Code Set Version 5.0 (October 2011) (Adoption of this standard expires on January 1, 2026)

§ 170.207(s)(2) Public Health Data Standards Consortium Source of Payment Typology Code Set, December 2020, Version 9.2 (This standard is required by December 31, 2025)

Paragraph (c)(4)(iii)(G) Patient sex

§ 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. NullFlavor UNK

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

§ 170.207(n)(2) Standard. SNOMED CT®, U.S. Edition, March 2022 Release

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)

Paragraph (c)(4)(iii)(H) Patient race and ethnicity

§ 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 (c)(4)(iii)(I) Patient problem list

§ 170.207(a)(4) International Health Terminology Standards Development Organisation (IHTSDO) Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®), U.S. Edition, September 2015 Release (Adoption of this standard expires on January 1, 2026)

§ 170.207(a)(1) SNOMED CT®, U.S. Edition, March 2022 Release  (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 one’s certification under Certification Dependencies.

Deadline: December 31, 2025

Action to be taken: Developers certified to this criterion must update their use of standards outlined in paragraphs (c)(4)(iii)(E), (G), (H) and (I).

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.

  • 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(c)(4). As a result, an ONC Authorized Certification Body (ONC-ACB) must ensure that a product presented for certification to a § 170.315(c) 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 (c) 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 tested 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 (c)(4) Clinical quality measures—filter—

  1. Record the data listed in paragraph (c)(4)(iii) of this section in accordance with the identified standards, where specified.
  2. Filter CQM results at the patient and aggregate levels by each one and any combination of the data listed in paragraph (c)(4)(iii) of this section and be able to:
    1. Create a data file of the filtered data in accordance with the standards adopted in § 170.205(h)(2) and § 170.205(k)(1) and (2); and
    2. Display the filtered data results in human readable format.
  3. Data.
    1. Taxpayer Identification Number.
    2. National Provider Identifier.
    3. Provider type in accordance with, at a minimum, the standard specified in § 170.207(r)(2).
    4. Practice site address.
    5. Patient insurance in accordance with, at a minimum, the standard specified in § 170.207(s)(2).
    6. Patient age.
    7. Patient sex in accordance with, at a minimum, the version of the standard specified in § 170.207(n)(2).
    8. Patient race and ethnicity in accordance with, at a minimum, the version of the standard specified in § 170.207(f)(3).
    9. Patient problem list data in accordance with, at a minimum, the version of the standard specified in § 170.207(a)(1).
Standard(s) Referenced

Paragraph (c)(4)(i)

Refer to paragraph (c)(4)(iii) below for standards where specified.

Paragraph (c)(4)(ii)

§ 170.205(h)(2) Health Level 7 (HL7®) CDA® Release 2 Implementation Guide for: Quality Reporting Document Architecture – Category I (QRDA I); Release 1, DSTU Release 3 (US Realm), Volume 1

§ 170.205(k)(1) Quality Reporting Document Architecture Category III, Implementation Guide for CDA Release 2

§ 170.205(k)(2) Errata to the HL7® Implementation Guide for CDA® Release 2: Quality Reporting Document Architecture—Category III, DSTU Release 1 (US Realm), September 2014

Paragraph (c)(4)(iii)(C) Provider Type

§ 170.207(r)(1) Crosswalk: Medicare Provider/Supplier to Healthcare Provider Taxonomy, April 2, 2015 (Adoption of this standard expires on January 1, 2026)

§ 170.207(r)(2) Medicare Provider and Supplier Taxonomy Crosswalk, October 29, 2021 (This standard is required by December 31, 2025)

Paragraph (c)(4)(iii)(E) Patient insurance

§ 170.207(s)(1) Public Health Data Standards Consortium Source of Payment Typology Code Set Version 5.0 (October 2011) (Adoption of this standard expires on January 1, 2026)

§ 170.207(s)(2) Public Health Data Standards Consortium Source of Payment Typology Code Set, December 2020, Version 9.2 (This standard is required by December 31, 2025)

Paragraph (c)(4)(iii)(G) Patient sex

§ 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. NullFlavor UNK

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

§ 170.207(n)(2) Standard. SNOMED CT®, U.S. Edition, March 2022 Release

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)

Paragraph (c)(4)(iii)(H) Patient race and ethnicity

§ 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 (c)(4)(iii)(I) Patient problem list

§ 170.207(a)(4) International Health Terminology Standards Development Organisation (IHTSDO) Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®), U.S. Edition, September 2015 Release (Adoption of this standard expires on January 1, 2026)

§ 170.207(a)(1) SNOMED CT®, U.S. Edition, March 2022 Release  (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 one’s certification under Certification Dependencies.

Deadline: December 31, 2025

Action to be taken: Developers certified to this criterion must update their use of standards outlined in paragraphs (c)(4)(iii)(E), (G), (H) and (I).

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.

  • 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(c)(4). As a result, an ONC Authorized Certification Body (ONC-ACB) must ensure that a product presented for certification to a § 170.315(c) 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 (c) 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 tested 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.

Testing
Testing Tool

Cypress

 

Criterion Subparagraph Test Data
(c)(4)(ii)

Cypress Gold Standard Test Data created using Cypress - “Category III Filter Test” test data instructions

The Cypress patient test data consists of:

  • Synthetic patients designed to interact with and provide measure steward approved, gold standard expected results for the Electronic Clinical Quality Measures (eCQMs) selected for CMS quality reporting programs for Eligible Clinicians and Eligible Professionals (EP/EC), and for Eligible Hospital (EH) and Critical Access Hospitals (CAH). Cypress test patients are developed to cover at least 95% of possible eCQM logic pathways.

These standardized set of patient test data will be used as the primary evaluation mechanism for Electronic Health Record (EHR) vendor performance on clinical quality measure implementations via the Cypress software. It has not been designed to be an exhaustive test of all logical elements. Instead, the patient test data has been designed instead to provide a simplified and standardized representation of common population information for an eCQM software implementation to process and accurately calculate results.
Revision History
Version # Description of Change Version Date
1.0

Initial publication
03-11-2024

This Test Procedure illustrates the test steps required to certify a Health IT Module to this criterion. Please consult the most recent ONC Final Rule on the Certification Regulations page for a detailed description of the certification criterion with which these testing steps are associated. ONC also encourages developers to consult the Certification Companion Guide in tandem with the test procedure as it provides clarifications that may be useful for product development and testing.

Note: The test step order does not necessarily prescribe the order in which the tests should take place.

Testing components

No Documentation Icon Visual Inspection Icon Test Tool Icon ONC Supplied Test Data Icon No SVAP Icon

Paragraph (c)(4)(i) Record

System Under Test
Expires on January 1, 2026

Record

  1. For each quality measure being certified, the user records the data elements used to filter the Clinical Quality Measure(s) (CQM) data specified in (c)(4)(iii) in accordance with the identified standards where specified into a patient record:
    1. Taxpayer Identification Number
    2. National Provider Identifier
    3. Provider type in accordance with, at a minimum, the standard specified in § 170.207(r)(1)Crosswalk: Medicare Provider/Supplier to Healthcare Provider Taxonomy, April 2, 2015
    4. Practice site address
    5. Patient insurance in accordance with the standard specified in § 170.207(s)(1) Public Health Data Standards Consortium Source of Payment Typology Code Set Version 5.0 (October 2011)
    6. Patient age (Calculated from the Patient Date of Birth)
    7. Patient sex in accordance with the version of the standard specified in § 170.207(n)(1) Birth sex must be coded in accordance with HL7® Version 3 Value Sets for AdministrativeGender and NullFlavor attributed as follows:
      1. Male. M
      2. Female. F
      3. Unknown. nullFlavor UNK
    8. Patient race and ethnicity in accordance with, at a minimum, the version of the standard specified in § 170.207(f)(2) CDC Race and Ethnicity Code Set Version 1.0 (March 2000)
    9. Patient problem list data as defined by the CQM value sets in the certified CQMs. Patient problem list data should support the version of the standard specified in § 170.207(a)(4) SNOMED-CT®
Required by December 31, 2025
  1. For each quality measure being certified, the user records the data elements used to filter the Clinical Quality Measure(s) (CQM) data specified in (c)(4)(iii) in accordance with the identified standards where specified into a patient record:
  • Taxpayer Identification Number
  • National Provider Identifier
  • Provider type in accordance with, at a minimum, the standard specified in § 170.207(r)(2) Medicare Provider and Supplier Taxonomy Crosswalk, October 29, 2021
  • Practice site address
  • Patient insurance in accordance with the standard specified in § 170.207(s)(2) Public Health Data Standards Consortium Source of Payment Typology Code Set, December 2020, Version 9.2
  • Patient age (Calculated from the Patient Date of Birth)
  • Patient sex in accordance with the version of the standard specified in § 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).
  • Patient race and ethnicity in accordance with, at a minimum, the version of the standard specified in § 170.207(f)(3) CDC Race and Ethnicity Code Set Version 1.2 (July 15, 2021)
  • Patient problem list data as defined by the CQM value sets in the certified CQMs. Patient problem list data should support the version of the standard specified in § 170.207(a)(1) SNOMED-CT®
Test Lab Verification
Expires on January 1, 2026

Record

  1. The tester verifies all the CQM data can be recorded by the Health IT Module, in accordance with the identified standards, where specified in (c)(4)(iii).

Packaging of Results

  1. Upon completion of the test, the tester generates a test artifact containing:
    1. All of the test data used to test (c)(4)(ii)(A);
    2. All of the data generated by the Health IT Module; and
    3. Any additional notes that the tester deems important into a single archive file.
Required by December 31, 2025

Record

  1. The tester verifies all the CQM data can be recorded by the Health IT Module, in accordance with the identified standards, where specified in (c)(4)(iii).

Packaging of Results

  1. Upon completion of the test, the tester generates a test artifact containing:
  • All of the test data used to test (c)(4)(ii)(A);
  • All of the data generated by the Health IT Module; and
  • Any additional notes that the tester deems important into a single archive file.
System Under Test Test Lab Verification
Expires on January 1, 2026

Record

  1. For each quality measure being certified, the user records the data elements used to filter the Clinical Quality Measure(s) (CQM) data specified in (c)(4)(iii) in accordance with the identified standards where specified into a patient record:
    1. Taxpayer Identification Number
    2. National Provider Identifier
    3. Provider type in accordance with, at a minimum, the standard specified in § 170.207(r)(1)Crosswalk: Medicare Provider/Supplier to Healthcare Provider Taxonomy, April 2, 2015
    4. Practice site address
    5. Patient insurance in accordance with the standard specified in § 170.207(s)(1) Public Health Data Standards Consortium Source of Payment Typology Code Set Version 5.0 (October 2011)
    6. Patient age (Calculated from the Patient Date of Birth)
    7. Patient sex in accordance with the version of the standard specified in § 170.207(n)(1) Birth sex must be coded in accordance with HL7® Version 3 Value Sets for AdministrativeGender and NullFlavor attributed as follows:
      1. Male. M
      2. Female. F
      3. Unknown. nullFlavor UNK
    8. Patient race and ethnicity in accordance with, at a minimum, the version of the standard specified in § 170.207(f)(2) CDC Race and Ethnicity Code Set Version 1.0 (March 2000)
    9. Patient problem list data as defined by the CQM value sets in the certified CQMs. Patient problem list data should support the version of the standard specified in § 170.207(a)(4) SNOMED-CT®
Required by December 31, 2025
  1. For each quality measure being certified, the user records the data elements used to filter the Clinical Quality Measure(s) (CQM) data specified in (c)(4)(iii) in accordance with the identified standards where specified into a patient record:
  • Taxpayer Identification Number
  • National Provider Identifier
  • Provider type in accordance with, at a minimum, the standard specified in § 170.207(r)(2) Medicare Provider and Supplier Taxonomy Crosswalk, October 29, 2021
  • Practice site address
  • Patient insurance in accordance with the standard specified in § 170.207(s)(2) Public Health Data Standards Consortium Source of Payment Typology Code Set, December 2020, Version 9.2
  • Patient age (Calculated from the Patient Date of Birth)
  • Patient sex in accordance with the version of the standard specified in § 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).
  • Patient race and ethnicity in accordance with, at a minimum, the version of the standard specified in § 170.207(f)(3) CDC Race and Ethnicity Code Set Version 1.2 (July 15, 2021)
  • Patient problem list data as defined by the CQM value sets in the certified CQMs. Patient problem list data should support the version of the standard specified in § 170.207(a)(1) SNOMED-CT®
Expires on January 1, 2026

Record

  1. The tester verifies all the CQM data can be recorded by the Health IT Module, in accordance with the identified standards, where specified in (c)(4)(iii).

Packaging of Results

  1. Upon completion of the test, the tester generates a test artifact containing:
    1. All of the test data used to test (c)(4)(ii)(A);
    2. All of the data generated by the Health IT Module; and
    3. Any additional notes that the tester deems important into a single archive file.
Required by December 31, 2025

Record

  1. The tester verifies all the CQM data can be recorded by the Health IT Module, in accordance with the identified standards, where specified in (c)(4)(iii).

Packaging of Results

  1. Upon completion of the test, the tester generates a test artifact containing:
  • All of the test data used to test (c)(4)(ii)(A);
  • All of the data generated by the Health IT Module; and
  • Any additional notes that the tester deems important into a single archive file.

Paragraph (c)(4)(ii)(A) Create a data file of filtered data 

System Under Test

Setup

  1. The Health IT Module provides the following information in order to enable the creation of the (c)(1)(i) “Cypress Gold Standard Test Data” which includes instructions to enable the recording of CQM data within patient record(s):
    1. Name of the health IT developer;
    2. Name of the product;
    3. List of CQMs to be certified;
    4. List of certification criteria to be tested; and 
    5. Instructions on how a user can filter and export patient data using the Health IT Module.

Import

  1. Using the "Cypress Gold Standard Test Data" a user demonstrates the importing of reports formatted in accordance with the standard specified at § 170.205(h)(2) HL7® CDA® Release 2 Implementation Guide for: Quality Reporting Document Architecture – Category I (QRDA I); Release 1, DSTU Release 3, volume 1, for all of the data needed to calculate each of the clinical quality measures (CQMs) presented for testing, for one or multiple patients.

Cypress Certification API (Alternative)

  1. The Health IT Module may use the Cypress Certification API to perform the import of patient records presented for testing, for one or multiple patients.

Filter

  1. For each CQM being certified: Using the “Filter Tests” instructions and the Health IT Module, the user applies the filters against the same patient data in the Import step in order to demonstrate the ability to filter the CQM results at the patient and aggregate levels by each one and any combination of the CQM data elements specified in (c)(4)(iii):
    1. Taxpayer Identification Number
    2. National Provider Identifier
    3. Provider type
    4. Practice site address
    5. Patient insurance
    6. Patient age (Calculated from Patient date of birth)
    7. Patient sex
    8. Patient race and ethnicity
    9. Patient problem list
      This includes the following types of filtering:
      • Filter by individual data elements; 
      • Filter with any combination of filter data elements.

Calculate Filtered Aggregate Reports

  1. The user calculates the aggregate reports (as specified in (c)(2)(ii)) for each filter applied to the imported dataset in the Import step.
  2. The Health IT Module submits a set of aggregate reports which includes the aggregate reports for all the filtered CQMs.
  3. The user creates a CQM results data file based upon the filtered data completed in the Filter step, in accordance with the standards adopted in § 170.205(h)(2) HL7® CDA® Release 2, Implementation Guide for: Quality Reporting Document Architecture – Category I (QRDA I); Release 1, DSTU Release 3, Volume 1, for one or more patients with one or more quality measures; using at a minimum, § 170.205(k)(1) Quality Reporting Document Architecture Category III, Implementation Guide for CDA Release 2, and § 170.205(k)(2) Errata to the HL7® Implementation Guide for CDA® Release 2: Quality Reporting Document Architecture—Category III, DSTU Release 1, for calculation of the CQMs containing a calculated summary of one or more quality measures for a specific population.
  4. The Health IT Module submits the CQM results data file.

Cypress Certification API (Alternative)

  1. The Health IT Module may use the Cypress Certification API to perform the submission of the CQM results data file.
Test Lab Verification

Verification of Filtered Aggregate Reports

  1. Using the Cypress Test Tool User Interface, the tester:
    1. Uploads the set of aggregate reports which includes the aggregate reports for all the filtered CQMs submitted from the Health IT Module; and
    2. Displays and evaluates the accuracy of the submitted CQM results.
  2. The verification should include at least:
    1. Two multi-factor (at least two criteria) filter tests based on patient information;
    2. Two multi-factor (at least two criteria) filter tests based on provider information; and
    3. A filter test based on patient problem list.

      Note: All filter tests in Cypress use AND logic in multi-factor tests.
  3. The tester exports the filtered results and uploads the CQM results data file submitted from the Health IT Module.
  4. Using Cypress validation, the CQM results data file and the aggregate files from the Health IT Module, the tester verifies that the Health IT Module can create a filtered CQM results data file at the patient and aggregate levels, in accordance with at a minimum the standards adopted in § 170.205(h)(2), and § 170.205(k)(1) and (2).

Cypress Certification API (Alternative)

  1. If a Health IT Module uses the Cypress Certification API to perform the import of patient records, the submission of a set of aggregate reports, or the submission of the CQM results data file (the steps under the Cypress Certification API (Alternative) sections), the tester will not need to perform the upload actions of the aggregate reports of the CQM results data file specified above (as these have already been performed by the Health IT Module using the API). The tester can verify the results in Cypress as normal, however, the tester should manually perform verification of the accuracy of the submitted CQM results and ensure that it includes at least two multi-factor filter tests based on patient information and provider information for at least one CQM to ensure this functionality is present. Testers are permitted to randomly select, at their discretion, which individual patient from the batch entry recording will be used to export a QRDA Category I file in order to demonstrate the functionality is present. The tester instructs the health IT developer to export the selected patient and confirms that this patient was exported.
System Under Test Test Lab Verification

Setup

  1. The Health IT Module provides the following information in order to enable the creation of the (c)(1)(i) “Cypress Gold Standard Test Data” which includes instructions to enable the recording of CQM data within patient record(s):
    1. Name of the health IT developer;
    2. Name of the product;
    3. List of CQMs to be certified;
    4. List of certification criteria to be tested; and 
    5. Instructions on how a user can filter and export patient data using the Health IT Module.

Import

  1. Using the "Cypress Gold Standard Test Data" a user demonstrates the importing of reports formatted in accordance with the standard specified at § 170.205(h)(2) HL7® CDA® Release 2 Implementation Guide for: Quality Reporting Document Architecture – Category I (QRDA I); Release 1, DSTU Release 3, volume 1, for all of the data needed to calculate each of the clinical quality measures (CQMs) presented for testing, for one or multiple patients.

Cypress Certification API (Alternative)

  1. The Health IT Module may use the Cypress Certification API to perform the import of patient records presented for testing, for one or multiple patients.

Filter

  1. For each CQM being certified: Using the “Filter Tests” instructions and the Health IT Module, the user applies the filters against the same patient data in the Import step in order to demonstrate the ability to filter the CQM results at the patient and aggregate levels by each one and any combination of the CQM data elements specified in (c)(4)(iii):
    1. Taxpayer Identification Number
    2. National Provider Identifier
    3. Provider type
    4. Practice site address
    5. Patient insurance
    6. Patient age (Calculated from Patient date of birth)
    7. Patient sex
    8. Patient race and ethnicity
    9. Patient problem list
      This includes the following types of filtering:
      • Filter by individual data elements; 
      • Filter with any combination of filter data elements.

Calculate Filtered Aggregate Reports

  1. The user calculates the aggregate reports (as specified in (c)(2)(ii)) for each filter applied to the imported dataset in the Import step.
  2. The Health IT Module submits a set of aggregate reports which includes the aggregate reports for all the filtered CQMs.
  3. The user creates a CQM results data file based upon the filtered data completed in the Filter step, in accordance with the standards adopted in § 170.205(h)(2) HL7® CDA® Release 2, Implementation Guide for: Quality Reporting Document Architecture – Category I (QRDA I); Release 1, DSTU Release 3, Volume 1, for one or more patients with one or more quality measures; using at a minimum, § 170.205(k)(1) Quality Reporting Document Architecture Category III, Implementation Guide for CDA Release 2, and § 170.205(k)(2) Errata to the HL7® Implementation Guide for CDA® Release 2: Quality Reporting Document Architecture—Category III, DSTU Release 1, for calculation of the CQMs containing a calculated summary of one or more quality measures for a specific population.
  4. The Health IT Module submits the CQM results data file.

Cypress Certification API (Alternative)

  1. The Health IT Module may use the Cypress Certification API to perform the submission of the CQM results data file.

Verification of Filtered Aggregate Reports

  1. Using the Cypress Test Tool User Interface, the tester:
    1. Uploads the set of aggregate reports which includes the aggregate reports for all the filtered CQMs submitted from the Health IT Module; and
    2. Displays and evaluates the accuracy of the submitted CQM results.
  2. The verification should include at least:
    1. Two multi-factor (at least two criteria) filter tests based on patient information;
    2. Two multi-factor (at least two criteria) filter tests based on provider information; and
    3. A filter test based on patient problem list.

      Note: All filter tests in Cypress use AND logic in multi-factor tests.
  3. The tester exports the filtered results and uploads the CQM results data file submitted from the Health IT Module.
  4. Using Cypress validation, the CQM results data file and the aggregate files from the Health IT Module, the tester verifies that the Health IT Module can create a filtered CQM results data file at the patient and aggregate levels, in accordance with at a minimum the standards adopted in § 170.205(h)(2), and § 170.205(k)(1) and (2).

Cypress Certification API (Alternative)

  1. If a Health IT Module uses the Cypress Certification API to perform the import of patient records, the submission of a set of aggregate reports, or the submission of the CQM results data file (the steps under the Cypress Certification API (Alternative) sections), the tester will not need to perform the upload actions of the aggregate reports of the CQM results data file specified above (as these have already been performed by the Health IT Module using the API). The tester can verify the results in Cypress as normal, however, the tester should manually perform verification of the accuracy of the submitted CQM results and ensure that it includes at least two multi-factor filter tests based on patient information and provider information for at least one CQM to ensure this functionality is present. Testers are permitted to randomly select, at their discretion, which individual patient from the batch entry recording will be used to export a QRDA Category I file in order to demonstrate the functionality is present. The tester instructs the health IT developer to export the selected patient and confirms that this patient was exported.

Paragraph (c)(4)(ii)(B) Display filtered data results in human readable format

System Under Test

Display Filtered Data Results

  1. Using the Health IT Module and the filtered data created for each CQM being certified in (c)(4)(ii)(A), the user can display the filtered data results in human readable format including the display of the following information for each of the measures: 
    1. patient population;
    2. denominator;
    3. numerator;
    4. exclusions; and
    5. exceptions.
Test Lab Verification

Display Filtered Data Results

  1. The tester verifies the Health IT Module can demonstrate the ability to display the filtered data that was created for each CQM being certified in (c)(4)(ii) in human readable format using visual inspection.
  2. Using the Cypress Test Tool User Interface, the tester verifies the displayed filtered data displayed during the SUT step compares to the Cypress User interface aggregate report, and compares the denominator, numerator, and exclusions with the expected results.
System Under Test Test Lab Verification

Display Filtered Data Results

  1. Using the Health IT Module and the filtered data created for each CQM being certified in (c)(4)(ii)(A), the user can display the filtered data results in human readable format including the display of the following information for each of the measures: 
    1. patient population;
    2. denominator;
    3. numerator;
    4. exclusions; and
    5. exceptions.

Display Filtered Data Results

  1. The tester verifies the Health IT Module can demonstrate the ability to display the filtered data that was created for each CQM being certified in (c)(4)(ii) in human readable format using visual inspection.
  2. Using the Cypress Test Tool User Interface, the tester verifies the displayed filtered data displayed during the SUT step compares to the Cypress User interface aggregate report, and compares the denominator, numerator, and exclusions with the expected results.

Paragraph (c)(4)(iii) Data

System Under Test
Expires on January 1, 2026

The following data elements are used to filter the CQM Results using the health IT developer-identified health IT function(s) in accordance with the identified standards, where specified.

  1. Taxpayer Identification Number
  2. National Provider Identifier
  3. Provider type in accordance with, at a minimum, the standard specified in § 170.207(r)(1) Crosswalk: Medicare Provider/Supplier to Healthcare Provider Taxonomy, April 2, 2015
  4. Practice site address
  5. Patient insurance in accordance with the standard specified in § 170.207(s)(1) Public Health Data Standards Consortium Source of Payment Typology Code Set Version 5.0 (October 2011)
  6. Patient age (Calculated from the Patient Date of Birth)
  7. Patient sex in accordance with the version of the standard specified in § 170.207(n)(1) Birth sex must be coded in accordance with HL7® Version 3, Value Sets for AdministrativeGender and NullFlavor attributed as follows:
    1. Male. M
    2. Female. F
    3. Unknown. nullFlavor_UNK
  8. Patient race and ethnicity in accordance with, at a minimum, the version of the standard specified in § 170.207(f)(2) CDC Race and Ethnicity Code Set Version 1.0 (March 2000)
  9. Patient problem list data in accordance with, at a minimum, the version of the standard specified in § 170.207(a)(4) SNOMED-CT®
Required by December 31, 2025

The following data elements are used to filter the CQM Results using the health IT developer-identified health IT function(s) in accordance with the identified standards, where specified.

  1. Taxpayer Identification Number
  2. National Provider Identifier
  3. Provider type in accordance with, at a minimum, the standard specified in § 170.207(r)(2) Medicare Provider and Supplier Taxonomy Crosswalk, October 29, 2021
  4. Practice site address
  5. Patient insurance in accordance with the standard specified in § 170.207(s)(2) Public Health Data Standards Consortium Source of Payment Typology Code Set, December 2020, Version 9.2
  6. Patient age (Calculated from the Patient Date of Birth)
  7. Patient sex in accordance with the version of the standard specified in § 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).
  8. Patient race and ethnicity in accordance with, at a minimum, the version of the standard specified in § 170.207(f)(3) CDC Race and Ethnicity Code Set Version 1.2 (July 15, 2021)
  9. Patient problem list data in accordance with, at a minimum, the version of the standard specified in § 170.207(a)(1) SNOMED-CT®
Test Lab Verification
Expires on January 1, 2026

The tester verifies the Health IT Module supports all of the CQM data elements specified in (c)(4)(iii) in accordance with the identified standards, where specified through the verification of: (c)(4)(i), (c)(4)(ii)(A) and (c)(4)(ii)(B).

Note: There is no expectation the tester verifies all combinations, rather they should demonstrate the filtering ability includes filtering any combination of the data values.

Required by December 31, 2025

The tester verifies the Health IT Module supports all of the CQM data elements specified in (c)(4)(iii) in accordance with the identified standards, where specified through the verification of: (c)(4)(i), (c)(4)(ii)(A) and (c)(4)(ii)(B).

Note: There is no expectation the tester verifies all combinations, rather they should demonstrate the filtering ability includes filtering any combination of the data values.

System Under Test Test Lab Verification
Expires on January 1, 2026

The following data elements are used to filter the CQM Results using the health IT developer-identified health IT function(s) in accordance with the identified standards, where specified.

  1. Taxpayer Identification Number
  2. National Provider Identifier
  3. Provider type in accordance with, at a minimum, the standard specified in § 170.207(r)(1) Crosswalk: Medicare Provider/Supplier to Healthcare Provider Taxonomy, April 2, 2015
  4. Practice site address
  5. Patient insurance in accordance with the standard specified in § 170.207(s)(1) Public Health Data Standards Consortium Source of Payment Typology Code Set Version 5.0 (October 2011)
  6. Patient age (Calculated from the Patient Date of Birth)
  7. Patient sex in accordance with the version of the standard specified in § 170.207(n)(1) Birth sex must be coded in accordance with HL7® Version 3, Value Sets for AdministrativeGender and NullFlavor attributed as follows:
    1. Male. M
    2. Female. F
    3. Unknown. nullFlavor_UNK
  8. Patient race and ethnicity in accordance with, at a minimum, the version of the standard specified in § 170.207(f)(2) CDC Race and Ethnicity Code Set Version 1.0 (March 2000)
  9. Patient problem list data in accordance with, at a minimum, the version of the standard specified in § 170.207(a)(4) SNOMED-CT®
Required by December 31, 2025

The following data elements are used to filter the CQM Results using the health IT developer-identified health IT function(s) in accordance with the identified standards, where specified.

  1. Taxpayer Identification Number
  2. National Provider Identifier
  3. Provider type in accordance with, at a minimum, the standard specified in § 170.207(r)(2) Medicare Provider and Supplier Taxonomy Crosswalk, October 29, 2021
  4. Practice site address
  5. Patient insurance in accordance with the standard specified in § 170.207(s)(2) Public Health Data Standards Consortium Source of Payment Typology Code Set, December 2020, Version 9.2
  6. Patient age (Calculated from the Patient Date of Birth)
  7. Patient sex in accordance with the version of the standard specified in § 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).
  8. Patient race and ethnicity in accordance with, at a minimum, the version of the standard specified in § 170.207(f)(3) CDC Race and Ethnicity Code Set Version 1.2 (July 15, 2021)
  9. Patient problem list data in accordance with, at a minimum, the version of the standard specified in § 170.207(a)(1) SNOMED-CT®
Expires on January 1, 2026

The tester verifies the Health IT Module supports all of the CQM data elements specified in (c)(4)(iii) in accordance with the identified standards, where specified through the verification of: (c)(4)(i), (c)(4)(ii)(A) and (c)(4)(ii)(B).

Note: There is no expectation the tester verifies all combinations, rather they should demonstrate the filtering ability includes filtering any combination of the data values.

Required by December 31, 2025

The tester verifies the Health IT Module supports all of the CQM data elements specified in (c)(4)(iii) in accordance with the identified standards, where specified through the verification of: (c)(4)(i), (c)(4)(ii)(A) and (c)(4)(ii)(B).

Note: There is no expectation the tester verifies all combinations, rather they should demonstrate the filtering ability includes filtering any combination of the data values.
Updated on 03-11-2024
Regulation Text
Regulation Text

§ 170.315 (c)(4) Clinical quality measures—filter—

  1. Record the data listed in paragraph (c)(4)(iii) of this section in accordance with the identified standards, where specified.
  2. Filter CQM results at the patient and aggregate levels by each one and any combination of the data listed in paragraph (c)(4)(iii) of this section and be able to:
    1. Create a data file of the filtered data in accordance with the standards adopted in § 170.205(h)(2) and § 170.205(k)(1) and (2); and
    2. Display the filtered data results in human readable format.
  3. Data.
    1. Taxpayer Identification Number.
    2. National Provider Identifier.
    3. Provider type in accordance with, at a minimum, the standard specified in § 170.207(r)(2).
    4. Practice site address.
    5. Patient insurance in accordance with, at a minimum, the standard specified in § 170.207(s)(2).
    6. Patient age.
    7. Patient sex in accordance with, at a minimum, the version of the standard specified in § 170.207(n)(2).
    8. Patient race and ethnicity in accordance with, at a minimum, the version of the standard specified in § 170.207(f)(3).
    9. Patient problem list data in accordance with, at a minimum, the version of the standard specified in § 170.207(a)(1).
Standard(s) Referenced

Paragraph (c)(4)(i)

Refer to paragraph (c)(4)(iii) below for standards where specified.

Paragraph (c)(4)(ii)

§ 170.205(h)(2) Health Level 7 (HL7®) CDA® Release 2 Implementation Guide for: Quality Reporting Document Architecture – Category I (QRDA I); Release 1, DSTU Release 3 (US Realm), Volume 1

§ 170.205(k)(1) Quality Reporting Document Architecture Category III, Implementation Guide for CDA Release 2

§ 170.205(k)(2) Errata to the HL7® Implementation Guide for CDA® Release 2: Quality Reporting Document Architecture—Category III, DSTU Release 1 (US Realm), September 2014

Paragraph (c)(4)(iii)(C) Provider Type

§ 170.207(r)(1) Crosswalk: Medicare Provider/Supplier to Healthcare Provider Taxonomy, April 2, 2015 (Adoption of this standard expires on January 1, 2026)

§ 170.207(r)(2) Medicare Provider and Supplier Taxonomy Crosswalk, October 29, 2021 (This standard is required by December 31, 2025)

Paragraph (c)(4)(iii)(E) Patient insurance

§ 170.207(s)(1) Public Health Data Standards Consortium Source of Payment Typology Code Set Version 5.0 (October 2011) (Adoption of this standard expires on January 1, 2026)

§ 170.207(s)(2) Public Health Data Standards Consortium Source of Payment Typology Code Set, December 2020, Version 9.2 (This standard is required by December 31, 2025)

Paragraph (c)(4)(iii)(G) Patient sex

§ 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. NullFlavor UNK

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

§ 170.207(n)(2) Standard. SNOMED CT®, U.S. Edition, March 2022 Release

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)

Paragraph (c)(4)(iii)(H) Patient race and ethnicity

§ 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 (c)(4)(iii)(I) Patient problem list

§ 170.207(a)(4) International Health Terminology Standards Development Organisation (IHTSDO) Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®), U.S. Edition, September 2015 Release (Adoption of this standard expires on January 1, 2026)

§ 170.207(a)(1) SNOMED CT®, U.S. Edition, March 2022 Release  (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 one’s certification under Certification Dependencies.

Deadline: December 31, 2025

Action to be taken: Developers certified to this criterion must update their use of standards outlined in paragraphs (c)(4)(iii)(E), (G), (H) and (I).

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.

  • 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(c)(4). As a result, an ONC Authorized Certification Body (ONC-ACB) must ensure that a product presented for certification to a § 170.315(c) 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 (c) 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 tested 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 (c)(4) Clinical quality measures—filter—

  1. Record the data listed in paragraph (c)(4)(iii) of this section in accordance with the identified standards, where specified.
  2. Filter CQM results at the patient and aggregate levels by each one and any combination of the data listed in paragraph (c)(4)(iii) of this section and be able to:
    1. Create a data file of the filtered data in accordance with the standards adopted in § 170.205(h)(2) and § 170.205(k)(1) and (2); and
    2. Display the filtered data results in human readable format.
  3. Data.
    1. Taxpayer Identification Number.
    2. National Provider Identifier.
    3. Provider type in accordance with, at a minimum, the standard specified in § 170.207(r)(2).
    4. Practice site address.
    5. Patient insurance in accordance with, at a minimum, the standard specified in § 170.207(s)(2).
    6. Patient age.
    7. Patient sex in accordance with, at a minimum, the version of the standard specified in § 170.207(n)(2).
    8. Patient race and ethnicity in accordance with, at a minimum, the version of the standard specified in § 170.207(f)(3).
    9. Patient problem list data in accordance with, at a minimum, the version of the standard specified in § 170.207(a)(1).
Standard(s) Referenced

Paragraph (c)(4)(i)

Refer to paragraph (c)(4)(iii) below for standards where specified.

Paragraph (c)(4)(ii)

§ 170.205(h)(2) Health Level 7 (HL7®) CDA® Release 2 Implementation Guide for: Quality Reporting Document Architecture – Category I (QRDA I); Release 1, DSTU Release 3 (US Realm), Volume 1

§ 170.205(k)(1) Quality Reporting Document Architecture Category III, Implementation Guide for CDA Release 2

§ 170.205(k)(2) Errata to the HL7® Implementation Guide for CDA® Release 2: Quality Reporting Document Architecture—Category III, DSTU Release 1 (US Realm), September 2014

Paragraph (c)(4)(iii)(C) Provider Type

§ 170.207(r)(1) Crosswalk: Medicare Provider/Supplier to Healthcare Provider Taxonomy, April 2, 2015 (Adoption of this standard expires on January 1, 2026)

§ 170.207(r)(2) Medicare Provider and Supplier Taxonomy Crosswalk, October 29, 2021 (This standard is required by December 31, 2025)

Paragraph (c)(4)(iii)(E) Patient insurance

§ 170.207(s)(1) Public Health Data Standards Consortium Source of Payment Typology Code Set Version 5.0 (October 2011) (Adoption of this standard expires on January 1, 2026)

§ 170.207(s)(2) Public Health Data Standards Consortium Source of Payment Typology Code Set, December 2020, Version 9.2 (This standard is required by December 31, 2025)

Paragraph (c)(4)(iii)(G) Patient sex

§ 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. NullFlavor UNK

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

§ 170.207(n)(2) Standard. SNOMED CT®, U.S. Edition, March 2022 Release

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)

Paragraph (c)(4)(iii)(H) Patient race and ethnicity

§ 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 (c)(4)(iii)(I) Patient problem list

§ 170.207(a)(4) International Health Terminology Standards Development Organisation (IHTSDO) Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®), U.S. Edition, September 2015 Release (Adoption of this standard expires on January 1, 2026)

§ 170.207(a)(1) SNOMED CT®, U.S. Edition, March 2022 Release  (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 one’s certification under Certification Dependencies.

Deadline: December 31, 2025

Action to be taken: Developers certified to this criterion must update their use of standards outlined in paragraphs (c)(4)(iii)(E), (G), (H) and (I).

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.

  • 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(c)(4). As a result, an ONC Authorized Certification Body (ONC-ACB) must ensure that a product presented for certification to a § 170.315(c) 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 (c) 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 tested 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
Testing Tool

Cypress

 

Criterion Subparagraph Test Data
(c)(4)(ii)

Cypress Gold Standard Test Data created using Cypress - “Category III Filter Test” test data instructions

The Cypress patient test data consists of:

  • Synthetic patients designed to interact with and provide measure steward approved, gold standard expected results for the Electronic Clinical Quality Measures (eCQMs) selected for CMS quality reporting programs for Eligible Clinicians and Eligible Professionals (EP/EC), and for Eligible Hospital (EH) and Critical Access Hospitals (CAH). Cypress test patients are developed to cover at least 95% of possible eCQM logic pathways.

These standardized set of patient test data will be used as the primary evaluation mechanism for Electronic Health Record (EHR) vendor performance on clinical quality measure implementations via the Cypress software. It has not been designed to be an exhaustive test of all logical elements. Instead, the patient test data has been designed instead to provide a simplified and standardized representation of common population information for an eCQM software implementation to process and accurately calculate results.

Certification Companion Guide: Clinical quality measures (CQMs) — filter

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
Not Included No No No Yes
Certification Requirements
Technical Explanations and Clarifications

Applies to entire criterion

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.

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.

Paragraph (c)(4)(i) Record data

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

Paragraph (c)(4)(ii) Filter CQM results

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.

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.

Paragraph (c)(4)(iii)(A) Taxpayer Identification Number (TIN)

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

Paragraph (c)(4)(iii)(B) National Provider Identifier (NPI)

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:

  • 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]

Paragraph (c)(4)(iii)(C) Provider type

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

Paragraph (c)(4)(iii)(D) Practice site address

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:

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

Paragraph (c)(4)(iii)(E) Patient insurance

Clarifications:

  • No additional clarifications.

Clarifications:

  • No additional clarifications.

Paragraph (c)(4)(iii)(F) Patient age

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:

  • 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]

Paragraph (c)(4)(iii)(G) Patient sex

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. [see also 80 FR 62618]

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. [see also 80 FR 62618]

Paragraph (c)(4)(iii)(H) Patient race and ethnicity

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:

  • 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]

Paragraph (c)(4)(iii)(I) Patient problem list

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]

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]