§170.315(c)(2) Clinical quality measures (CQMs) — import and calculate
§170.315(c)(2)
Updated on 03-11-2024
Regulation Text
Regulation Text
§ 170.315 (c)(2) Clinical quality measures—import and calculate—
- Import. Enable a user to import a data file in accordance with the standard specified in § 170.205(h)(2) for one or multiple patients and use such data to perform the capability specified in paragraph (c)(2)(ii) of this section. A user must be able to execute this capability at any time the user chooses and without subsequent developer assistance to operate.
- Calculate each and every clinical quality measure for which it is presented for certification.
Standard(s) Referenced
Paragraph (c)(2)(i)
Standards Version Advancement Process (SVAP) Version(s) Approved
For more information, please visit the Standards Version Advancement Process (SVAP) Version(s) page.
Additional Resources
§ 170.205(k)(1) Quality Reporting Document Architecture Category III, Implementation Guide for CDA Release 2
Certification Dependencies
Conditions and Maintenance of Certification
Real World Testing: Products certified to this criterion must complete requirements outlined for the Real World Testing Conditions and Maintenance of Certification.
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)(2). 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 (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.
- If choosing Approach 1:
- Authentication, access control, and authorization (§ 170.315(d)(1))
- Auditable events and tamper-resistance (§ 170.315(d)(2))
- Audit reports (§ 170.315(d)(3))
- Automatic access time-out (§ 170.315(d)(5))
- Encrypt authentication credentials (§ 170.315(d)(12))
- Multi-factor authentication (MFA) (§ 170.315(d)(13))
- If choosing Approach 2:
- For each applicable privacy and security certification criterion not certified for Approach 1, the health IT developer may certify using system documentation which is sufficiently detailed to enable integration such that the Health IT Module has implemented service interfaces the Health IT Module to access external services necessary to meet the requirements of the privacy and security certification criterion. Please see the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Final Rule at 85 FR 25710 for additional clarification.
Revision History
| Version # | Description of Change | Version Date |
|---|---|---|
| 1.0 |
Final Test Procedure. |
03-11-2024
|
- Regulation Text
-
Regulation Text
§ 170.315 (c)(2) Clinical quality measures—import and calculate—
- Import. Enable a user to import a data file in accordance with the standard specified in § 170.205(h)(2) for one or multiple patients and use such data to perform the capability specified in paragraph (c)(2)(ii) of this section. A user must be able to execute this capability at any time the user chooses and without subsequent developer assistance to operate.
- Calculate each and every clinical quality measure for which it is presented for certification.
- Standard(s) Referenced
-
Paragraph (c)(2)(i)
Standards Version Advancement Process (SVAP) Version(s) Approved
For more information, please visit the Standards Version Advancement Process (SVAP) Version(s) page.
Additional Resources
§ 170.205(k)(1) Quality Reporting Document Architecture Category III, Implementation Guide for CDA Release 2
- Certification Dependencies
-
Conditions and Maintenance of Certification
Real World Testing: Products certified to this criterion must complete requirements outlined for the Real World Testing Conditions and Maintenance of Certification.
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)(2). 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 (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.
- If choosing Approach 1:
- Authentication, access control, and authorization (§ 170.315(d)(1))
- Auditable events and tamper-resistance (§ 170.315(d)(2))
- Audit reports (§ 170.315(d)(3))
- Automatic access time-out (§ 170.315(d)(5))
- Encrypt authentication credentials (§ 170.315(d)(12))
- Multi-factor authentication (MFA) (§ 170.315(d)(13))
- If choosing Approach 2:
- For each applicable privacy and security certification criterion not certified for Approach 1, the health IT developer may certify using system documentation which is sufficiently detailed to enable integration such that the Health IT Module has implemented service interfaces the Health IT Module to access external services necessary to meet the requirements of the privacy and security certification criterion. Please see the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Final Rule at 85 FR 25710 for additional clarification.
- Testing
-
Testing Tool
Criterion Subparagraph Test Data (c)(2)(i) (c)(2)(ii) - Revision History
-
Version # Description of Change Version Date 1.0 Final Test Procedure.
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
Paragraph (c)(2)(i) Import
System Under Test
Execute Any Time
- The health IT developer supplies documentation outlining how a user can execute the import capability described in (c)(2)(i) any time the user chooses and without subsequent developer assistance to operate.
Setup
- The Health IT Module provides the following information in order to enable the creation of the (c)(2)(i) “Cypress Gold Standard Test Data” which includes instructions to enable the recording of CQM data within patient record(s):
- Name of the health IT developer;
- Name of the product;
- List of CQMs to be certified; and
- List of certification criteria to be tested
Import
- 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 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.
Approved SVAP Version(s)
- 170.205(h)(2) HL7® CDA® R2 Implementation Guide for: Quality Reporting Document Architecture – Category I (QRDA I); Release 1, STU Release 5.3 with errata - US Realm, December 2022
Test Lab Verification
Execute Any Time
- The tester verifies the health IT developer supplied documentation outlines that a user can perform an import as specified in (c)(2)(i) any time the user chooses and without subsequent developer assistance to operate.
Setup
- The tester creates the "Cypress Gold Standard Test Data" based upon the information provided by the health IT developer, in Cypress, which will create a new (c)(2) test instance.
Import
- Using visual inspection, the tester verifies the Health IT Module can demonstrate the importing of CQM data specified in accordance with the standard at § 170.205(h)(2).
| System Under Test | Test Lab Verification |
|---|---|
|
Execute Any Time
Setup
Import
Approved SVAP Version(s)
|
Execute Any Time
Setup
Import
|
Paragraph (c)(2)(ii) Calculate
System Under Test
Calculate
- The user calculates the aggregate reports for each of the CQMs for which they are seeking certification, based upon the imported and de-duplicated data set.
- The Health IT Module submits an aggregate report for each of the CQMs to be certified.
Test Lab Verification
Calculate
- The tester verifies the Health IT Module can use the imported CQM data to calculate the aggregate data and display the report in accordance, at a minimum, with the standard at § 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, using visual inspection.
- Using Cypress, the tester:
- uploads the aggregate report(s) submitted by the Health IT Module; and
- displays and evaluates the accuracy of the submitted CQM results.
Packaging of Results
- The tester generates a test artifact containing the following into a single archived file and any additional notes that the tester deems important:
- all of the test data used to test (c)(2); and
- all of the data generated by the Health IT Module.
Cypress Certification API (Alternative)
- A tester may use the Cypress Certification API to upload the data file submitted by the Health IT Module. The tester can verify the results in Cypress as normal, however, the tester should manually verify that the Health IT Module can use the imported CQM data to calculate the aggregate data and display the report appropriately as well as the accuracy of the submitted CQM results for at least one CQM to ensure this functionality is present. The tester should still generate a test artifact containing the test data and all data generated by the Health IT Module into a single archive file, as usual. 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 |
|---|---|
|
Calculate
|
Calculate
Packaging of Results
Cypress Certification API (Alternative)
|
Archived Version:
Updated on 03-11-2024
Regulation Text
Regulation Text
§ 170.315 (c)(2) Clinical quality measures—import and calculate—
- Import. Enable a user to import a data file in accordance with the standard specified in § 170.205(h)(2) for one or multiple patients and use such data to perform the capability specified in paragraph (c)(2)(ii) of this section. A user must be able to execute this capability at any time the user chooses and without subsequent developer assistance to operate.
- Calculate each and every clinical quality measure for which it is presented for certification.
Standard(s) Referenced
Paragraph (c)(2)(i)
Standards Version Advancement Process (SVAP) Version(s) Approved
For more information, please visit the Standards Version Advancement Process (SVAP) Version(s) page.
Additional Resources
§ 170.205(k)(1) Quality Reporting Document Architecture Category III, Implementation Guide for CDA Release 2
Certification Dependencies
Conditions and Maintenance of Certification
Real World Testing: Products certified to this criterion must complete requirements outlined for the Real World Testing Conditions and Maintenance of Certification.
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)(2). 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 (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.
- If choosing Approach 1:
- Authentication, access control, and authorization (§ 170.315(d)(1))
- Auditable events and tamper-resistance (§ 170.315(d)(2))
- Audit reports (§ 170.315(d)(3))
- Automatic access time-out (§ 170.315(d)(5))
- Encrypt authentication credentials (§ 170.315(d)(12))
- Multi-factor authentication (MFA) (§ 170.315(d)(13))
- If choosing Approach 2:
- For each applicable privacy and security certification criterion not certified for Approach 1, the health IT developer may certify using system documentation which is sufficiently detailed to enable integration such that the Health IT Module has implemented service interfaces the Health IT Module to access external services necessary to meet the requirements of the privacy and security certification criterion. Please see the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Final Rule at 85 FR 25710 for additional clarification.
Revision History
| Version # | Description of Change | Version Date |
|---|---|---|
| 1.0 |
Final Test Procedure. |
03-11-2024
|
- Regulation Text
-
Regulation Text
§ 170.315 (c)(2) Clinical quality measures—import and calculate—
- Import. Enable a user to import a data file in accordance with the standard specified in § 170.205(h)(2) for one or multiple patients and use such data to perform the capability specified in paragraph (c)(2)(ii) of this section. A user must be able to execute this capability at any time the user chooses and without subsequent developer assistance to operate.
- Calculate each and every clinical quality measure for which it is presented for certification.
- Standard(s) Referenced
-
Paragraph (c)(2)(i)
Standards Version Advancement Process (SVAP) Version(s) Approved
For more information, please visit the Standards Version Advancement Process (SVAP) Version(s) page.
Additional Resources
§ 170.205(k)(1) Quality Reporting Document Architecture Category III, Implementation Guide for CDA Release 2
- Certification Dependencies
-
Conditions and Maintenance of Certification
Real World Testing: Products certified to this criterion must complete requirements outlined for the Real World Testing Conditions and Maintenance of Certification.
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)(2). 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 (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.
- If choosing Approach 1:
- Authentication, access control, and authorization (§ 170.315(d)(1))
- Auditable events and tamper-resistance (§ 170.315(d)(2))
- Audit reports (§ 170.315(d)(3))
- Automatic access time-out (§ 170.315(d)(5))
- Encrypt authentication credentials (§ 170.315(d)(12))
- Multi-factor authentication (MFA) (§ 170.315(d)(13))
- If choosing Approach 2:
- For each applicable privacy and security certification criterion not certified for Approach 1, the health IT developer may certify using system documentation which is sufficiently detailed to enable integration such that the Health IT Module has implemented service interfaces the Health IT Module to access external services necessary to meet the requirements of the privacy and security certification criterion. Please see the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Final Rule at 85 FR 25710 for additional clarification.
- Revision History
-
Version # Description of Change Version Date 1.0 Initial Publication
03-11-2024 - Testing
-
Testing Tool
Criterion Subparagraph Test Data (c)(2)(i) (c)(2)(ii)
Certification Companion Guide: Clinical quality measures (CQMs) — import and calculate
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 | Yes | No | Yes | No |
Certification Requirements
Technical Explanations and Clarifications
Applies to entire criterion
Clarifications:
- The specific version, number, and type of clinical quality measures (CQMs) presented for certification are determined at the developer’s discretion. ONC recommends developers consult any CMS or other programs’ requirements around the specific version, number, or type of CQMs required for providers in determining the CQMs presented for certification.
- Health IT developers are permitted to test and certify to the newest versions of the HL7® CDA® R2 Implementation Guide: Quality Reporting Document Architecture - Category I (QRDA I) and Category III (QRDA III) IGs, regardless of the versions approved by the National Coordinator via the Standards Version Advancement Process (SVAP).
- 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 a specific version of the Quality Reporting Document Architecture (QRDA) Category I standard. Each year’s QRDA Category I standard is 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 these 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 version of QRDA Category I standard referenced in the CMS QRDA IG. Note that for this criterion at § 170.315(c)(2), the testing tools are only capable of validating the correct calculation of CQMs for reports submitted in the corresponding QRDA Category III format. ONC will evaluate the need for future rulemaking to align the version of QRDA Category I standard required for this certification criterion with the version of QRDA Category I standard in the CMS annual measure update.
- After technology is certified to specific CQMs for this § 170.315(c)(2) criterion, technology is not required to recertify to the annual measure specification updates CMS issues to maintain certification unless that product is relabeled. Said another way, other programs, such as the Promoting Interoperability Programs, may require developers upgrade their technology to the newest CQM specifications, but the technology is not required to be retested or recertified, unless explicitly specified in other program requirements. It is expected that all systems will test all measure and standards updates as a best practice. The testing tools are available for each CMS annual measure update and when there are late standards errata or CMS requirement changes to facilitate additional testing.
- Systems that present for certification to § 170.315(c)(1), (c)(2), (c)(3) must explicitly demonstrate this criterion at § 170.315(c)(2). Those systems previously considered “self-contained” according to the 2014 Edition policy will no longer be deemed to meet certification for § 170.315(c)(2). [see also 80 FR 62650]
- 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:
|
Paragraph (c)(2)(i) Import
Technical outcome – A user can import a data file formatted in accordance with HL7® QRDA Category I Release 3 or the corresponding version of the QRDA standard for the CMS annual measure update being certified 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. ONC is 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 leaves the determination at the discretion of the developer. [see also 80 FR 62650]
- Testing and Certification. Successful testing and certification do not require the evaluation of the time required to process a CQM data file. To illustrate, a delay between when a user initiates an export and receives the resulting data file would not, by itself, preclude successful testing of the technology or the issuance of a certification on the basis of those successful test results.
- Surveillance. While the CQM export capability does not require that data be received instantaneously, a non-conformity would exist if surveillance revealed that processing or other delays were likely to substantially interfere with the ability of a provider or health system to view and verify their CQM results for quality improvement on a near real-time basis. [see also 80 FR 62650] Similarly, a non-conformity would exist if delays were causing or contributing to users being presented with data files that no longer contained current, accurate, or valid data. To avoid these implementation issues and ensure that capabilities support all required outcomes, health IT developers should seek to minimize processing times and other delays to the greatest extent possible. ONC notes also that any delays must be disclosed in accordance with § 170.523(k)(1).
- 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. [see also 80 FR 62650]
- 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. [see also 80 FR 62651]
- ONC 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 de-duplication. [see also 80 FR 62651] De-duplication testing will require systems to identify two files with the same or similar patient identifiers but different QRDA document identifiers and adjudicate information that is identical and combine information that is not.
- 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. [see also 80 FR 62651]
|
Technical outcome – A user can import a data file formatted in accordance with HL7® QRDA Category I Release 3 or the corresponding version of the QRDA standard for the CMS annual measure update being certified for one or multiple patients in order to perform calculations on the CQMs presented for certification. Clarifications:
|
Paragraph (c)(2)(ii) Calculate
Technical outcome – The health IT must be able to calculate each CQM presented for certification.
Clarifications:
- The testing tools are only capable of validating the correct calculation of CQMs for reports submitted in the QRDA Category III format.
|
Technical outcome – The health IT must be able to calculate each CQM presented for certification. Clarifications:
|