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

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

Version 1.2 Updated on 02-22-2018
Revision History
Version # Description of Change Version Date
1.0

Final Test Procedure

08-02-2016
1.1

Updated step numbers for criterion (c)(4)(ii) to correspond correctly between SUT and TLV.

01-10-2017
1.2

Corrected reference to CDC Race & Ethnicity standard.

02-22-2018
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)(1).
    4. Practice site address.
    5. Patient insurance in accordance with, at a minimum, the standard specified in § 170.207(s)(1).
    6. Patient age.
    7. Patient sex in accordance with, at a minimum, the version of the standard specified in § 170.207(n)(1).
    8. Patient race and ethnicity in accordance with, at a minimum, the version of the standard specified in § 170.207(f)(2).
    9. Patient problem list data in accordance with, at a minimum, the version of the standard specified in § 170.207(a)(4).

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

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)

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
     

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

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

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

§ 170.207(a)(4) International Health Terminology Standards Development Organization (IHTSDO) Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®), U.S. Edition, September 2015 Release

Please consult the Final Rule entitled: 2015 Edition Health Information Technology (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications for a detailed description of the certification criterion with which these testing steps are associated. We also encourage developers to consult the Certification Companion Guide in tandem with the test procedure as they provide clarifications that may be useful for product development and testing.

Note: The order in which the test steps are listed reflects the sequence of the certification criterion and does not necessarily prescribe the order in which the test should take place.
 

Testing components

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

 

Paragraph (c)(4)(i)

System Under Test Test Lab Verification

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), Healthcare Provider Taxonomy Code Set (updated 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 Payer 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), “Race & Ethnicity – CDC” code system in the PHIN Vocabulary Access and Distribution System (VADS), Release 3.3.9
    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©

Record

  1. The tester verifies that all of 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.

Paragraph (c)(4)(ii)(A)

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; and
    4. List of certification criteria to be tested. 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® R2 Implementation Guide: Quality Reporting Document Architecture – Category I (QRDA I) DSTU Release 3 (US Realm for all of the data needed to calculate each of the clinical quality measures (CQMs) 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 Import Step 2 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 data set in step 3.
  2. The Health IT Module submits a set of aggregate reports which includes the aggregate reports for all the filtered CQMs.

Filtered QRDA Reports

  1. The user creates a CQM results data file based upon the filtered data in (c)(4)(ii) step 3, 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), DTSU Release 3 (US Realm) 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), HL7 Implementation Guide for CDA® Release 2: Quality Reporting Document Architecture—Category III, DSTU Release 1 (US Realm) with September 2014 Errata; for calculation of the CQMs containing a calculated summary of one or more quality measures for a specific population.
  2. The Health IT Module submits the CQM results data file.

Calculate Filtered Aggregate Reports

  1. Using Cypress, the tester:
    1. uploads the aggregate report(s) submitted from the Health IT Module in step 5 of the SUT; and
    2. evaluates and displays 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.

Filtered QRDA Reports

  1. The tester exports the filtered results and uploads the CQM results data file from the Health IT Module in step 7 of the SUT.
  2. Using Cypress validation, the CQM results data file and the aggregate files from the Health IT Module step 6 of the SUT, the tester verifies that the Health IT Module can created 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).

Alternative: Cypress Certification API

  1. A user may use the Cypress Certification API to perform steps 2-7 of the SUT. The tester can verify the results in Cypress as normal, however, the tester should manually perform verification steps 2-7 for at least one CQM to ensure this functionality is present.

Paragraph (c)(4)(ii)(B)

System Under Test Test Lab Verification

Display Filtered Data Results

  1. Using the Health IT Module and the filtered data created in (c)(4)(ii)(A) step 3, 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 that the Health IT Module can demonstrate the ability to display the filtered data created in (c)(4)(ii) step 3 in human readable format using Visual Inspection.
  2. Using the Cypress Test Tool User Interface, the tester verifies that the displayed filtered data displayed in (c)(4)(ii)(B) SUT step 1 compare to the Cypress User interface aggregate report, and compare the denominator, numerator and exclusions with the expected results.

Paragraph (c)(4)(iii)

