Department of health and human services
Yüklə 1,55 Mb.
|
- Bu səhifədəki naviqasiya:
- 2015 Edition Health IT Certification Criterion
- 2015 Edition Health IT Certification Criteria
|
In general, 42 CFR part 2-covered data is not currently provided electronically to healthcare providers through electronic exchange. Instead, the status quo remains to share 42 CFR part 2-covered data via paper and fax. In line with the HITPC recommendations, we propose a certification criterion that would require a Health IT Module to be able to receive 42 CFR part 2-covered data in accordance with the DS4P IG. DS4P at the document level (Level 1) of the recommendations allows recipient health IT to receive, recognize, and view documents with privacy metadata tagging indicating certain restrictions from 42 CFR part 2 providers with the document sequestered from other health IT data. A recipient provider could use document level tagging to sequester the document from other documents received and help prevent unauthorized re-disclosure, while allowing the sensitive data to flow more freely to authorized recipients. Thus, consistent with the HITPC recommendations, we propose that a Health IT Module be able to receive documents tagged with privacy metadata tagging (Level 1).
We propose to adopt a new 2015 Edition certification criterion that would reflect a Health IT Module’s ability to enable a user to record, change, access, create and receive care plan information in accordance with the “Care Plan document template” in the C-CDA Release 2.0 standard. The S&I Framework Longitudinal Coordination of Care (LCC) Longitudinal Care Plan Sub-Work Group defined a “care plan” as “the synthesis and reconciliation of the multiple plans of care produced by each provider to address specific health concerns. It serves as the blueprint shared by all participants to guide the individual’s care. As such, it provides the structure required to coordinate care across multiple sites, providers, and episodes of care.”126 The care plan helps multiple providers and caregivers align and coordinate care, which is especially valuable for patients living with chronic conditions and/or disabilities. It also provides a structure to promote the consideration of a patient’s future goals and expectations in addition to managing their currently active health issues. The C-CDA Release 2.0 contains a Care Plan document template that reflects these principles and provides a structured format for documenting information such as the goals, health concerns, health status evaluations and outcomes, and interventions. Note that the Care Plan document template is distinct from the “Plan of Care Section” in previous versions of the C-CDA. The Care Plan document template represents the synthesis of multiple plans of care (for treatment) for a patient, whereas the Plan of Care Section represented one provider’s plan of care (for treatment). To make this distinction clear, the C-CDA Release 2.0 has renamed the previous “Plan of Care Section” as the “Plan of Treatment Section (V2).” Given the value for improved coordination of care, we propose a new 2015 Edition certification criterion for “care plan” that would require a Health IT Module to enable a user to record, change, access, create, and receive care plan information in accordance with the “Care Plan document template” in the HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes.127 The IG provides guidance for implementing CDA documents, including the Care Plan document template. The “transitions of care” certification criterion proposed elsewhere in this section of the preamble would require a Health IT Module enable a user to send and receive transitions of care/referral summaries according to the C-CDA Release 2.0, which would include the Care Plan document template. Therefore, this criterion would focus only on a Health IT Module’s ability to enable a user to record, change, access, create, and receive care plan information. We welcome comment on our proposal, including whether we should require certain “Sections” that are currently deemed optional as part of the Care Plan document template for certification to this criterion. For example, we invite comment on whether we should require the optional “Health Status Evaluations and Outcomes Section” and “Interventions Section (V2)” as part of certification to this criterion, and if so, for what value/use case.
We propose to adopt a 2015 Edition certification criterion for “clinical quality measures (CQM) – record and export” that is revised in comparison to the 2014 Edition “CQM – capture and export” certification criterion (§ 170.314(c)(1)). In order to align with our use of the term “record” used in other 2014 and 2015 Edition certification criteria, we propose to call this certification criterion “CQM – record and export.” We explain the term “record” in the 2014 Edition final rule at 77 FR 54168.128 We propose to require that a system user be able to export CQM data at any time the user chooses and without subsequent developer assistance to operate. We also propose to require that this certification criterion be part of the set of criteria necessary to satisfy the “2015 Edition Base EHR” definition (see also section III.B.1 of this preamble for a discussion of the proposed 2015 Edition Base EHR definition). Last, we solicit comment on the version of standards we should adopt for this certification criterion. Standards for Clinical Quality Measures In the 2014 Edition “CQM – capture and export” certification criterion, we require that technology must be able to export a data file formatted in accordance with the HL7 Implementation Guide for CDA Release 2: Quality Reporting Document Architecture (QRDA), DSTU Release 2 (July 2012) standard. We understand that the industry is working to harmonize both clinical quality measurement and CDS standards through initiatives such as the Clinical Quality Framework (CQF) S&I initiative. CDS guides a clinician to follow a standard plan of care, while CQMs measure adherence to a standard plan of care. Thus, these two areas are closely related and would benefit from standard ways to reference patient data within health IT as well as common logic to define a sub-population. The CQF S&I initiative is working to define a shared format, terminology, and logic between CQMs and CDS for improved efficiency, cost, and quality of care. In order to harmonize CQM and CDS standards, the industry is using pieces of existing CQM standards (e.g., Health Quality Measures Format (HQMF), QRDA Categories I and III, and the Quality Data Model (QDM)) and CDS standards (e.g., Clinical Decision Support Knowledge Artifact Specification (also known as HeD Schema) and the Virtual Medical Record). HL7 issued an errata (September 2014)129 that reflects updates based on an incremental version of the harmonized CQM and CDS standards (i.e., QDM-based HQMF Release 2.1130). This errata is meant to be used in conjunction with the July 2012 QRDA IG we adopted in the 2014 Edition. Our understanding is that the fully harmonized CQM and CDS standards will be based on the Quality Improvement and Clinical Knowledge (QUICK) data model131, and that the industry expects to ballot a QUICK FHIR-based DSTU serving the same function as the HQMF standard at the May 2015 HL7 meeting. Subsequent standards for electronically processing and reporting CQMs and CDS would then be expected to be built on the QUICK data model, including a QRDA-like standard based on the anticipated QUICK FHIR-based DSTU. Given the timing of this proposed rule and the expected deliverables for harmonized CQM and CDS standards as described above, we solicit comment on the version of QRDA or the QRDA-like standards we should adopt for this certification criterion. Specifically, we solicit comment on the following three options:
We anticipate that the QUICK data model will not be available to review during the public comment period of this NPRM, and welcome stakeholder input on the usefulness of adopting the current (July 2012) QRDA standard alone or in conjunction with the September 2014 errata given that we anticipate there will be harmonized CQM and CDS standards available in mid-2015. We also seek to understand the tradeoffs stakeholders perceive in adopting each standard provided that the EHR Incentive Programs Stage 3 proposed rule is proposing that technology certified to the 2015 Edition would not be required until January 1, 2018, but that technology certified to the 2015 Edition “CQM – record and export” certification criterion would be needed for EPs, eligible hospitals, and CAHs participating in the EHR Incentive Programs Stage 3 objectives and measures in 2017. Thus, we welcome input on recommended QRDA standards for the “CQM – record and export” certification criterion factoring in where the industry may be with adoption of CQM and CDS standards over the next few years. User Ability to Export CQM Data We have received stakeholder feedback that some systems certified to the 2014 Edition “CQM – capture and export” certification criterion do not provide users with the ability to export data “on demand” nor to export batches of multiple patients simultaneously. Rather, some users of certified health IT must request this functionality from the health IT developer. Our intent is that users should be able to export CQM data formatted to the QRDA standard at any time the user chooses for one or multiple patients and without additional assistance. Thus, as proposed, when a Health IT Module is presented for certification to this criterion, we would expect that testing of the Health IT Module would include demonstration of a user’s ability to export CQM data without subsequent health IT developer assistance beyond normal orientation/training.
We propose to adopt a 2015 Edition certification criterion for “clinical quality measures (CQM) – import and calculate” that is revised in comparison to the 2014 Edition “CQM – import and calculate” certification criterion (§ 170.314(c)(2)). We propose to require that a system user be able to import CQM data at any time the user chooses and without subsequent health IT developer assistance to operate. We also no longer include an exemption that would allow a Health IT Module presented for certification to all three CQM certification criteria (§§ 170.315(c)(1), (c)(2), and (c)(3)) to not have to demonstrate the data import capability. Last, we solicit comment on our intended direction for testing and certifying health IT and the version of standards we should adopt for this certification criterion. User Ability to Import CQM Data We have received stakeholder feedback that some systems certified to the 2014 Edition “CQM – import and calculate” certification criterion do not provide users the ability to import data “on demand,” and rather users must request this functionality from the system developer or vendor. Our intent is that users should be able to import CQM data formatted to the QRDA standard for one or multiple patients at any time the user chooses and without additional assistance. Thus, when a Health IT Module is presented for certification to this criterion, we would expect that testing of the Health IT Module would include demonstration of a user’s ability to import CQM data without subsequent health IT developer assistance beyond normal orientation/training. Import of CQM Data For the 2014 Edition, we do not require systems that certify to § 170.314(c)(1) (CQM – capture and export), § 170.314(c)(2) (CQM – import and calculate), and § 170.314(c)(3) (CQM - electronic submission) to have to demonstrate that they can import data files in accordance with the QRDA standard. In 2012, we adopted this policy because we did not believe that systems that could perform capture, export, and electronic submission functions would need to import CQM data as they were in essence “self-contained” (77 FR 54231). However, we have received stakeholder input recommending that all systems should be able to import CQM data and that there could be instances were a provider using one technology to record CQM data could not subsequently import such data into a different technology. We agree with this feedback. Therefore, this exemption will no longer carry forward as part of the proposed 2015 Edition version of this certification criterion. This means that a Health IT Module presented for certification to this certification criterion (§ 170.315(c)(2)) would need to be able to demonstrate the ability to import data in order to be certified to this certification criterion even if they also certify to provide “record and export” and “electronic submission/report” functions. Testing of Import and Calculate Functionalities The testing procedures for the 2014 Edition “CQM – import and calculate” certification criterion only test that technology can import a small number of test records and use those for calculation of CQM results. We have received feedback that technology should be able to import a larger number of test records and that we should test this ability to reflect real-world needs for technology. With the import of a large number of records, technology also needs to be able to de-duplicate records for accurate calculation of CQM results. Therefore for testing and certification to the proposed 2015 Edition “CQM – import and calculate” certification criterion, we intend for testing to include that technology can import a larger number of test records compared to testing for the 2014 Edition and automatically de-duplicate them for accurate CQM calculation. We welcome comment on our proposed intentions to test a larger number of test records compared to the 2014 Edition test procedure and that a Health IT Module could eliminate duplicate records. We also request comment on the number of test records we should consider testing a Health IT Module for performing import and calculate functions. Standards for Clinical Quality Measures We describe above in the preamble for the proposed 2015 Edition “CQM – record and export” certification criterion our understanding of the industry’s timeline and expected deliverables for harmonized CQM and CDS standards. Given the discussion above, we also solicit comment on the QRDA standards we should consider adopting for this 2015 Edition “CQM – import and calculate” certification criterion.
In the 2014 Edition, we adopted a “CQM – electronic submission” certification criterion that requires technology to enable a user to electronically create a data file for transmission of CQM data in accordance with QRDA Category I and III standards and “that can be electronically accepted by CMS” (§ 170.314(c)(3)). We have received stakeholder feedback recommending we better align our certification policy and standards for electronically-specified CQM (eCQM) reporting with other CMS programs that include eCQMs, such as the Physician Quality Reporting System (PQRS) and Hospital Inpatient Quality Reporting (IQR) programs. The PQRS and Hospital IQR programs update their measure specifications on an annual basis through rulemaking in the Physician Fee Schedule (PFS) and Inpatient Prospective Payment Systems (IPPS) rules respectively. To better align with the reporting requirements of other CMS programs, we intend to propose certification policy for reporting of CQMs in or with annual PQRS and/or Hospital IQR program rulemaking. We anticipate we will propose standards for reporting of CQMs that reflect CMS’ requirements for the “form and manner” of CQM reporting (e.g., CMS program-specific QRDA standards), allowing for annual updates of these requirements as necessary. Under this approach, the “CQM – report” certification policy and associated standards for the 2015 Edition that support achieving EHR Incentive Program requirements would be proposed jointly with the calendar year (CY) 2016 PFS and/or IPPS proposed rules. We anticipate these proposed and final rules will be published in CY 2015. We clarify that we anticipate removing “electronic” from the name of this certification criterion. As described in the preamble, we expect that all functions proposed in the 2015 Edition certification criteria are performed or demonstrated electronically. Thus, it is not necessary to specifically include this requirement in the title of this certification criterion. We also anticipate naming this certification criterion “report” instead of “submission” to better align with the language we use in other certification criteria that also require demonstration of the same functionality to submit data.
Yüklə 1,55 Mb. Dostları ilə paylaş:
|