§170.315(c)(1) Clinical quality measures (CQMs) — record and export
§170.315(c)(1)
Updated on 03-11-2024
Regulation Text
Regulation Text
§ 170.315(c)(1) Clinical quality measures—record and export—
- Record. For each and every CQM for which the technology is presented for certification, the 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.”
- Export. A user must be able to export a data file at any time the user chooses and without subsequent developer assistance to operate:
- Formatted in accordance with the standard specified in § 170.205(h)(2);
- Ranging from one to multiple patients; and
- That includes all of the data captured for each and every CQM to which technology was certified under paragraph (c)(1)(i) of this section.
Standard(s) Referenced
Paragraph (c)(1)(ii)
Standards Version Advancement Process (SVAP) Version(s) Approved
For more information, please visit the Standards Version Advancement Process (SVAP) Version(s) page.
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)(1). 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.
- 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
|
- Regulation Text
-
Regulation Text
§ 170.315(c)(1) Clinical quality measures—record and export—
- Record. For each and every CQM for which the technology is presented for certification, the 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.”
- Export. A user must be able to export a data file at any time the user chooses and without subsequent developer assistance to operate:
- Formatted in accordance with the standard specified in § 170.205(h)(2);
- Ranging from one to multiple patients; and
- That includes all of the data captured for each and every CQM to which technology was certified under paragraph (c)(1)(i) of this section.
- Standard(s) Referenced
-
Paragraph (c)(1)(ii)
Standards Version Advancement Process (SVAP) Version(s) Approved
For more information, please visit the Standards Version Advancement Process (SVAP) Version(s) page.
- 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)(1). 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.
- 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)(1) - 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 tests step order does not necessarily prescribe the order in which the tests should take place.
Testing components
Paragraph (c)(1)(i) Record
System Under Test
Setup
- 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):
- Name of the health IT developer;
- Name of the product;
- List of CQMs to be certified; and
- List of certification criteria to be tested (such as (c)(1) only or (c)(1), (c)(2), (c)(3) and (c)(4))
Record Entry
- Using the instructions provided by Cypress, a user demonstrates they can record the specified data needed for each of the certified CQMs, using codified entries for data required for all CQM data criteria, including but not limited to support for codified:
- patient reason;
- system reason; and
- medical reason.
Note: Record entry is not limited to use of a user interface. If a user interface entry is not available, the record entry can be demonstrated with the creation of structured documents (e.g. QRDA, C-CDA, or custom format) and their import into the SUT. These structured documents must be created by the health IT developer at the time of certification and must contain the specified data.
If a health IT developer is only testing to and seeking certification to § 170.315(c)(1), and not other CQM criteria (i.e. § 170.315(c)(2)-(c)(4)), record batch entry is not required to be tested.
Record Batch Entry
- Using the “Cypress Gold Standard Test Data” instructions provided by Cypress, a user demonstrates the recording of data needed for each of the certified CQMs, using codified entries for data required for all CQM data elements.
Test Lab Verification
Setup
- The tester creates the “Cypress Gold Standard Test Data” based upon the Health IT Module provided information using Cypress to create a new (c)(1) test instance.
Record Entry
- Through visual inspection, the tester verifies the test data that is denoted for record entry can be recorded in a patient record within the Health IT Module, using the health IT developer identified data entry functions.
Note: If a health IT developer is only testing to and seeking certification to § 170.315(c)(1), and not other CQM criteria (i.e. § 170.315(c)(2)-(c)(4)), record batch entry is not required to be tested.
Record Batch Entry
- The tester verifies through visual inspection the test data recorded for each of the certified CQMs can be batch recorded in a patient record within the Health IT Module, using the health IT developer identified entry functions.
- The tester verifies through visual inspection that all of the test data that will be used to calculate each CQM has been recorded in a patient record within the Health IT Module for each of the CQMs to be certified.
- The tester verifies through visual inspection the data required for CQM data criteria within the Health IT Module are codified entries.
| System Under Test | Test Lab Verification |
|---|---|
|
Setup
Record Entry
Note: Record entry is not limited to use of a user interface. If a user interface entry is not available, the record entry can be demonstrated with the creation of structured documents (e.g. QRDA, C-CDA, or custom format) and their import into the SUT. These structured documents must be created by the health IT developer at the time of certification and must contain the specified data. Record Batch Entry
|
Setup
Record Entry
Note: If a health IT developer is only testing to and seeking certification to § 170.315(c)(1), and not other CQM criteria (i.e. § 170.315(c)(2)-(c)(4)), record batch entry is not required to be tested. Record Batch Entry
|
Paragraph (c)(1)(ii) Export
System Under Test
- The health IT developer submits documentation that demonstrates how a user can export a file at any time the user chooses and without subsequent developer assistance.
- Based upon the patient records updated in paragraph (c)(1)(i), a user exports, at any time and without any developer assistance, a data file 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 a single patient and for multiple patients for each eCQM presented for certification.
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
- Via documentation submitted by the health IT developer, the tester verifies that a QRDA I data file(s) can be exported at any time (on-demand) and without any developer assistance for one or more CQMs associated with one or more patients for the eCQMs chosen by the provider and for the chosen reporting period.
- Using Cypress, the tester:
- uploads the data file submitted by the Health IT Module; and
- reviews the QRDA validation report for errors.
- The tester verifies that the data file is formatted according to the standard specified at § 170.205(h)(2) for a single patient and multiple patients correctly and without omission.
- 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 compliance in this area. The tester instructs the health IT developer to export the selected patient and confirms that this patient was exported.
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 all relevant steps of the TLV for at least one CQM to ensure this functionality is present, including reviewing the QRDA validation report for errors and that the data file is formatted according to the standard specified. 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 this 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 |
|---|---|
Approved SVAP Version(s)
|
Cypress Certification API (Alternative)
|
Updated on 03-11-2024
Regulation Text
Regulation Text
§ 170.315(c)(1) Clinical quality measures—record and export—
- Record. For each and every CQM for which the technology is presented for certification, the 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.”
- Export. A user must be able to export a data file at any time the user chooses and without subsequent developer assistance to operate:
- Formatted in accordance with the standard specified in § 170.205(h)(2);
- Ranging from one to multiple patients; and
- That includes all of the data captured for each and every CQM to which technology was certified under paragraph (c)(1)(i) of this section.
Standard(s) Referenced
Paragraph (c)(1)(ii)
Standards Version Advancement Process (SVAP) Version(s) Approved
For more information, please visit the Standards Version Advancement Process (SVAP) Version(s) page.
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)(1). 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.
- 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
|
- Regulation Text
-
Regulation Text
§ 170.315(c)(1) Clinical quality measures—record and export—
- Record. For each and every CQM for which the technology is presented for certification, the 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.”
- Export. A user must be able to export a data file at any time the user chooses and without subsequent developer assistance to operate:
- Formatted in accordance with the standard specified in § 170.205(h)(2);
- Ranging from one to multiple patients; and
- That includes all of the data captured for each and every CQM to which technology was certified under paragraph (c)(1)(i) of this section.
- Standard(s) Referenced
-
Paragraph (c)(1)(ii)
Standards Version Advancement Process (SVAP) Version(s) Approved
For more information, please visit the Standards Version Advancement Process (SVAP) Version(s) page.
- 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)(1). 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.
- 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)(1)
Certification Companion Guide: Clinical quality measures (CQMs) — record and export
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 |
|---|---|---|---|---|
| Included | Yes | No | Yes | No |
Certification Requirements
Technical Explanations and Clarifications
Applies to entire criterion
Clarifications:
- Health IT needs to be able to record all data necessary to successfully calculate selected clinical quality measures (CQMs).
- 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).
- The specific version, number, and type of 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.
- 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 tools 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. 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)(1) 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 to upgrade their technology to the newest CQM specifications, but the technology is not required to be retested or recertified for eCQMs already certified 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 for products using eCQMs.
- 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)(1)(i) Record
Technical outcome – The health IT must be able to record all data necessary to calculate CQMs presented for certification.
Clarifications:
- Providers may employ many methods to capture the information required by CQMs. Information transferred from other systems can meet the requirement for “capture.” [see also 77 FR 54230] ONC recommends developers include functionality that allows users to view any information transferred from other systems.
- ONC-Authorized Testing Labs (ONC-ATLs) are permitted to provide flexibility regarding data elements for manual entry where the measure allows multiple ways to express the same data criteria or alternate data criteria where appropriate.
- 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.
|
Technical outcome – The health IT must be able to record all data necessary to calculate CQMs presented for certification. Clarifications:
|
Paragraph (c)(1)(ii) Export
Technical outcome – A user can export 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 that includes all of the data captured in (c)(1)(i) of this criterion.
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. While a user of this health IT must be able to create these reports at any time selected without additional assistance from health IT developers, health IT developers can claim technology downtime for software upgrades (to accommodate upgrades for the latest QRDA specification, for example). Health IT developers experiencing technology downtime for software upgrades should communicate their reason for technology downtime and when their technology will again be operational. [see also 77 FR 54230 and 80 FR 62650]
- Testing and Certification. Successful testing and certification does 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. [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).
- Providers and health systems should determine the protocols around when and how providers export CQM data. As noted above, 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. [see also 80 FR 62650]
|
Technical outcome – A user can export 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 that includes all of the data captured in (c)(1)(i) of this criterion. Clarifications:
|