System Under Test Test Lab Verification

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), Healthcare Provider Taxonomy Code Set (updated 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 Payer 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 attributed as follows:
    1. Male. M
    2. Female. F
    3. Unknown. UNK
  8. Patient race and ethnicity in accordance with, at a minimum, the version of the standard specified in § 170.207(f)(2), “Race & Ethnicity – CDC” code system in the PHIN Vocabulary Access and Distribution System (VADS), Release 3.3.9.
  9. Patient problem list data in accordance with, at a minimum, the version of the standard specified in § 170.207(a)(4), SNOMED-CT©.

The tester verifies that 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 that the tester verifies all combinations, rather demonstrate that the filtering ability includes filtering any combination of the data values


Alternative Test Method

Summary Alternative Test Method File Test Tool Updated On

NCQA was approved as an ONC-Approved Alternate Test Method June 19, 2017 for testing § 170.315(c)(2), § 170.315(c)(3), and § 170.315(c)(4).

NCQA tests and validates the integrity of an HIT organization’s software code that calculates eCQM results and produces Quality Reporting Document Architecture (QRDA) reports.

Our eMeasure Certification program uses the same ONC-approved methodology, but the certification is used to reduce the audit on supplemental HEDIS data and is not part of the ONC program.

Version 1.4 Updated on 04-06-2018
Revision History
Version # Description of Change Version Date
1.0

Initial Publication

12-18-2015
1.1

Revised to include clarification about testing and certification to versions of standards associated with the CMS annual measure updates.

01-10-2017
1.2

Revised to clarify the requirements for filtering by SNOMED CT® codes for problem list data.

04-24-2017
1.3

Revised to include an ONC approved alternative test procedure, tool and data offered by the National Committee for Quality Assurance (NCQA).

Revised to clarify the requirements for the practice site address data element.

08-04-2017
1.4

Added clarification for paragraph (c)(4)(ii) regarding expectations for filtering unstructured data.

04-06-2018
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)(1).
    4. Practice site address.
    5. Patient insurance in accordance with, at a minimum, the standard specified in § 170.207(s)(1).
    6. Patient age.
    7. Patient sex in accordance with, at a minimum, the version of the standard specified in § 170.207(n)(1).
    8. Patient race and ethnicity in accordance with, at a minimum, the version of the standard specified in § 170.207(f)(2).
    9. Patient problem list data in accordance with, at a minimum, the version of the standard specified in § 170.207(a)(4).

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

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)

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
     

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

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

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

§ 170.207(a)(4) International Health Terminology Standards Development Organization (IHTSDO) Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®), U.S. Edition, September 2015 Release

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

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

 

Certification Requirements

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

Design and Performance: The following design and performance certification criteria (adopted in § 170.315(g)) must also be certified in order for the product to be certified.

  • When a single quality management system (QMS) is used, the QMS only needs to be identified once. Otherwise, the QMS’ need to be identified for every capability to which it was applied.
  • When a single accessibility-centered design standard is used, the standard only needs to be identified once. Otherwise, the accessibility-centered design standards need to be identified for every capability to which they were applied; or, alternatively the developer must state that no accessibility-centered design was used.
Table for Privacy and Security
Technical Explanations and Clarifications

 

Applies to entire criterion

Clarifications:

  • Certain CMS programs require or provide the option for electronic CQM (eCQM) reporting. These programs include the EHR Incentive Program, 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)

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)

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

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]

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

Clarifications:

  • The CMS Crosswalk: Medicare Provider/Supplier to Healthcare Provider Taxonomy, April 2, 2015 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 the April 2, 2015 release 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 2015 Edition 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 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 available.

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]

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]

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]
  • We provide the following OID to assist developers in the proper identification and exchange of health information coded to certain vocabulary standards.
    • “Race & Ethnicity” - CDC code system OID: 2.16.840.1.113883.6.238 [see also 80 FR 62612]
  • Health IT Modules can present for certification to a more recent version of the “Race & Ethnicity” – CDC code system than Version 1.0. [see also 80 FR 62612]

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 we 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, we 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, we have 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.
  • We provide 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 September 2015 Release per ONC’s policy that permits certification to a more recent version of certain vocabulary standards. [see also 80 FR 62612]

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)(1).
    4. Practice site address.
    5. Patient insurance in accordance with, at a minimum, the standard specified in § 170.207(s)(1).
    6. Patient age.
    7. Patient sex in accordance with, at a minimum, the version of the standard specified in § 170.207(n)(1).
    8. Patient race and ethnicity in accordance with, at a minimum, the version of the standard specified in § 170.207(f)(2).
    9. Patient problem list data in accordance with, at a minimum, the version of the standard specified in § 170.207(a)(4).

Testing Tool
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 a eCQM software implementation to process and accurately calculate results.

Content last reviewed on April 13, 2018
Was this page helpful?