Clinical Quality Measures 2015 Edition : What is New?

by Nadeem Nazeer

Learn more and try it yourself

Contact Us for a Demo

Let us take a look at requirements needed for the 2015 Edition Health IT Certification Criteria for EHRs.

The 2015 Edition Health IT Certification Criteria (2015 Edition) builds on past rule makings to facilitate greater interoperability for several clinical health information purposes and enables health information exchange through new and enhanced certification criteria, standards, and implementation specifications. Taking into account public comments received on the 2015 Proposed Rule, the final rule continues to focus on the establishment of an interoperable nationwide health information infrastructure.(1)

For the first time, ONC is providing Certification Companion Guides to accompany the 2015 Edition certification criteria. The Certification Companion Guides provide development guidance and technical clarifications to complement the 2015 Edition test procedures in a single, consolidated source for certification criteria clarifications. The Certification Companion Guides are intended to assist with product development in preparation for ONC Health IT Certification Program requirements for testing and certification.(2)

 

certification-process-glance

The Certification Process at a Glance(3)

 

The four major criteria mentioned about CQM are:

Regulation Text Citation Certification Criterion Certification Companion Guide (CCG)
§ 170.315(c)(1) Clinical quality measures (CQMs) – record and export Guide
§ 170.315(c)(2) CQMs – import and calculate Guide
§ 170.315(c)(3) CQMs – report Guide
§ 170.315(c)(4) CQMs – filter Guide

 

 1. Clinical quality measures (CQMs) – record and export

(i) Record: For each and every CQM for which the technology is presented for certification, technology must be able to record all of the data that would be necessary to calculate each CQM. Data required for CQM exclusions or exceptions must be codified entries, which may include specific terms as defined by each CQM, or may include codified expressions of “patient reason”, “system reason”, or “medical reason”.

Clarifications:

  • Providers may employ many methods to capture the information required by CQMs. Not all data must be manually entered through a user interface into the health IT. For example, information transferred from other systems can meet the requirements for “capture.”
  • Data required for CQM exclusion or exceptions must be codified entries and may include specific terms defined by each CQM selected. Free text is permitted to be captured in addition to the minimum requirement to capture data as a codified entry.
  • Specific reasons why an action was performed or not performed to determine whether the patient meets an exclusion or exception should be recorded as part of the generated QRDA Category I file.

(ii) Export: A user can export a data file formatted in accordance with HL7 QRDA Category I Release 3 for one or multiple patients that includes all of the data captured.

Clarifications:

  • A user of this health IT must be able to create these reports at any time selected without additional assistance from health IT developers. This will allow a provider or health system to view and verify their CQM results for quality improvement on a near real-time basis. It also gives providers the ability to export their results to multiple programs, such as those run by CMS, states, and private payers, and/or reporting solutions, such as registries or other types of data intermediaries.
  • Providers and health systems should determine the protocols around when and how providers export CQM data. For testing, the health IT would need to demonstrate a user can export data formatted to QRDA Category I for one or more patients without needing additional developer support.

2. CQMs – Import and Calculate

(i) Import:  A user can import a data file formatted in accordance with HL7 QRDA Category I Release 3 for one or multiple patients in order to perform calculations on the CQMs presented for certification.

Clarifications:

  • A user of this health IT must be able to import a data file at any time selected without additional assistance from health IT developers. We are not prescribing how data is imported into a system (e.g., mapped to backend database or viewable to a provider as part of the patient record) and leave the determination at the discretion of the developer.
  • This provision will streamline testing and certification by importing QRDA Category I files avoiding the need for systems to manually enter test patient data. It will also promote quality improvement and data sharing between systems by providing the systems the ability to import CQM data from other systems in a standardized format.
  • Providers and health systems should determine the protocols around when and how providers import CQM data. For testing, the health IT would need to demonstrate a user can import data formatted to QRDA Category I for one or more patients without needing additional developer support.
  • We would expect that health IT must be able to de-duplicate patient records, but do not prescribe how systems would demonstrate de-duplication. Developers have the discretion to determine the most suitable method for deduplication.
  • Testing will more robustly test the pathways by which a patient is included in the numerator and/or denominator, including exclusions and exceptions, of a measure.

(ii) Calculate: The health IT must be able to calculate each CQM presented for certification.

3. Clinical quality measures – Report

A user can create a data file for transmission of CQM data in QRDA Category I (for individual level reports) and Category III (for aggregate reports) as specified in the HL7 CDA® Release 2 Implementation Guide for: Quality Reporting Document Architecture – Category I (QRDA I), DTSU Release 3 and Implementation Guide for CDA® Release 2: Quality Reporting Document Architecture—Category III, DSTU Release 1 (US Realm) with September 2014 Errata, respectively.

Optional report: As an optional provision, a user can create a data file for transmission of CQM data that can be electronically accepted by CMS.

Clarifications:

  • The requirements for CMS reporting will be published by CMS in documents such as the CMS QRDA Implementation Guide. CMS will indicate in its regulations and program guidance whether this optional provision is required for participation in its programs.
  • This provision is optional because providers may use technology certified to this criterion for reporting to programs that do not require the same QRDA reporting provisions of CMS programs.
  • The following links are references to CMS CQM reporting resources:
    CMS and ONC eCQI Resource Center
    CMS Quality Measure Basics
    CMS 2015 CQM Reporting Options
    eCQM Library

4. Clinical quality measures – Filter

1. Health IT can record data listed for below sections in accordance with the identified standards where specified.

(A)  Taxpayer Identification Number.

(B)  National Provider Identifier.

(C)  Provider type.

(D)  Practice site address.

(E)  Patient insurance.

(F)  Patient age.

(G)  Patient sex.

(H)  Patient race and ethnicity.

(I)  Patient problem list data.

2. 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 above. 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; and
– Errata to the HL7 Implementation Guide for CDA® Release 2: Quality Reporting Document Architecture – Category III, DSTU Release 1 (US Realm), September 2014.

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.
  • No particular workflow must be demonstrated for certification as long as the technical outcome can be achieved.

3. Data:

(A)  Taxpayer Identification Number:

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.

(B)  National Provider Identifier:

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.

(C)  Provider type:

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

(D)  Practice site address:

The Cypress testing tool for 2015 Edition CQMs criteria, including for CQM filtering, 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. Note that testing will test for the site address of the site that bills for care rather than the mailing address of the provider itself.

(E)  Patient insurance: Coded in  Source of Payment Typology Code Set Version 5.0 (October 2011)

(F)  Patient age:

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.

(G)  Patient sex:

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.

(H)  Patient race and ethnicity:

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

(I)  Patient problem list data:

  • For testing and certification, a Health IT Module only needs to demonstrate it can filter by a SNOMED CT® code and related codes in the problem list value set by measure.
  • 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
  • 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.

For more details about standards checkout the links provided in section below and consult the guides mentioned in above table.

For any queries just email me at: nadeem@trialx.com

References:

  1. https://www.healthit.gov/policy-researchers-implementers/2015-edition-final-rule
  2. https://www.healthit.gov/policy-researchers-implementers/2015-edition-test-method
  3. https://www.healthit.gov/policy-researchers-implementers/about-onc-health-it-certification-program

 

Learn more and try it yourself

Contact Us for a Demo

Leave a Reply

Your email address will not be published. Required fields are marked *

Healthcare Informatics Solutions

Healthcare IT news, developments, opinions and solutions

Contact us now

Popular Posts