# Health Information Technology: Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, 2014 Edition; Revisions to the Permanent Certification Program for Health Information Technology > Briefs, arguments, decisions, and more. URL: https://www.frixlaw.com/law-library/documents/fr%3A2012-20982 ## Record - **Collection:** Federal Register - **Document type:** Rule - **Published:** September 4, 2012 - **Citation:** 77 FR 54163 ## Text DEPARTMENT OF HEALTH AND HUMAN SERVICES Office of the Secretary 45 CFR Part 170 RIN 0991-AB82 Health Information Technology: Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, 2014 Edition; Revisions to the Permanent Certification Program for Health Information Technology AGENCY: Office of the National Coordinator for Health Information Technology (ONC), Department of Health and Human Services. ACTION: Final rule. SUMMARY: With this final rule, the Secretary of Health and Human Services adopts certification criteria that establish the technical capabilities and specify the related standards and implementation specifications that Certified Electronic Health Record (EHR) Technology will need to include to, at a minimum, support the achievement of meaningful use by eligible professionals, eligible hospitals, and critical access hospitals under the Medicare and Medicaid EHR Incentive Programs beginning with the EHR reporting periods in fiscal year and calendar year 2014. This final rule also makes changes to the permanent certification program for health information technology, including changing the program's name to the ONC HIT Certification Program. DATES: These regulations are effective October 4, 2012. The incorporation by reference of certain publications listed in the rule is approved by the Director of the Federal Register as of October 4, 2012. FOR FURTHER INFORMATION CONTACT: Steven Posnack, Director, Federal Policy Division, Office of Policy and Planning, Office of the National Coordinator for Health Information Technology, 202-690-7151. SUPPLEMENTARY INFORMATION: This final rule is issued under section 3004 of the Public Health Service Act. Commonly Used Acronyms CAH Critical Access Hospital CDA Clinical Document Architecture CDC Centers for Disease Control and Prevention CDS Clinical Decision Support CEHRT Certified EHR Technology CFR Code of Federal Regulations CHPL Certified HIT Products List CMS Centers for Medicare & Medicaid Services CQM Clinical Quality Measure CY Calendar Year EH Eligible Hospital EHR Electronic Health Record EP Eligible Professional FY Fiscal Year HHS Department of Health and Human Services HIPAA Health Insurance Portability and Accountability Act of 1996 HIT Health Information Technology HITECH Health Information Technology for Economic and Clinical Health HITPC HIT Policy Committee HITSC HIT Standards Committee HL7 Health Level Seven ICD-9-CM International Classification of Diseases, 9th Revision, Clinical Modification ICD-10 International Classification of Diseases, 10th Revision ICD-10-CM International Classification of Diseases, 10th Revision, Clinical Modification ICD-10-PCS International Classification of Diseases, 10th Revision, Procedure Coding System IHE Integrating the Healthcare Enterprise® LOINC® Logical Observation Identifiers Names and Codes MU Meaningful Use ONC Office of the National Coordinator of Health Information Technology NCPDP National Council for Prescription Drug Programs NIST National Institute of Standards and Technology PHSA Public Health Service Act SNOMED CT® Systematized Nomenclature of Medicine Clinical Terms I. Executive Summary A. Purpose of Regulatory Action B. Summary of Major Provisions 1. Overview of the 2014 Edition EHR Certification Criteria 2. Certified EHR Technology 3. ONC HIT Certification Program C. Costs and Benefits II. Background A. Statutory Basis 1. Standards, Implementation Specifications, and Certification Criteria 2. HIT Certification Programs B. Regulatory History 1. Standards, Implementation Specifications, and Certification Criteria Rules 2. Medicare and Medicaid EHR Incentive Programs Rules 3. HIT Certification Programs Rules III. Provisions of the Final Rule Affecting Standards, Implementation Specifications and Certification Criteria A. 2014 Edition EHR Certification Criteria 1. Certification Criteria Relationship to MU 2. Applicability 3. Scope of a Certification Criterion for Certification 4. Explanation and Revision of Terms Used in Certification Criteria 5. Consensus-Based Standards 6. Adopting Versions of Standards 7. Display of Vocabulary Standards 8. Common Data Elements in Certification Criteria 9. New Certification Criteria a. Ambulatory and Inpatient Setting b. Ambulatory Setting c. Inpatient Setting 10. Revised Certification Criteria a. Ambulatory and Inpatient Setting b. Ambulatory Setting c. Inpatient Setting 11. Unchanged Certification Criteria a. Refinements to Unchanged Certification Criteria b. Unchanged Certification Criteria Without Refinements 12. Gap Certification 13. “Disability” Status B. Redefining Certified EHR Technology and Related Terms 1. Certified EHR Technology (CEHRT) Definition 2. Base EHR Definition 3. Complete EHR Definition 4. Certifications Issued for Complete EHRs and EHR Modules 5. Adaptations of Certified Complete EHRs or Certified EHR Modules IV. Provisions of the Final Rule Affecting the Permanent Certification Program for HIT (“ONC HIT Certification Program”) A. Program Name Change B. “Minimum Standards” Code Sets C. Revisions to EHR Module Certification Requirements 1. Privacy and Security Certification 2. Certification to Certain New Certification Criteria D. ONC-ACB Reporting Requirements E. Continuation and Representation of Certified Status 1. 2011 or 2014 Edition EHR Certification Criteria Compliant 2. Updating a Certification 3. Representation of Meeting the Base EHR Definition F. EHR Technology Price Transparency G. Certification and Certification Criteria for Other Health Care Settings V. Collection of Information Requirements VI. Regulatory Impact Statement A. Statement of Need B. Overall Impact 1. Comment and Response 2. Executive Orders 12866 and 13563—Regulatory Planning and Review Analysis a. Costs i. Development and Preparation Costs for 2014 Edition EHR Certification Criteria ii. Overall Development and Preparation Estimated Costs Over a 3-Year Period iii. Costs for Reporting Test Results Hyperlinks b. Benefits 3. Regulatory Flexibility Act Analysis 4. Executive Order 13132—Federalism 5. Unfunded Mandates Reform Act of 1995 Regulation Text I. Executive Summary A. Purpose of Regulatory Action The HIT Standards Committee (HITSC) issued recommendations for standards, implementation specifications, and certification criteria to the National Coordinator for Health Information Technology (the National Coordinator) on September 28, 2011 and October 21, 2011. In fulfilling his duties under sections 3001(c)(1)(A) and (B) of the Public Health Service Act (PHSA), the National Coordinator reviewed the recommendations made by the HITSC, endorsed certain standards, implementation specifications, and certification criteria, and reported his determinations to the Secretary for consideration. On March 7, 2012, the Secretary published a proposed rule (77 FR 13832) with her determinations regarding the standards, implementation specifications, and certification criteria endorsed by the National Coordinator, as required by section 3004(a)(3) of the PHSA. The proposed rule solicited public comment on the standards, implementation specifications, and certification criteria the Secretary proposed for adoption. This final rule addresses comments received on the proposed rule and specifies the adoption by the Secretary, under sections 3004(a)(3) and 3004(b)(3) of the PHSA, of the standards, implementation specifications, and certification criteria that will establish the technical capabilities that electronic health record (EHR) technology must include to be certified. EHR technology certified to these standards, implementation specifications, and certification criteria makes it possible for eligible professionals (EPs), eligible hospitals (EHs), and critical access hospitals (CAHs) to adopt Certified EHR Technology (CEHRT) and subsequently attempt to demonstrate its meaningful use (MU) under the Medicare and Medicaid EHR Incentive Programs (the “EHR Incentive Programs”). Consistent with Executive Order 13563, we have undertaken a retrospective review of our regulations. The final rule establishes multiple means for reducing regulatory burden and increasing regulatory flexibility for stakeholders, including changes to current regulatory requirements and approaches. B. Summary of Major Provisions 1. Overview of the 2014 Edition EHR Certification Criteria We have adopted certification criteria that will support the changes to the EHR Incentive Programs, including the new and revised objectives and measures for Stages 1 and 2 of MU finalized by CMS. The adopted certification criteria also enhance care coordination, patient engagement, and the security, safety, and efficacy of EHR technology. We refer to the adopted certification criteria as the 2014 Edition EHR certification criteria and the certification criteria previously adopted through rulemaking (75 FR 2014, 75 FR 44590) as the 2011 Edition EHR certification criteria. To permit efficient certification methods and reduce regulatory burden, we have identified those certification criteria that we have adopted as part of the 2014 Edition EHR certification criteria that include unchanged capabilities that were also included in the 2011 Edition EHR certification criteria. For EHR technology previously certified to the 2011 Edition EHR certification criteria, this will permit, where applicable, the use of prior test results for certification to the 2014 Edition EHR certification criteria (see the discussion of “gap certification” in section III.A.12 of this preamble). 2. Certified EHR Technology Since the publication of the Standards and Certification Criteria final rule in July 2010, 75 FR 44590 (July 28, 2010) (the “S&CC July 2010 final rule”), HHS received significant feedback from stakeholders which suggested that we change our CEHRT policy (and definition) to one that would provide EPs, EHs, and CAHs the flexibility to have only the EHR technology they need to demonstrate MU. Consistent with stakeholder feedback and recommendations received from the HITSC, we proposed to revise the CEHRT definition to offer the requested flexibility. Based on comments received, we have finalized a CEHRT definition that provides even more flexibility for EPs, EHs, and CAHs than we originally proposed. In order to have EHR technology that meets the CEHRT definition for FY and CY 2014 and subsequent years, EPs, EHs, and CAHs must have EHR technology certified to the 2014 Edition EHR certification criteria that meets the Base EHR definition (EHR technology that includes fundamental capabilities all providers would need to have) as well as the additional EHR technology certified to the 2014 Edition EHR certification criteria necessary to meet the MU objectives and measures for the stage of MU that they seek to meet and to capture, calculate, and electronically submit clinical quality measures. In addition, this final rule permits EPs, EHs, and CAHs to adopt EHR technology that meets the FY/CY 2014 CEHRT definition and use it in their attempts to achieve MU prior to FY/CY 2014. We further discuss the new dynamic CEHRT definition, including the Base EHR definition in section III.B (“Redefining Certified EHR Technology and Related Terms”). We note that we continue to permit only two types of EHR technology, Complete EHRs and EHR Modules, to be certified to meet these definitions under the “ONC HIT Certification Program.” A Complete EHR requires EHR technology to meet, at a minimum, all the mandatory certification criteria for either the ambulatory or inpatient setting, while an EHR Module can be any EHR technology certified to one less than all the mandatory certification criteria for either the ambulatory or inpatient setting (as noted, it would be a Complete EHR if it was certified to all the mandatory certification criteria for a setting). A Complete EHR, by definition, would meet the Base EHR definition and could be used to meet the CEHRT definition, but we note that an EP may need EHR technology certified to the optional “cancer registries” certification criteria to support their attempt to achieve MU. A single EHR Module could also be developed to meet the Base EHR definition and CEHRT definition for an EP, EH, or CAH. Additionally, an EP, EH, or CAH could use multiple certified EHR Modules or a certified EHR Module(s) in conjunction with a certified Complete EHR to meet the Base EHR definition and CEHRT definition. 3. ONC HIT Certification Program This final rule revises the permanent certification program in ways that increase regulatory clarity and transparency, reduce regulatory burden, and add flexibility for the health information technology (HIT) community. One of these revisions includes changing the permanent certification program title to the “ONC HIT Certification Program,” which provides clearer attribution to the agency responsible for the program and an appropriate description of the program's scope, covering both current and potential future activities. The final rule also revises the process for permitting the use of newer versions of “minimum standard” code sets. The new approach is expected to reduce regulatory complexity and burden by providing the industry with the flexibility to utilize newer versions of adopted “minimum standard” code sets in a timelier manner. The final rule modifies the certification processes ONC-Authorized Certification Bodies (ONC-ACBs) will need to follow for certifying EHR Modules in a manner that provides clear implementation direction and compliance with the new certification criteria. It also reduces regulatory burden by eliminating the certification requirement that every EHR Module be certified to the “privacy and security” certification criteria. Instead, the privacy and security capabilities are included in the Base EHR definition that every EP, EH, and CAH must meet as part of meeting the CEHRT definition. To increase clarity for purchasers in the HIT market, we have established methods for representing certified Complete EHRs and certified EHR Modules, including when Complete EHRs and EHR Modules meet the Base EHR definition. We also require that test results used for EHR technology certification be made publicly available in an effort to increase transparency and provide EPs, EHs, and CAHs a potential starting point from which to assess any implementation issues associated with certified Complete EHRs and certified EHR Modules. Finally, as another means of increasing transparency and mitigating any potential confusion in the market, we require that ONC-ACBs ensure that EHR technology developers include in their marketing materials and communications notification to potential purchasers any additional types of costs that an EP, EH, or CAH would pay to implement their certified Complete EHR or certified EHR Module in order to attempt to meet MU objectives and measures. C. Costs and Benefits We determined that this final rule is not an economically significant rule as its overall costs will be less than $100 million in any one year. We have, however, estimated the costs and benefits of the final rule. The final rule does not account for the estimated costs that EPs, EHs, and CAHs will incur in adopting and implementing certified Complete EHRs and certified EHR Modules. Those costs are estimated in the CMS Medicare and Medicaid EHR Incentive Programs Stage 2 final rule (Stage 2 final rule) published elsewhere in this issue of the Federal Register. The estimated costs expected to be incurred by EHR technology developers to develop and prepare EHR technology (i.e., Complete EHRs and EHR Modules) to be tested and certified in accordance with the 2014 Edition EHR certification criteria are represented in monetary terms in Table 1 below. We believe that there will be market pressures to have certified Complete EHRs and certified EHR Modules ready and available prior to when EPs, EHs, and CAHs must meet the revised CEHRT definition for FY/CY 2014, particularly with the option provided by this final rule for EPs, EHs, and CAHs to adopt EHR technology that meets the FY/CY 2014 CEHRT definition and use it in their attempts to achieve MU in FY/CY 2013. Due to these market pressures, we believe that most of the estimated costs for developing EHR technology to meet the 2014 Edition EHR certification criteria will be incurred during the remainder of 2012 and throughout 2013, rather than in 2014. As a result, as represented in Table 1, the estimated costs attributable to this final rule are distributed as follows: 45% for 2012, 45% for 2013, and 10% for 2014. The dollar amounts expressed in Table 1 are expressed in 2012 dollars. There are multiple potential benefits that stem from the 2014 Edition EHR certification criteria. Foremost, the 2014 Edition EHR certification criteria promote enhanced interoperability, functionality, utility, and security of EHR technology through the capabilities they include and the standards they require EHR technology to meet for certification. EHR technology certified to the 2014 Edition EHR certification criteria also will be capable of supporting EPs, EHs, and CAHs' attempts to demonstrate MU under the EHR Incentive Programs. The revised CEHRT definition, the availability of gap certification, and the revisions to the ONC HIT Certification Program, will, as noted, increase regulatory clarity, improve transparency, and add flexibility, while also reducing the regulatory burden on the HIT industry. Last, the provisions of this final rule are supportive of other initiatives, such as the Partnership for Patients, Medicare Shared Savings Program, and other quality measure programs administered by CMS. Table 1—Estimated Costs of the Final Rule: Distributed Total Development and Preparation Costs for Complete EHR and EHR Module Developers (3-year period)—Totals Rounded Year Ratio (percent) Total low cost estimate ($M) Total high cost estimate ($M) Primary mid-point total cost estimate ($M) 2012 45 45.85 130.02 87.93 2013 45 45.85 130.02 87.93 2014 10 10.20 28.90 19.56 3-Year Totals 101.90 288.94 195.42 II. Background A. Statutory Basis The Health Information Technology for Economic and Clinical Health (HITECH) Act, Title XIII of Division A and Title IV of Division B of the American Recovery and Reinvestment Act of 2009 (the Recovery Act) (Pub. L. 111-5), was enacted on February 17, 2009. The HITECH Act amended the PHSA and created “Title XXX—Health Information Technology and Quality” (Title XXX) to improve health care quality, safety, and efficiency through the promotion of HIT and electronic health information exchange. 1. Standards, Implementation Specifications, and Certification Criteria With the passage of the HITECH Act, two new Federal advisory committees were established, the HIT Policy Committee (HITPC) and the HIT Standards Committee (HITSC) (sections 3002 and 3003 of the PHSA, respectively). Each is responsible for advising the National Coordinator on different aspects of standards, implementation specifications, and certification criteria. The HITPC is responsible for, among other duties, recommending priorities for the development, harmonization, and recognition of standards, implementation specifications, and certification criteria. The HITPC also considers and provides recommendations to ONC and CMS on meaningful use (MU) policy under the EHR Incentive Programs. The HITSC is responsible for recommending standards, implementation specifications, and certification criteria for adoption by the Secretary under section 3004 of the PHSA consistent with the ONC-coordinated Federal Health IT Strategic Plan. Section 3004 of the PHSA identifies a process for the adoption of health IT standards, implementation specifications, and certification criteria and authorizes the Secretary to adopt such standards, implementation specifications, and certification criteria. As specified in section 3004(a)(1), the Secretary is required, in consultation with representatives of other relevant Federal agencies, to jointly review standards, implementation specifications, and certification criteria endorsed by the National Coordinator under section 3001(c) and subsequently determine whether to propose the adoption of any grouping of such standards, implementation specifications, or certification criteria. The Secretary is required to publish all determinations in the Federal Register. Section 3004(b)(3) of the PHSA titled “Subsequent Standards Activity” provides that the “Secretary shall adopt additional standards, implementation specifications, and certification criteria as necessary and consistent” with the schedule published by the HITSC. We consider this provision in the broader context of the HITECH Act to grant the Secretary the authority and discretion to adopt standards, implementation specifications, and certification criteria that have been recommended by the HITSC and endorsed by the National Coordinator, as well as other appropriate and necessary HIT standards, implementation specifications, and certification criteria. Throughout this process, the Secretary intends to continue to seek the insights and recommendations of the HITSC. 2. HIT Certification Programs Section 3001(c)(5) of the PHSA provides the National Coordinator with the authority to establish a certification program or programs for the voluntary certification of HIT. Specifically, section 3001(c)(5)(A) specifies that the “National Coordinator, in consultation with the Director of the National Institute of Standards and Technology, shall keep or recognize a program or programs for the voluntary certification of health information technology as being in compliance with applicable certification criteria adopted under this subtitle” (i.e., certification criteria adopted by the Secretary under section 3004 of the PHSA). The certification program(s) must also “include, as appropriate, testing of the technology in accordance with section 13201(b) of the [HITECH] Act.” Section 13201(b) of the HITECH Act requires that with respect to the development of standards and implementation specifications, the Director of the National Institute of Standards and Technology (NIST), in coordination with the HITSC, “shall support the establishment of a conformance testing infrastructure, including the development of technical test beds.” The HITECH Act also indicates that “[t]he development of this conformance testing infrastructure may include a program to accredit independent, non-Federal laboratories to perform testing.” B. Regulatory History 1. Standards, Implementation Specifications, and Certification Criteria Rules The Secretary issued an interim final rule with request for comments titled “Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology” (75 FR 2014, Jan. 13, 2010) (the “S&CC January 2010 interim final rule”), which adopted an initial set of standards, implementation specifications, and certification criteria. After consideration of the public comments received on the S&CC January 2010 interim final rule, a final rule was issued to complete the adoption of the initial set of standards, implementation specifications, and certification criteria and realign them with the final objectives and measures established for MU Stage 1. Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology; Final Rule, 75 FR 44590 (July 28, 2010). On October 13, 2010, an interim final rule with a request for comment was issued to remove certain implementation specifications related to public health surveillance that had been previously adopted in the S&CC July 2010 final rule (75 FR 62686). The standards, implementation specifications, and certification criteria adopted by the Secretary in the S&CC July 2010 final rule established the capabilities that CEHRT must include in order to, at a minimum, support the achievement of MU Stage 1 by EPs, EHs, and CAHs under the Medicare and Medicaid EHR Incentive Programs Stage 1 final rule (the “Stage 1 final rule”) (see 75 FR 44314 for more information about MU and the Stage 1 requirements). On March 7, 2012, ONC published a proposed rule (“the Proposed Rule”) (77 FR 13832) in the Federal Register that proposed new and revised certification criteria that would support the achievement of MU beginning with the EHR reporting periods in FY/CY 2014. These certification criteria are referred to as the 2014 Edition EHR certification criteria. The rule also proposed revisions to the CEHRT definition. 2. Medicare and Medicaid EHR Incentive Programs Rules On January 13, 2010, CMS published the EHR Incentive Programs Stage 1 proposed rule (75 FR 1844). The rule proposed a definition for Stage 1 MU of CEHRT and regulations associated with the incentive payments made available under Division B, Title IV of the HITECH Act. Subsequently, CMS published a final rule (75 FR 44314) for the EHR Incentive Programs on July 28, 2010, simultaneously with the publication of the S&CC July 2010 final rule. The Stage 1 final rule established the objectives, associated measures, and other requirements that EPs, EHs, and CAHs must satisfy to demonstrate MU during Stage 1. On March 7, 2012, CMS published a proposed rule (77 FR 13698) in the Federal Register for MU Stage 2 that included proposed revisions to MU Stage 1 beginning with the EHR reporting periods in FY/CY 2013 (Stage 2 proposed rule). 3. HIT Certification Programs Rules On March 10, 2010, ONC published a proposed rule (75 FR 11328) titled “Proposed Establishment of Certification Programs for Health Information Technology” (the “Certification Programs proposed rule”). The rule proposed both a temporary and permanent certification program for the purposes of testing and certifying HIT. It also specified the processes the National Coordinator would follow to authorize organizations to perform the certification of HIT. A final rule establishing the temporary certification program was published on June 24, 2010 (75 FR 36158) (the “Temporary Certification Program final rule”) and a final rule establishing the permanent certification program was published on January 7, 2011 (76 FR 1262) (“the Permanent Certification Program final rule”). In the Proposed Rule mentioned above, ONC also proposed revisions to the permanent certification program, including changing the program's name to the ONC HIT Certification Program. III. Provisions of the Final Rule Affecting Standards, Implementation Specifications, and Certification Criteria To make a clear distinction between previously adopted certification criteria and the ones proposed for adoption in the Proposed Rule, we stated we would refer to and define the certification criteria adopted in the S&CC July 2010 final rule and included in §§ 170.302, 170.304, and 170.306 collectively as the “2011 Edition EHR certification criteria.” We proposed to revise § 170.102 to add this definition. Comments. Commenters expressed support for “editions” of certification criteria, particularly the use of “2011 Edition EHR certification criteria” for collectively referencing §§ 170.302, 170.304, and 170.306. Response. We appreciate the expression of support and have revised § 170.102 to include the definition of 2011 Edition EHR certification criteria as proposed. A. 2014 Edition EHR Certification Criteria In the Proposed Rule, we proposed new, revised, and unchanged certification criteria that would establish the technical capabilities and specify the related standards and implementation specifications that CEHRT would need to include to, at a minimum, support the achievement of MU by EPs, EHs, and CAHs under the EHR Incentive Programs beginning with the EHR reporting periods in FY/CY 2014. We referred to these new, revised, and unchanged certification criteria as the “2014 Edition EHR certification criteria” and proposed to add this term and its definition to § 170.102. Additionally, we proposed to include all of the 2014 Edition EHR certification criteria in § 170.314 to set them apart and make it easier for stakeholders to quickly determine which certification criteria would be required beginning with the EHR reporting periods that start in FY/CY 2014. Comments. Commenters expressed support for “editions” of certification criteria, particularly the use of “2014 Edition EHR certification criteria” to reference the certification criteria adopted in § 170.314. One commenter, however, did not agree with our approach to include all of the 2014 Edition EHR certification criteria in § 170.314. The commenter suggested that we should maintain the approach used for the 2011 Edition EHR certification criteria (i.e., to separate general, ambulatory, and inpatient certification criteria into three sections of the Code of Federal Regulations (CFR)). Response. We appreciate the expression of support for our “editions” approach and have revised § 170.102 to include the definition of 2014 Edition EHR certification criteria as proposed. Use of “2014 Edition EHR certification criteria” coupled with our use of “2011 Edition EHR certification criteria” should eliminate any ambiguity and provide a clear distinction between the certification criteria that are part of the 2011 Edition EHR certification criteria and those in the 2014 Edition EHR certification criteria. We believe by including all the 2014 Edition EHR certification criteria in one section of the CFR is a better approach than our previous approach of separating general, ambulatory, and inpatient certification criteria into three sections of the CFR. As noted in the Proposed Rule, the inclusion of all 2014 Edition EHR certification criteria in one regulatory section will simplify the regulatory framework for stakeholders. 1. Certification Criteria Relationship to MU Many of the certification criteria that we proposed supported the MU objectives and measures proposed by CMS in the Stage 2 proposed rule as well as the reporting of MU objectives and measures and clinical quality measures (CQMs). To the extent CMS has changed (e.g., added, revised, or removed) the MU objectives, measures, or reporting requirements in its final rule, we have made appropriate changes to the associated certification criteria so that they continue to support the MU objectives, measures, and reporting requirements. We received many comments on the 2014 Edition EHR certification criteria that were not within this rulemaking's scope. These comments focused on the MU objectives, measures, CQM measures, and reporting requirements. For responses to such comments, we direct readers to the Stage 2 final rule published elsewhere in this issue of the Federal Register . We reiterate and emphasize for commenters to remember that certification is a floor not a ceiling. It does not specify an exhaustive set of capabilities that EHR technology must include. Rather, certification assesses a subset of capabilities (generally capabilities that support MU requirements) that may be part of the overall EHR technology that an EP, EH, or CAH adopts. In this regard, certification focuses on providing assurance to EPs, EHs, and CAHs that EHR technology certified to a certification criterion includes the specified capabilities, that those capabilities perform correctly and, where applicable, that those capabilities properly utilize/support adopted standards. We discuss the new, revised, and unchanged certification criteria that we are adopting as the 2014 Edition EHR certification criteria in sections A.8 through A.10 below. We include a table at the beginning of the discussion of each certification criterion or criteria that specifies the MU objective that the 2014 Edition EHR certification criterion or criteria support. The objective cited is either a Stage 1 or Stage 2 objective that will be effective for the EHR reporting periods in FY/CY 2014. We provide this frame of reference because beginning in FY/CY 2014 EHR technology will need to be certified to the 2014 Edition EHR certification criteria to meet the CEHRT definition and the tables clearly associate the certification criterion or criteria with the MU objective it supports. The tables also specify the CFR location for each certification criterion adopted in § 170.314. 2. Applicability Section 170.300 establishes the applicability of subpart C—Certification Criteria for Health Information Technology. Section 170.300(a) establishes the applicability of the adopted certification criteria to the testing and certification of Complete EHRs and EHR Modules. Section 170.300(b) specifies that when a certification criterion refers to two or more standards as alternatives, the use of at least one of the alternative standards will be considered compliant. Section 170.300(c) specifies that Complete EHRs and EHR Modules are not required to be compliant with certification criteria that are designated as optional. We proposed to revise § 170.300 to reflect our proposed regulatory structure for the 2014 Edition EHR certification criteria. We proposed to revise paragraph (c) to add that Complete EHRs and EHR Modules are also not required to be certified to specific capabilities within a certification criterion that are designated as optional. We also proposed to add a paragraph (d) that would clarify which certification criteria or specific capabilities within a certification criterion included in § 170.314 have general applicability (i.e., apply to both ambulatory and inpatient settings) or apply only to an inpatient setting or an ambulatory setting. Comments. Comments asked for clarification on how the optionality provided for capabilities within certification criteria would be clearly identified to purchasers of certified EHR technology. Response. We expect that the certifications issued to EHR technology will clearly indicate whether the EHR technology was certified to any optional capability within a certification criterion or, for that matter, any optional certification criterion. The Certified HIT Product List (CHPL) will also indicate whether a certified Complete EHR or certified EHR Module was certified to an optional certification criterion or an optional specific capability within a certification criterion. 3. Scope of a Certification Criterion for Certification In the Proposed Rule, based on our proposal to codify all the 2014 Edition EHR certification criteria in § 170.314, we clarified that certification to the certification criteria at § 170.314 would occur at the second paragraph level of the regulatory section. We noted that the first paragraph level in § 170.314 organizes the certification criteria into categories. These categories include: clinical (§ 170.314(a)); care coordination (§ 170.314(b)); clinical quality measures (§ 170.314(c)); privacy and security (§ 170.314(d)); patient engagement (§ 170.314(e)); public health (§ 170.314(f)); and utilization (§ 170.314(g)). Thus, we stated that a certification criterion in § 170.314 is at the second paragraph level and would encompass all of the specific capabilities in the paragraph levels below with, as noted in our discussion of “applicability,” an indication if the certification criterion or the specific capabilities within the criterion only apply to one setting (ambulatory or inpatient). Comments. We received no comments on this clarification. Response. Having adopted the 2014 Edition EHR certification criteria in § 170.314 as we proposed, our clarification remains accurate. Additionally, we offer further clarity with an illustration of this principle using the “demographics” certification criterion adopted at § 170.314(a)(3) (second paragraph level). The certification criterion includes two specific capabilities at (3)(i) and (ii) (third paragraph level): “(i)” enable a user to electronically record, change, and access patient demographic data including preferred language, gender, race, ethnicity, and date of birth (in accordance with the specified standards for race, ethnicity, and preferred language (§ 170.314(3)(i)(A) and (B)); and, “(ii)” for the inpatient setting only, enable a user to electronically record, change, and access preliminary cause of death in the event of mortality. Consequently, to meet the demographics certification criterion, for example, EHR technology designed for the inpatient setting would need to meet § 170.314(a)(3)(i)(A) and (B) and (ii), while EHR technology designed for the ambulatory setting would only need to meet (3)(i)(A) and (B) because the capability at (3)(ii) only applies to the inpatient setting. 4. Explanation and Revision of Terms Used in Certification Criteria In the Proposed Rule, we noted that certain terms are repeatedly used in the proposed 2014 Edition EHR certification criteria. We stated that, based on our experience and stakeholder feedback related to how terms in the 2011 Edition EHR certification criteria have been interpreted, it was necessary in certain cases to select different terms. Therefore, we provided the following list of terms that are repeatedly used in the 2014 Edition EHR certification criteria and the intended meaning for each term. “User” is used to mean a health care professional or his or her office staff or a software program or service that would interact directly with the CEHRT. This is essentially the same description that we gave to “user” in the S&CC July 2010 final rule (75 FR 44598). We clarified that, unless expressly stated otherwise, “user” does not mean a patient. “ Record ” is used to mean the ability to capture and store information in EHR technology. We consider this meaning complementary to and consistent with related terms, namely “change and “access,” and their associated capabilities. “ Change ” is used to mean the ability to alter or edit information previously recorded in EHR technology. We proposed to replace the term “modify” used in the 2011 Edition EHR certification criteria with “change.” Although we interpret both terms to have essentially the same meaning, we believe “change” connotes a more plain language meaning as recommended by plainlanguage.gov. 1 In certification criteria in which this term is used, we stated that we do not intend for it to be interpreted to mean that information previously recorded would be able to be changed without the retention of prior value(s). Rather, a change must be retained as an audited event and in a viewable format that identifies the changed information in a patient's record (similar to how one might see changes represented in a word-processing application). How such changes are displayed is a design decision left to EHR technology developers. 1 http://www.plainlanguage.gov/howto/wordsuggestions/simplewords.cfm#lm “ Access ” is used to mean the ability to examine or review information in or through EHR technology. We proposed to replace the term “retrieve” used in the 2011 Edition EHR certification criteria with “access” because we believe it is clearer and more accurately expresses the capability we intend for EHR technology to include. We noted that some stakeholders had interpreted “retrieve” to suggest that the EHR technology also needed to be able to obtain data from external sources. Nevertheless, we stated that we interpret both “access” and “retrieve” to have essentially the same meaning, but note that “access” should not be interpreted to include necessarily the capability of obtaining or transferring the data from an external source. “ Incorporate ” is used to mean to electronically import, attribute, associate, or link information in EHR technology. With the exception of import, we previously used these terms to describe the “incorporate” capability included in certification criteria as illustrated by the capability specified at § 170.302(h)(3). We proposed to revise its unique meaning for the 2014 Edition EHR certification criteria and the purposes of certification to account for the ability to electronically import information. “ Create ” is used to mean to electronically produce or generate information. We proposed to replace the term “generate” used in the 2011 Edition EHR certification criteria with “create.” We stated that “create” is clearer and is a better word choice than generate from a plain language perspective. “ Transmit ” is used to mean to send from one point to another. Comments. Commenters expressed general support for our proposed replacement of terms in certification criteria with the proposed terms described above. A few commenters, however, expressed confusion about our description of “incorporate” as we described it and used it in different certification criteria such as the proposed “transitions of care-incorporate summary care record” certification criterion (§ 170.314(b)(1)) and the “incorporate laboratory tests and values/results” certification criterion (§ 170.314(b)(5)). Response. We appreciate the support for the proposed term replacements and are replacing the terms as proposed, except for the term “incorporate.” We agree with commenters that our description of incorporate could create confusion based on the context in which we proposed to use it in different certification criteria. In consideration of comments received, we have revised our description of incorporation to reflect the common interpretation commenters stated they assigned to the term. Thus, when the term incorporate is used within a certification criterion it is intended to mean to electronically process structured information from another source such that it is combined (in structured form) with information maintained by EHR technology and is subsequently available for use within the EHR technology by a user. As part of the 2014 Edition EHR certification criteria, the “transitions of care” and “incorporate laboratory tests and values/results” certification criteria at § 170.314(b)(2) and (b)(5), respectively, reference this term in the context of a specific capability that would require EHR technology to be able to incorporate information. Comments. Commenters expressed confusion about how to interpret our use of the phrase “included in one or any combination of the following” in certification criteria. Response. To eliminate any potential confusion, we have revised the certification criteria containing this phrase to read “each one and at least one combination of the following data.” We use this phrase to mean that the capability for which certification is required must be able to individually address each of the data specified in the certification criterion and at least one combination of those data. “One combination” means a combination of two or more of the data listed in the certification criterion. For example, in the clinical decision support (CDS) certification criterion six categories of data are listed in paragraphs § 170.314 (a)(8)(i)(A) through (F). The certification criterion states “enable a limited set of identified users to select (i.e., activate) one or more electronic clinical decision support interventions … based on each one and at least one combination of the following data.” Thus, to meet this certification criterion EHR technology must be able to enable the selection of CDS interventions that would be separately applicable to the data listed in (A) through (F) and at least one combination of the data listed in (A) through (F), such as (A) and (D) (problems and demographics). To provide further clarity for the 2014 Edition EHR certification criteria, we have revised a number of certification criteria to now begin with “EHR technology must be able to * * *” rather than “Enable a user to * * *.” We believe this approach more clearly communicates that the EHR technology must demonstrate the capability to be certified to the certification criterion. As one last point of clarification, we replaced “data element” references in certification criteria, where appropriate, with simply “data.” We believe this clarifies when we intend to mean data that includes types and elements. We also believe this will prevent confusion when the reference point is solely a “data element.” Comments. Commenters asked how terms used in MU objectives and measures are defined for the purposes of the 2014 Edition EHR certification criteria, such as “electronic notes,” “images,” “care plan,” and “care team.” Response. We incorporate in our certification criteria the terms used in MU objectives and measures as they are defined or described in the Stage 2 final rule. 5. Consensus-Based Standards Comments. Commenters stated that for interoperability to be successful, it was essential that standards be created through collaborative, consensus-based processes that take into consideration the needs and concerns of all interested stakeholders. Response. Federal agencies are required under the National Technology Transfer and Advancement Act of 1995 (NTTAA) (15 U.S.C. § 3701 et seq.) and OMB Circular A-119 2 to use, wherever practical, technical standards that are developed or adopted by voluntary consensus standards bodies to carry out policy objectives or activities, with certain exceptions. Both the NTTAA and OMB Circular A-119 provide for certain exceptions to selecting only standards developed or adopted by voluntary consensus standards bodies, namely when doing so would be inconsistent with applicable law or otherwise impractical. In this final rule, we have adopted or refer to voluntary consensus standards, except for the following government-unique standards: the Office of Management and Budget Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity; the three transport standards adopted in § 170.202; the standard that identifies the data elements referenced by clinical quality measures (adopted at § 170.204(c)); and certain standards related to the protection of electronic health information adopted in § 170.210. We are aware of no voluntary consensus standards that would serve as alternatives to these standards for the purposes that we have identified. 2 http://www.whitehouse.gov/omb/circulars_a119. Comments. A commenter suggested that we incorporate the HL7 EHR System Functional Model (ISO/HL7 10781 standard) into certification. The commenter noted that is a long-standing international consensus standard for EHR System functionality and that Release 2 of this standard is currently in ballot by the International Standards Organization Technical Committee 215 on Health Informatics (ISO TC215), the Committee for European Normalization Technical Committee 251 (CEN TC251), the International Health Terminology Standards Development Organisation (IHTSDO), the Clinical Data Interchange Standards Consortium (CDISC) and Health Level Seven (HL7). The commenter suggested that “linking” the function and conformance criteria of the internationally-recognized ISO/HL7 10781 standard to the 2014 Edition EHR certification criteria for the purposes of certification would make EHR technology certified under the ONC HIT Certification Program more competitive in international markets. Response. It is our understanding that the HL7 EHR System Functional Model provides a comprehensive set of EHR system functional requirements that in many cases goes beyond the scope of the capabilities required by the 2014 Edition EHR certification criteria. As such, this comment is outside the scope of this current rulemaking. However, we strongly support methods that could be used to increase international interoperability and acceptance of EHR technology certified under the ONC HIT Certification Program. Accordingly, we intend to explore and request that the HITPC and HITSC consider the applicability and usefulness of the HL7 EHR System Functional Model as a basis for future recommendations on certification criteria. 6. Adopting Versions of Standards Comments. We received comments recommending that we adopt standards at a higher level of abstraction and that we should not be overly prescriptive about the exact version and release of vocabulary and messaging protocols. That is, that we should not adopt a particular version of a content exchange standard for which certification would be required, (e.g., HL7 2.x, where “x” could be any version within the version 2 family) and accompany the adopted standards with detailed implementation specifications or guidance outside of rulemaking. Response. While the commenters' recommendation may provide added flexibility, we are unable to accept the recommendation for multiple reasons. First, it has the potential to create interoperability challenges. Second, there are processes under the Administrative Procedure Act that must be followed for the adoption of substantive requirements. Third, in accordance with Office of the Federal Register regulations related to “incorporation by reference,” 1 CFR part 51, which we follow for this final rule, the publications we reference are “limited to the edition of the publication that is approved” and do not include “[f]uture amendments or revisions of the publication.” Consequently, we do not include regulatory language that refers, for instance, to “Version 1.X” when “X” remains a variable. We note, however, that we have taken two steps for certain vocabulary standards designated as minimum standards code sets. First, in this final rule we have adopted updated versions of four vocabulary standards that we proposed for certification in the Proposed Rule. We proposed the use of the January 2012 International Release of SNOMED CT®, but have adopted the July 2012 International Release of SNOMED CT® as well as the March 2012 U.S. Extension to SNOMED CT®. We proposed the use of version 2.38 of LOINC®, but have adopted version 2.40. We proposed the use of the February 2012 monthly version of RxNorm, but have adopted the August 2012 monthly version of RxNorm. We proposed the use of the August 15, 2011 version of CVX code sets, but have adopted the updated through July 11, 2012 version. In all these instances, we have found that the newer versions improve interoperability and EHR technology implementation, support MU, and do not create additional substantive requirements in comparison to the proposed versions of these vocabulary standards. Further, the adoption of these versions establishes the baseline in the CFR with the most recent versions of these vocabulary standards that is possible. Second, we have also established an approach that permits the use of newer versions of these standards than the one adopted in the CFR. We refer readers to section IV.B for a discussion of “minimum standards” code sets and our new more flexible approach for their use in certification and upgrading certified Complete EHRs and certified EHR Modules. Readers should also review § 170.555, which specifies the certification processes for “minimum standards” code sets. 7. Display of Vocabulary Standards Comments. Several commenters asked a similarly themed question with respect to the vocabulary standards we proposed to adopt. The question centered on whether EHR technology was required to display a particular vocabulary to a user (for the certification criteria that require recording certain patient information in a vocabulary standard) in order to be certified. Commenters explained that for the problem list certification criterion that SNOMED CT® codes should not be required for display in EHR technology and that an organization should be able to use whichever code set they prefer to display. Others provided similar rationale and said that health care providers are typically unfamiliar with SNOMED CT®. Commenters raised similar questions regarding the display of race and ethnicity as well as smoking status. Response. We agree with commenters and want to make clear that EHR technology does not have to display an adopted vocabulary to a user to be certified to the certification criterion that includes the vocabulary standard. For a more detailed discussion and example of our intent please review our responses to the problem list certification criterion. 8. Common Data in Certification Criteria Comments. Several commenters pointed out that we repeat much of the same data in the “view, download, and transmit to a 3rd party,” “clinical summaries,” and both “transitions of care” certification criteria. These commenters suggested that we specify a single definition that included this common data and then reference that definition in the applicable certification criteria. They added that this would cut down on the repetitiveness of the certification criteria, make the certification criteria smaller and, thus, easier to read, and that this approach would be more efficient overall. Commenters recommended that we define a “Summary Care Record.” Response. We agree with commenters' suggestions. Further, we note that the data we reference in these certification criteria mirror those specified by CMS for the objectives and measures to which these certification criteria correlate. Because there is a common set of MU data types/elements for which certification would be required across several certification criteria, we have created the term “Common MU Data Set.” We define this term by only the data that is common to (i.e., included in all five certification criteria) the “view, download, and transmit to a 3rd party,” “clinical summary,” “transitions of care—receive, display, and incorporate transition of care/referral summaries,” “transitions of care—create and transmit transition of care/referral summaries,” and “data portability” certification criteria (see Table 2 below). We decline to create a specific definition for “summary care record” because the Common MU Data Set definition serves multiple certification criteria that reference different “summary” oriented documents. For instance, data referenced in the “clinical summary” shares the data in the Common MU Data Set with the “transitions of care” certification criteria, but also includes unique data that is specific to a clinical summary. The following data are included in the Common MU Data Set definition and where applicable reference the standard that would have otherwise been assigned if the data were individually included within the certification criteria. Table 2—Common MU Data Set 1. Patient name 2. Sex. 3. Date of birth 4. Race. 5. Ethnicity 6. Preferred language. 7. Smoking status 8. Problems. 9. Medications 10. Medication allergies. 11. Laboratory test(s) 12. Laboratory value(s)/result(s). 13. Vital signs (height, weight, BP, BMI) 14. Care plan field(s), including goals and instructions. 15. Procedures 16. Care team members. We also believe that further clarity for stakeholders can be provided through the use of more specific descriptions for the different types of “data summaries” referenced in certification criteria. These specific descriptions are listed below and are used in the applicable certification criteria and referenced in the preamble discussions of the certification criteria. This revision is intended to make the data referenced in the final rule and the “data summary” to which it is assigned more readily apparent to readers. We note that the use of these specific descriptions in the certification criteria are for regulatory clarity purposes only and do not imply any additional meaning. Certification criterion Type of summary Data portability § 170.314(b)(7) Export Summary. Transitions of care—receive, display, and incorporate transition of care/referral summaries § 170.314(b)(1) Transition of care/referral summary. Transitions of care—create and transmit transition of care/referral summaries § 170.314(b)(2) View, download, and transmit to a 3rd party § 170.314(e)(1) Ambulatory Summary. Inpatient Summary. Clinical Summary § 170.314(e)(2) Clinical Summary. 9. New Certification Criteria In the Proposed Rule, we described certification criteria that we considered “new.” We noted the following factors that we would consider when determining whether a certification criterion is “new”: • The certification criterion only specifies capabilities that have never been included in previously adopted certification criteria; or • The certification criterion was previously adopted as “mandatory” for a particular setting and subsequently adopted as “mandatory” or “optional” for a different setting. Comments. We did not receive comments questioning our description of new certification criteria. Response. We therefore continue to use this description of new certification criteria to categorize the following certification criteria we have adopted as part of the 2014 Edition EHR certification criteria. The adopted new certification criteria include those certification criteria that we explicitly proposed in the Proposed Rule and two additional certification criteria stemming from proposals related to quality management principles for EHR technology development and data portability for which we solicited comments. We have not adopted the proposed “non-percentage-based measure use report” certification criterion. a. Ambulatory and Inpatient Setting We have adopted 9 new certification criteria that will be applicable to both the ambulatory and inpatient settings. We also discuss the proposed “non-percentage-based measure use report” certification criterion but, as noted above, we have not adopted it as part of the 2014 Edition EHR certification criteria. • Electronic Notes MU Objective Record electronic notes in patient records. 2014 Edition EHR Certification Criterion § 170.314(a)(9) (Electronic notes). We proposed a certification criterion that was similar to the one recommended by the HITSC to support the MU objective and measure recommended by the HITPC. CMS did not specifically propose the HITPC recommended MU objective and measure for Stage 2, but requested public comment on whether the objective and measure should be incorporated into MU Stage 2. We proposed to replace the terms “modify” and “retrieve” in the recommended criterion with “change” and “access,” respectively. We proposed that “search” in the certification criterion was intended to mean the ability to search free text and data fields of electronic notes. We further proposed that the ability to search would mean the ability to search the notes that any licensed health care professional has included within the EHR technology and the ability to search for information across separate notes rather than just within notes. Comments. Many commenters stated that we should not adopt an electronic notes certification criterion without CMS establishing a corresponding MU objective and measure. Commenters requested that we define a note for qualifying in the numerator and clarify who could create, edit, and sign a note. Commenters suggested permitting a range of options for capturing notes, such as templates and free text. A few commenters suggested that electronic notes should be recorded in structured data. These commenters thought this would help avoid illegible scanned notes or make searching more efficient and useful (e.g., searching be defined attributes such as physician name). One commenter suggested structured data fields that include: symptomatic (subjective); objective; assessment; and plan. The same commenter suggested specific note structure for patient problem lists. Commenters expressed general support for the search functionality. They stated that the ability to search notes for relevant keywords will reduce time spent reviewing documentation that is irrelevant to the patient's current medical condition(s). Commenters, however, asked for further clarification on the extent of the search capability EHR technology needed to have in order to meet this certification criterion. Commenters expressed concern that this certification criterion would require a capability to search across notes, especially across providers and patients' charts. Multiple commenters suggested that a reasonable requirement for certification would be to require the capability to search for a free-text string within a particular open note, while other search capabilities should be left as competitive differentiators within the marketplace. These commenters noted that more specific certification requirements could interrupt innovative ways to do effective chart search and information display. Conversely, other commenters suggested requiring additional search functionality, such as searching across notes based on date ranges or indexing of notes in much the same way today's common search engines create background indexes allowing for almost instant retrieval of documents (e.g., Google, Spotlight on the Mac or “locate” on Unix-based machines). Commenters stated that some providers will find it particularly challenging and burdensome to directly document their notes into EHRs. For example, some EPs would need to have their notes dictated or transcribed. Commenters stated that many hospitals scan physician paper notes into EHR technology, particularly in the small hospital setting where the EPs are not normally employed by the hospital. A commenter suggested that the capabilities included in this certification criterion be expanded to require EHR technology to be able to export electronic notes as CDA Level 2 documents. The commenter stated that this would require the electronic notes to be wrapped with a CDA document header and to identify the document type and section headings with LOINC® codes. The commenter stated that this would not be an onerous requirement because most commercial transcription services can already meet these requirements. The commenter further stated that this requirement would provide hundreds of millions of interoperable clinical documents per year and enrich the clinical content shared during care transitions. Response. We have adopted an “electronic notes” certification criterion for the 2014 Edition EHR certification criteria at § 170.314(a)(9) as proposed. After consideration of public comments, CMS has included an “electronic notes” objective and measure in the MU Stage 2 menu set and the adoption of this certification criterion will support that objective and measure. We direct commenters to the Stage 2 final rule for further discussion of the “electronic notes” objective and measure, including description of notes that qualify for the numerator and explanation of who can create, edit, and sign a note. We did not propose, nor do we believe, that there is a standard and industry-wide accepted format for capturing electronic notes. Therefore, we agree with the commenters that suggested that a range of options be permitted for capturing notes, including templates and free text. We also note that in the Stage 2 final rule scanned notes that are text searchable are acceptable for inclusion in the numerator. This requirement should address the commenters' concern about illegible scanned notes. We appreciate the support expressed for the search capability included in this certification criterion. After consideration of comments, we have concluded that the search capability that EHR technology must demonstrate to meet this certification criterion should be limited to the ability to search within a note. We believe this will provide EPs, EHs, and CAHs with a search capability that will be useful, but still permit EHR technology developers to design and develop search capabilities that meet specific customer needs. Additionally, as commenters noted, this will permit the market to innovate and offer various search capabilities for EPs, EHs, and CAHs. While we appreciate the commenter's suggestion that the capabilities included in this certification criterion be expanded to require EHR technology to be able to export electronic notes as CDA Level 2 documents, we decline to require EHR technology to demonstrate this capability as a condition of certification since such a capability would go beyond what we believe it is necessary to require for certification in support of MU. • Image Results MU Objective Imaging results and information are accessible through Certified EHR Technology. 2014 Edition EHR Certification Criterion § 170.314(a)(12) (Image results). We proposed to adopt a new “imaging” certification criterion as part of the 2014 Edition EHR certification criteria to support an EP's, EH's, and CAH's performance of the proposed new MU objective and measure. In the Proposed Rule, we clarified that the phrase “immediate electronic access” was intended to mean that a user should be able to electronically access images and their narrative interpretations directly and without, for example, having to log in to a separate electronic system or repository. We stated that this access could be provided by multiple means, including, but not limited to, “single sign-on” and “secure identity parameter passing.” We also considered the Digital Imaging and Communications in Medicine (DICOM) standard for this certification criterion, but concluded that the adoption of this or other standards was not necessary to enable users to electronically access images and their narrative interpretations, as required by this certification criterion. We have categorized and responded to comments under subheadings for the purposes of clarity and readability. Types of Images Comments. Commenters requested a clear definition of “image” as well as “narrative interpretation.” Commenters asked whether both cardiology and pathology images are included or whether images were limited to radiology. A few commenters specifically suggested that images be limited to radiology and MRIs and not include photography or electrocardiograms (ECGs). One commenter suggested the inclusion of ECGs. Response. It is outside the scope of this rulemaking to define the scope of images and narrative interpretations. We direct commenters to the Stage 2 final rule found elsewhere in this issue of the Federal Register for a discussion of the MU objective and measure and responses to these comments. Internal and External and Storage of Images Comments. Commenters stated that the requirement to display diagnostic images is ideal; however, the infrastructure to display images from all possible modalities, along with all possible technology solutions within the ambulatory setting, would require huge numbers of costly interfaces to integrate the images into the EHR technology. Commenters further stated that clinical images are often large and stored on external PACS systems. As such, these commenters contended that requiring EHR technology to duplicate image storage and perform at the level of a PACS system would be difficult and unnecessary functionality for EHR technology. Some commenters stated that EHR systems should not be required to store images, since the use of reference pointers is enabled by DICOM Web Access to DICOM Persistent Objects (WADO) standards. Commenters stated that the incorporation of scanned images into EHRs is generally ineffective at improving patient care. These commenters stated that when images are scanned into EHRs, physicians cannot manipulate the data, which may prevent them from truly seeing the images or understanding what the images represent. A few other commenters stated that the storing of images by any means to facilitate access will be costly. Commenters recommended that the certification capability be limited to directly linking to images stored in the EHR technology or providing a context-sensitive link to an external application, which provides access to images and their associated narrative. Other commenters asserted that current EHR technology does not track whether a PACS link is “available” or “clicked on” because the user interaction happens largely with the Web-based PACS application. These commenters believed that there might be barriers to EHR technology collecting information about the availability of third party data accessible via a Web link within the EHR to sufficiently meet this requirement. A few commenters suggested that we limit the capability to provide narrative interpretations and recommended that the ability to view images within or through EHR technology be optional. Response. We have adopted a new “image results” certification criterion to support the new MU objective and measure. We clarify that we did not propose nor are we requiring that EHR technology has to be able to store images to meet this certification criterion. EHR technology can meet this certification criterion by demonstrating a capability to directly link to images stored in the EHR system or providing a context-sensitive link to an external application which provides access to images and their associated narrative. By “context sensitive link” we mean that the link to the image will ideally include parameters that enable access to the images themselves rather than access to a system—which would require login, patient search, image selection, and (finally) image viewing. However, we agree with commenters that there is insufficient penetration of single sign-on or services-oriented integration capabilities between EHR technology and PACS systems, and that the fluidity with which this access is enabled may not be under the CEHRT's control. We therefore do not explicitly require that this link provide “immediate access” as described below. Finally, we emphasize that access to both narrative and imaging data must available to the user. In cases where there is no narrative data (for example when a radiographic image has not yet been interpreted by a radiologist) there will obviously be no narrative available. Nonetheless, the EHR technology must be capable of retrieving and displaying the narrative information in order to meet this certification criterion. Comments. A commenter requested clarification on whether the proposed certification criterion pertains only to EPs who send x-rays outside of their facility or whether providers that take x-rays in their own offices required to meet this certification criterion. Response. This certification criterion applies to EHR technology designed for both the ambulatory and inpatient setting and expresses the capabilities that EHR technology would need to include in order to be certified to this certification criterion. Clarification of Certification Criterion Text Comments. A few commenters asked for clarification of “and/or” and whether it implies optionality regarding either images or the corresponding narratives. Alternatively, the commenters asked if it means that the EHR technology must be certified for both availability of images and narrative interpretations. Other commenters asked whether the intent of “electronically indicated to a user the availability of a patient's images” was to identify imaging results as available in order to circumvent redundant imaging tests. If that is the intent, the commenter recommend that we require, at minimum that information on when the imaging test was completed, results pending, results location and date of completion be provided. Similarly, a commenter requested clarification of whether a “list” of past imaging tests completed would helpful. Response. For clarity, we have removed the “or” from the “and/or” in the regulation text. EHR technology must be capable of electronically indicating the availability of both images and narrative interpretations. Redundant imaging tests can lead to unnecessary costs. We believe that the capabilities included in this certification criterion can assist in preventing redundant testing. This certification criterion, however, includes those capabilities that are necessary to support an EP, EH, or CAH's attempt to achieve the associated MU objective and measure. Therefore, we decline to include the additional capabilities recommended by the commenters. Immediate Electronic Access Comments. Some commenters expressly supported our proposal that users should have “immediate electronic access” to images and their narrative interpretations directly and without having to login to a separate electronic system. Many commenters stated that the requirements for “immediacy” go beyond the capabilities of the EHR system. Some commenters suggested the term “immediate” be removed from the certification criterion. Other commenters requested clarification of what immediate electronic access entailed. A commenter stated that there appeared to be two different functions coupled with the word “immediate”—taking the image and getting access to the image. Commenters also specifically stated that the requirements for “immediacy” via additional sign-on capabilities and other system requirements are beyond the control of the EHR system and, thus, should not be required for certification. One commenter suggested that, in order to ensure immediate access, EHR technology should provide stream-capable hyperlinks to images that can be viewed in a typical web browser without the delay related to use of DICOM file transfer and without the requirement to install additional software beyond the standard web browser itself. Response. We agree with commenters that “immediate” access is vague and would be difficult to implement in EHR technology at this time, particularly with methods such as single sign-on. Therefore, we are removing the term “immediate” from the certification criterion. Applicable Standard Comments. Some commenters suggested that no standard be adopted for this certification criterion. Conversely, some commenters recommended the inclusion of the DICOM standard as a requirement for EHR certification, as well as certification of DICOM compliance for the storage and transmission of images. Commenters reasoned that the DICOM standards and complementary implementation guides developed by Integrating the Healthcare Enterprise® (IHE) provide satisfactory methods for the formatting of medical imaging and for their access through EHR systems. Some commenters specifically recommended that DICOM Supplement 127: CT Radiation Dose Reporting (Dose SR) should be required for the transmission of patient radiation dose information. Some commenters suggest that we adopt the Consolidated CDA Diagnostic Imaging Report standard and the DICOM image standard for exchanging images and their interpretations. A few commenters recommended that we at least communicate that we intend to move towards requiring this standard to complement the DICOM image standard for use in exchanging images and their interpretations. Response. We appreciate commenters' recommendations regarding the DICOM standard, but the recommendations and information provided has not altered our position expressed in the Proposed Rule nor has CMS made revisions to the associated MU objective and measure that would alter our position. As stated in the Proposed Rule, we concluded that the adoption of the DICOM standard (or any other standards) was unnecessary to enable users with electronic access to images and their narrative interpretations, the capability required by this certification criterion and for MU. • Family Health History MU Objective Record patient family health history as structured data. 2014 Edition EHR Certification Criterion § 170.314(a)(13) (Family health history). We proposed to adopt at § 170.314(a)(13) a 2014 Edition EHR certification criterion for family health history. The proposed certification criterion required that EHR technology be able to, at minimum, electronically record, change, and access the health history of a patient's first-degree relatives. The Proposed Rule also solicited comment on whether we should adopt specific standards for this certification criterion, including the HL7 Pedigree standard 3 and the use of Systematized Nomenclature of Medicine—Clinical Terms (SNOMED CT®) terms for familial conditions. We also noted that the Surgeon General had produced a tool that can capture, save, and manage family health histories using standard vocabularies and can export the data in eXtensible Markup Language (XML) format and sought comments on the maturity and breadth of adoption of this tool and its export format. 3 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=8. Comments. Commenters generally supported the concept of including a certification criterion related to family health history. A commenter noted that our description of the capabilities in this certification criterion was somewhat ambiguous and thus requested confirmation that we did not mean to imply that this criterion requires the capability to access the patient's first degree relatives' records. Many commenters expressed that the HL7 Pedigree standard was not widely used or sufficiently mature to adopt at the present time. Similarly, many commenters also expressed that if a specific terminology is required for coding familial conditions, then SNOMED CT® would be an appropriate terminology. Commenters requested that the certification criterion permit unstructured/free text entry. Response. We appreciate commenters' general support for this certification criterion. Equally, CMS received a great deal of support and has included a family health history objective in the MU Stage 2 menu set. Accordingly, we have finalized a certification criterion for family health history. We clarify that this certification criterion requires EHR technology to demonstrate that it is capable of enabling a user to electronically record, change, and access a patient's family health history. This means that EHR technology must, at minimum, be capable of recording information about a patient's first degree relative in the patient's record and permitting a user to change and access that information as needed. EHR technology would not need to be able to access the records of a patient's first degree relatives. In support of MU, this certification criterion requires that EHR technology be capable of capturing family health history in structured data. Therefore, the certification criterion we have adopted does not permit unstructured/free text for certification because such entries would not constitute MU of CEHRT. Similar to commenters, we believe that SNOMED CT® is an appropriate terminology, and perhaps the best intermediate step, for coding family health history in structured data if one was not to use the HL7 Pedigree standard. We also understand that some organizations have built family health history CDS interventions using SNOMED CT®. The HL7 Pedigree standard was originally released in 2007. Release 1 was recently reaffirmed by the American National Standards Institute (ANSI), which is a process that occurs every five years. We have adopted this reaffirmed version as it is the same version (Release 1) of the standard as the version we proposed. An implementation guide for this standard is scheduled to be published shortly after this final rule. Although EHR technology will not be required to conform to the implementation guide for certification, the implementation guide will provide important guidance for use of the HL7 Pedigree standard with EHR technology. We have finalized that EHR technology may meet this certification criterion by either being able to capture a patient's family health history in SNOMED CT® or in the HL7 Pedigree standard. Since the use of SNOMED CT® is required for meeting several other certification criteria, we do not believe that it will be a challenge to meet this certification criterion. We emphasize, as specified in the § 170.300(b), when “a certification criterion refers to two or more standards as alternatives, use of at least one of the alternative standards will be considered compliant.” Thus, an EHR technology can demonstrate use of SNOMED CT® or the HL7 Pedigree standard to meet this certification criterion. • Amendments MU Objective Protect electronic health information created or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities. 2014 Edition EHR Certification Criterion § 170.314(d)(4) (Amendments). We proposed to adopt a new “amendments” certification criterion (§ 170.314(d)(4)) as part of the 2014 Edition EHR certification criteria. We made this proposal based on HITPC and HITSC recommendations which included that a certification criterion should be adopted that provides some of the basic technical tools to support compliance with the HIPAA Privacy Rule. We noted in the Proposed Rule that the proposed certification criterion does not address all of the requirements specified at 45 CFR 164.526 and that EHR technology certification is not a substitute for, or guarantee of, HIPAA Privacy Rule compliance. Finally, we requested comment on whether EHR technology should be required to be capable of appending patient supplied information in both free text and scanned format or only one or these methods to be certified to this proposed certification criteria. Comments. Many commenters recommended that the proposed certification criterion's reference to “free text or scanned” patient supplied information be revised. Many supported both and suggested that both be permitted. Others contended that the certification criterion was over specified and suggested that ONC not specify one or the other because patient-supplied information could take many forms. In general, commenters suggested that EHR technologies have different ways of appending information and that either of these methods would be sufficient for certification. Another commenter noted that scanning patient amendments could be problematic from a storage perspective. One commenter agreed with the certification criterion but recommended that ONC should have robust standards for how patient information is appended to EHR technology before allowing EHR technology developers to create multiple versions of this workflow. Yet another stated that the ability to append patient supplied information should be no different from the ability to append any other ancillary information (outside reports from other providers). One commenter stated that EHR technology developers should only need to be certified to one method of amendment and not all (i.e., free text, scanned information, or embedded links) in order to meet the certification criterion. Additionally, a commenter noted that amending the patient record should be allowed via the two methods proposed, but that scanned documents should have to adhere to a standard such as PDF or JPG. Last, a group of commenters took issue with the phrase “electronic link” in the certification criterion. They raised concerns that the phrase “embedding an electronic link” in the certification criterion could be interpreted in many ways, including some that would create security risks. Commenters suggested removing “or by embedding an electronic link” to allow different forms and ways to append patient-supplied information. They also noted that the HIPAA Privacy Rule does not mention electronic links. Response. In consideration of the comments received, we have modified this proposed certification criterion to make clear the capabilities that EHR technology must include in order to be certified. As we indicated in the Proposed Rule, we proposed this certification criterion at the HITPC's recommendation. Along those lines, we reiterated our agreement with the HITPC's expectation for this certification criterion, that it be “kept as simple as possible and evolve over time to greater complexity, including potentially greater standardization and automation.” Our revisions seek to make clear this certification criterion's focus on supporting the instance where a HIPAA covered entity agrees or declines to accept a patient's request for an amendment. Additionally, this certification criterion is meant to be a starting point from which more comprehensive capabilities and standards can be included, so we disagree with the commenter that suggested we wait until more comprehensive standards are available. In response to commenter feedback, we have revised the certification criterion to more closely mirror the language in the HIPAA Privacy Rule at 45 CFR § 164.526. In doing so, we no longer specify a particular format (i.e., free text or scanned) and we have revised the language associated with “electronic link.” The “link,” which is an alternative to appending the patient's record must convey to a user or enable a user to obtain the information associated with an amendment's acceptance or denial. We believe this adjustment to the certification criterion provides EHR technology developers with more flexibility with which to design a capability that can accommodate the outcome this certification criterion expresses. Comment. A commenter supported this proposed certification criterion and stated that there should be a mechanism to identify and make visible the source of the information to allow evaluation by any recipient that the information came from a reliable and accurate source. Response. We appreciate this commenter's suggestion. However, it appears to be more specific than we believe necessary at this point for this new certification criterion. We believe that the requirements we have included in the final certification criterion are a sufficient start. We also believe that the certification criterion may, in part, address this commenter's suggestion in that the information appended or linked in the case of an accepted or denied amendment should at least have an indication as to the source of the information (i.e., patient or provider/organization). Comments. Several commenters sought clarification as to whether patient-supplied information had to be appended to specific data in the patient's health record or attached to a specific instance of a clinical note or document. Another commenter expressed concern regarding the feasibility of being able to append patient supplied information to specific data. The commenter stated that this practice would be inconsistent with common provider policies that require all amendments to documents be classified as separate documents. In this way such information is clearly identified and maintained in a section or folder of the electronic record, and then subject to clinician review for what may be actually incorporated into the record upon acceptance. They indicated that by following this approach the patient requested amendment has its own “wholeness” or integrity as a medical record entry. In general, other commenters echoed this statement and suggested that it should be acceptable to have a separate section of the record for patient-supplied information. Response. The final certification criterion does not require that accepted or denied amendments be appended to specific data in order for compliance to be demonstrated. As indicated above, this criterion is intended to support compliance with the HIPAA Privacy Rule's amendment requirements at 45 CFR 164.526. The Privacy Rule provides some flexibility with how accepted or denied amendments are appended to an individual's protected health information, recognizing that the type and scope of an amendment will vary based on the circumstances. For example, the affected record could include a link to documentation of an accepted or denied amendment, while still allowing, in the case of an accepted amendment, any necessary corrections to be incorporated directly into the record itself. Comments. A couple of commenters requested clarification regarding the interplay between the terms “amend” and “append” in the certification criterion. One commenter stated that amendments are documentation meant to clarify health information within a health record whereas addendums are new documentation used to add information to an existing entry, and corrections are changes to information meant to clarify inaccuracies after the original document has been signed or rendered complete. The other commenter stated that we described “amending” a patient's record as allowing clinicians to correct errors or update the information within their record and that later we referred to the act of “appending” patient supplied information by using free text and/or scanned material. This commenter stated that “amend” and “append” are distinct concepts and should not be combined into one certification criterion because if we intend to allow these functions of correcting and/or attaching information to the patient's record they should remain separate. The commenter reasoned that amending should not permit any overwriting of the existing documentation and should include a date, time and authentication record of who took the action—while appending data should accurately capture the date, time, and authentication of the appended information. Response. The terminology used in this certification criterion is meant to mirror the terms used in the HIPAA Privacy Rule at 45 CFR 164.526. Put simply, those rules describe that a patient is permitted to request an amendment to their health information and the corresponding obligations a HIPAA covered entity must follow to either accept or deny the requested amendment. As stated in 45 CFR § 164.526(c)(1), for example, if the amendment is accepted, “[t]he covered entity must make the appropriate amendment to the protected health information or record that is the subject of the request for amendment by * * * appending or otherwise providing a link to the location of the amendment.” Thus, this certification criterion reflects some of the capabilities needed in the event of an accepted or denied amendment. Comment. A commenter stated that § 170.314(d)(4)(i)(A) conflicts with the description of the term of “Change” included in the Proposed Rule and that this criterion needs to be consistent with that definition. Response. This comment is incorrect. The term “change” as described in the Proposed Rule was not included in this certification criterion. Thus, there is no conflict with respect to the clarity of the capabilities specified by this certification criterion and others that include the term “change.” Comment. A commenter asked for clarification on the degree of information retained. They stated that too much information makes the data storage requirements burdensome on providers and superfluous data makes it difficult for auditors to detect unauthorized access. Response. This certification criterion seeks to specify the EHR technology capabilities necessary to support, in part, the requirements specified at 45 CFR § 164.526 and it is not within its scope to address the degree or amount of information retained. Comment. A commenter recommended that the electronic amendment contain a date/time stamp and reflect the user who took such action when content is amended. Response. We appreciate this commenter's suggestion, however, we expect that this kind of event would be subject to the audit log requirements we have already specified (and which includes time and date stamp). Comments. One commenter asked for clarification as to whether this criterion makes a distinction between “work in progress” records and “signed off” records. They stated, for example, a user may make several changes to the same data while working within a particular screen of the EHR technology. They suggested that the changes should only be captured when the user saves their changes and signs off on the record. Response. No, this certification criterion does not make such a distinction because those distinctions are inapplicable to this certification criterion. We believe the commenter misinterpreted the purpose of this certification criterion and its focus on incrementally building in the capacity of EHR technology to make compliance with the HIPAA Privacy Rule more efficient. Comment. One commenter noted a concern that if this certification criterion is applied to EHR Modules that are not part of the Base EHR definition that it could result in conflicting and overlapping practices and result in incorrect or inconsistent information in a patient record. For example, the commenter noted that it was a downstream business associate (or business associate subcontractor) and an intermediary, and thus does not amend patient information. Further they stated that they provide notice of any requests for amendments to their upstream business associates and covered entities with whom they directly contract. They concluded by stating that requiring an intermediary or developers of certain EHR Modules to have the capability to amend information could present confusion and should be applicable to core functionality of the EHR technology utilized at the provider level. Response. For some of the reasons expressed by this commenter, we proposed to remove the requirement that EHR Modules also be certified to the privacy and security criteria. We clarify that this certification criterion is not separately applied to any EHR Modules in order for them to be certified. An EHR technology developer needs to include such capability, however, if they seek certification for EHR technology that would meet the Base EHR definition. Comments. Two commenters recommended that we remove this certification criterion. One agreed that HIT should support workflow for complying with HIPAA privacy regulations, including allowing a user to amend a patient record, but contended that this functionality is typically found in a Medical Record Management system. Thus, they encouraged ONC to remove the certification criterion. However, they stated that if it remained, we should only require scanned documents. The other commenter recommended that we delay this certification criterion's adoption to a later edition of EHR certification criteria because the technical and legal implications of supporting patient amendments to the EHR are complex and evolving. Response. We have not removed this proposed certification criterion. We agree with the HITPC that starting with a simple certification criterion can set us on a path to include more comprehensive capabilities over time. We acknowledge that the processes involved in supporting patient amendments can sometimes be difficult, which is why we explained in the Proposed Rule and reiterated in the above responses that this certification criterion can only help support (and potentially make more efficient) a HIPAA covered entity's compliance with the HIPAA Privacy Rule. Comments. Several commenters supported the proposed certification criterion, but requested joint confirmation from ONC and CMS that EPs, EHs, and CAHs do not have to demonstrate use of this capability in order to meet meaningful use. Other commenters urged us to acknowledge that this functionality has importance beyond a privacy and security context. Response. This certification criterion expresses capabilities that EHR technology would need to include in order to meet this certification criterion. Given that this certification criterion is included as part of the Base EHR definition, EPs, EHs, and CAHs, will need to have EHR technology certified to this certification criterion in order to have EHR technology that meets both the Base EHR and CEHRT definitions. We have consulted with CMS and clarify that since there is not a meaningful use objective expressly requiring the use of this capability to satisfy an associated measure that EPs, EHs, and CAHs do not need to demonstrate use of this capability in order to meet any meaningful use stage. However, we encourage EPs, EHs, and CAHs to consider if this capability could make compliance with the requirements of the HIPAA Privacy Rule, particularly, 45 CFR § 164.526, more efficient. • View, Download, and Transmit to 3rd Party MU Objective EPs: Provide patients the ability to view online, download, and transmit their health information within 4 business days of the information being available to the EP. EHs and CAHs: Provide patients the ability to view online, download, and transmit information about a hospital admission. 2014 Edition EHR Certification Criterion § 170.314(e)(1) (View, download, and transmit to 3rd party). We proposed a new criterion at § 170.314(e)(1) to subsume the certification criteria previously adopted at §§ 170.304(f), 170.304(g), 170.306(d), and 170.306(e). This proposal was based on the HITPC issued MU recommendation that patients (or their authorized representative(s)) be able to view and download their health information online (i.e., Internet/web-based). The HITPC recommended that this MU objective should replace or subsume the objectives for providing patients with timely electronic access to their health information and providing patients with an electronic copy of their health information and hospital discharge instructions upon request. Consistent with these recommendations, the HITSC recommended a certification criterion that framed the capabilities EHR technology would need to include to support this new objective and that, for the 2014 Edition EHR certification criterion, the criterion should replace the certification criteria previously adopted at §§ 170.304(f), 170.304(g), 170.306(d), and 170.306(e). In addition to the view and download capabilities recommended by the HITSC, we proposed to include a third specific capability in this certification criterion—the ability to transmit an ambulatory and inpatient summary to a third party. Coupled with this addition, we proposed that EHR technology would need to be capable of transmitting an ambulatory and inpatient summary according to the two specifications—developed under the Direct Project—which we proposed for adoption: (1) Applicability Statement for Secure Health Transport 4 and (2) Cross-Enterprise Document Reliable Interchange (XDR) and Cross-Enterprise Document Media Interchange (XDM) for Direct Messaging. 5 We indicated that these transport standards were ideal for this purpose and would make it possible for patients to transmit a copy of their ambulatory or inpatient summary to the destination of their choice. Additionally, because we proposed requiring the capability to perform transmissions in accordance with these transport standards (which provide for encryption and integrity protection) in this criterion and in the “transitions of care—create and transmit transition of care/referral summaries” certification criterion, we determined that it would not be necessary to include in the 2014 Edition EHR certification criteria the “encrypting when exchanging” certification criterion adopted in the 2011 Edition EHR certification criteria (§ 170.302(v)). We stated our belief that to include the 2011 Edition EHR certification criterion would be redundant and that our proposed approach more explicitly tied security to a particular transmission. 4 http://wiki.directproject.org/Applicability+Statement+for+Secure+Health+Transport. 5 http://wiki.directproject.org/XDR+and+XDM+for+Direct+Messaging. At the recommendation of the HITSC, the proposed certification criterion required that EHR technology certified to this criterion include a “patient accessible log” to track the use of the view, download, and transmit capabilities included in this certification criterion and make that information available to the patient. We required this specific capability within this certification criterion because we believed that it was highly likely numerous EHR Modules could be certified to this criterion without also being certified to the auditable events and tamper resistance certification criterion we proposed to adopt at § 170.314(d)(2) (due to the proposed policy change we specified in section IV.C.1 of the proposed rule related to EHR Modules and privacy and security). Thus, this explicit proposal was meant to guarantee that an EHR Module certified to this criterion would include the capability to track who has viewed, downloaded, or transmitted to a third party electronic health information and that patients would have access to this information. That being said, we noted that we did not intend for this portion of the certification criterion to impose a redundant requirement on EHR technology developers who present a Complete EHR or EHR Module for certification to both this certification criterion and the auditable events and tamper resistance certification criterion. Accordingly, we provided in paragraph (e)(1)(ii)(B) of § 170.314 that EHR technology presented for certification may demonstrate compliance with paragraph (e)(1)(ii)(A) of § 170.314 if it is also certified to the certification criterion proposed for adoption at § 170.314(d)(2) and the information required to be recorded in paragraph (e)(1)(ii)(A) of § 170.314 is accessible to the patient. In other words, we clarified that an EHR technology certified to § 170.314(d)(2) would not need to also include the “patient accessible log” capability specified in paragraph (e)(1)(ii)(A) of § 170.314 because it would be capable of logging such events and providing the information to the patient. We also proposed that the “patient accessible log” capability would need to record the date and time each action occurs using a system clock that has been synchronized following either Request for Comments (RFC) 1305 Network Time Protocol (NTP) v3 or RFC 5905 Network Time Protocol Version 4: Protocol and Algorithms Specification (NTPv4). We proposed to require EHR technology to be capable of enabling images formatted according to the Digital Imaging and Communications in Medicine (DICOM) standard 6 to be downloaded and transmitted to a third party. We stated our belief that this specific capability has the potential to empower patients to play a greater role in their own care coordination and could help assist in reducing the amount of redundant and duplicative imaging-oriented tests performed. 6 ftp://medical.nema.org/medical/dicom/2011/. Consistent with our belief that all patients should have an equal opportunity to access their electronic health information without barriers or diminished functionality or quality, we proposed that the viewing capability must meet Level AA conformance with the most recent set of the Web Content Accessibility Guidelines (WCAG). We explained that the most recent set of guidelines (WCAG 2.0) were published in 2008 and are organized under 4 central principles with testable “success criteria”: Perceivable, Operable, Understandable, and Robust. 7 We further explained that each guideline offers 3 levels of conformance: A, AA, and AAA. We proposed compliance with Level AA because it provides a stronger level of accessibility and addresses areas of importance to the disabled community that are not included in Level A. In addition to WCAG 2.0 Level AA conformance, we requested public comment on whether commenters believed additional standards were needed for certification to ensure accessibility for the viewing capability, such as the User Agent Accessibility Guidelines (UAAG). 8 7 http://www.w3.org/TR/WCAG20/. 8 http://www.w3.org/WAI/intro/uaag.php. We proposed to require that EHR technology be capable of providing the information that CMS proposed be required in an ambulatory or inpatient summary that is provided to patients or their authorized representatives. This proposal was based on the HITSC's recommendation that we move to one standard for capturing this information and our belief that moving to one standard would lead to increased interoperability and spur innovation. We explained that we believed the Consolidated CDA was the most appropriate standard to achieve this goal because it was designed to be simpler and more straightforward to implement and, in relation to this rulemaking, its template structure can accommodate the formatting of an ambulatory or inpatient summary that includes all of the data elements that CMS proposed be available to be populated in an ambulatory or inpatient summary. In certain instances in § 170.314(e)(1), we proposed to require that the capability be demonstrated in accordance with the specified vocabulary standard—which were previously adopted or proposed for adoption in the Proposed Rule consistent with the recommendations of the HITSC. With the exception of four standards (LOINC®, ICD-10-CM, ICD-10-PCS, and CPT/HCPCS), the vocabulary standards included in the certification criterion were discussed elsewhere in the Proposed Rule in connection with the certification criteria where the vocabulary standard is central to the required data or serves a primary purpose (e.g., RxNorm for e-prescribing). For encounter diagnoses and procedures, we proposed the use of ICD-10 (ICD-10-CM and ICD-10-PCS, respectively). We requested comment, however, on whether we should be more flexible with this proposed requirement based on any potential extension of the ICD-10 compliance deadline or possible delayed enforcement approach. More specifically, we noted our interest in whether commenters believed it would be more appropriate to require EHR technology to be certified to a subset of ICD-10; either ICD-9 or ICD-10; or to both ICD-9 and ICD-10 for encounter diagnoses and procedures. We also asked that commenters consider these options when reviewing and commenting on the other proposed certification criteria that include these standards (i.e., § 170.314(a)(3), (b)(2), and (e)(2)). For procedures, we proposed to continue to permit a choice for EHR technology certification, either ICD-10-PCS or the combination of Health Care Financing Administration Common Procedure Coding System (HCPCS) and Current Procedural Terminology, Fourth Edition (CPT-4). For outbound messages including laboratory tests, we stated that EHR technology must be capable of transmitting the tests performed in LOINC® 2.38 to meet this certification criterion and for all other proposed certification criteria that include the capability to transmit laboratory tests in the LOINC® 2.38 standard. We proposed to adopt the “view, download, and transmit to 3rd party” certification criterion at § 170.314(e)(1) and the ICD-10-PCS and ICD-10-CM standards for procedures and encounter diagnoses at § 170.207(b)(3) and (m), respectively. We received a significant amount of comments on the proposed view, download, and transmit to a 3rd party certification criterion. To make clear the policy expressed in our responses to comments, we have used subheadings under which specific comment themes will be discussed. In response to comments, we have made several revisions to the proposed certification criterion. Those revisions are explicitly noted in the applicable response. View Comments. Many commenters raised questions and concerns about the data we specified EHR technology would need to be capable of making viewable to a patient or their authorized representative. Some contended that the data exceeded those required for this use case and questioned the value of such data. Others pointed out that we did not have a consistent list of data between the “view” and “download” paragraphs. Commenters specifically called out “encounter diagnoses” as being inconsistently applied and raised concerns about our proposal to refer to ICD-10-CM. With respect to the vocabularies we proposed for procedures several commenters disagreed with our proposal to permit EHR technology to be certified to represent procedures in ICD-10-PCS. Overall, commenters suggested in one form or another that SNOMED CT® should be the sole clinical vocabulary for documentation because it would help better meet the information objectives for MU. They further stated that SNOMED CT® is most appropriate when data is to be represented for clinical purposes and clinical accuracy. Commenters also contended that ICD-10-PCS was an inappropriate standard to reference for the purposes of clinical data exchange and was best suited for billing diagnosis and billing purposes. Among those comments at least one commenter stated that SNOMED CT® should be an alternative vocabulary standard included in the final rule. Another commenter stated that permitting the use of ICD-10-PCS to represent procedures in a Consolidated CDA formatted document would unnecessarily limit the usefulness of the Consolidated CDA document. This commenter stated that SNOMED CT® was the appropriate reference terminology to use to encode procedures. Similarly, other commenters recommended we replace ICD-10-PCS with SNOMED CT® because they believed that ICD-10-PCS would be inappropriate to use to represent procedures. They contended that procedures need to address counseling, education, and specific interventions that are not managed with a billing vocabulary. Last, one commenter stated that we should adopt the American Dental Association's Current Dental Terminology (CDT) as a vocabulary to represent procedures. They reasoned that CDT is a named HIPAA standard for use in electronic administrative transactions for dental claims and that this is the standard vocabulary dentists use to represent procedures. Response. The data that is specified in this certification criterion was proposed to directly mirror the data that CMS proposed should be available for patients to view, download, and transmit to a 3rd party. Thus, we disagree that the data exceeds what is required for this use case. We have worked with CMS to align the data specified in this certification criterion. In that respect if there were any discrepancies we have corrected them. Additionally, as discussed earlier in this preamble we have revised this certification criterion to refer to the Common MU Data Set, which has significantly reduced the certification criterion's overall size and complexity. Further, we have removed “encounter diagnoses” from this certification criterion because it is no longer data that is minimally necessary to support what CMS has finalized for the objective and measure this certification criterion is designed to support. “Encounter diagnoses” is referenced by the transitions of care certification criterion (§ 170.314(b)(2)) and the data portability certification criterion (§ 170.314(b)(7)). Since the data portability certification criterion mirrors a portion of the transitions of care certification criterion, we have chosen to provide our response to comments on encounter diagnoses when we discuss the transitions of care certification criterion. In consideration of the comments we received in response to our questions about ICD-10-PCS, we agree with those commenters that argued SNOMED CT® is a more appropriate vocabulary to reference in this case. As commenters noted, SNOMED CT® is more appropriate for clinical purposes and provides greater clinical accuracy. Thus, this final rule requires that in order for EHR technology to be certified to a certification criterion that references “procedures” data, it must demonstrate compliance with the use of SNOMED CT® or CPT/HCPCS (the latter is already adopted as part of the 2011 Edition EHR certification criteria and was carried forward in the Proposed Rule). However, in recognition that it may be beneficial for inpatient EHR technology developers to demonstrate compliance with, and support for the use of, ICD-10-PCS to represent procedures in the various certification criteria that reference procedures, we have adopted ICD-10-PCS as an “optional” vocabulary standard to which EHR technology developers can seek certification for their EHR technology. In consideration of the comment suggesting that we include CDT as an alternative vocabulary for dentists, we have done so. However, we have adopted this vocabulary as “optional” and in addition to (not in lieu of) one of the primary vocabularies necessary for representing procedures data. Therefore, in the event that an EHR technology developer seeks to get its EHR technology certified to CDT, it will have to also be certified to one of the mandatory standards we have adopted for representing procedures, either SNOMED CT® or CPT/HCPCS. Comments. Commenters recommended that we delineate which data for view is optional as which data is required. Response. We decline to make this change. In order to be certified, EHR technology must be capable of permitting a patient or their authorized representative access to all of the data specified by the certification criterion. What information is actually made available by an EP, EH, or CAH and how it is displayed to a patient or their authorized representative should be determined by the EP, EH or CAH. Comments. Some commenters asked that we clarify that the term “gender” as proposed was really intended to mean “sex” given the wide range of characteristics that could be encompassed by the term gender. Response. We agree. Both ONC and CMS have included the term “sex” in our final rules. Comments. A commenter advocated that the substitution of patient friendly terms for diagnoses should be permitted. Response. We agree. We clarify and have modified the regulation text to explicitly indicate that for view (and download) that where certain coded data exists, the English language descriptions and not the codes should be viewable to a patient or their authorized representative. Comments. Commenters recommended that we include the additional flexibility of being able to import (save “as is”) and view CCD/C32 and CCR documents in order to provide a transition between Stages 1 and 2. They stated that as a patient if they viewed an old CCD it should still count towards the MU numerator. Response. We did not accept this recommendation and have not included this type of capability in the certification criterion. In large part, these comments are out of scope for this rulemaking and focus on measurement, which is relevant to the MU objective and measure with which this certification criterion correlates. That being said, the certification criterion does not specify how data is made viewable. Taking this approach is not necessarily precluded by the certification criterion and may somehow be able to address the view capability. However, we are uncertain, without additional details, whether the use of these older standard document formats would in practicality meet the numerator and denominator requirements for the MU measure or the new data required to be made viewable. Comment. A commenter requested that we provide detailed requirements to EHR technology developers on how to address potential language barriers in their products (especially with regard to the use of the patient portal). They stated that a language barrier would negatively impact providers' abilities to engage patients and get them to use the view, download, and transmit capabilities. They contended that it would be inconsistent to require patient engagement through the use of a patient portal and not provide common standards for multi-lingual or predominantly non-English speaking communities where providers might exclusively practice. Response. While we appreciate this commenter's suggestion and believe in the importance of multi-lingual accommodations, we believe this suggestion is a significant departure from the certification criterion proposed and would require additional study to determine how to appropriately frame it as a certification requirement for EHR technology. Thus, we have not changed the certification criterion in response to this comment. Comments. A commenter recommended that this certification criterion should include more specific capabilities than we proposed such as, accommodate patient generated data to “upload” into the EHR; include linkages to patient specific education materials; and be based upon a standing patient preference. Response. We did not accept this recommendation. We believe the certification criterion is properly scoped to support its correlated MU objective and measure and do not seek to introduce additional burden that could be value-added functionality outside the scope of certification that EHR technology developers can include for competitive purposes. Accessibility Comments. Commenters generally supported the underlying rationale behind the proposal, with some endorsing the requirement as proposed. Other commenters contended that achieving WCAG Level AA compliance in the time available would be extremely difficult for EHR developers to achieve. They stated that it is very complex to achieve compliance in a real world scenario and that Level AA conformance imposes a burden too great at this point in time. Further, they stated that the requirements for interfacing to independent accessibility tools (also required by WCAG 2.0), such as those that read screen text aloud can be impossible to achieve for “snappy” and “intelligent” JavaScript-dependent applications. One commenter noted that as of April 2012, two well-known news sites reported 76 and 104 known problems, respectively. Some commenters suggested removing this requirement altogether while others suggested that we take a more incremental approach and start with Level A conformance which could set the stage for a predictable progression to Level AA at a later date. Commenters also requested that we clarify that the WCAG standard would apply only to patient viewable information as intended by this certification criterion. Response. We appreciate commenters support for this proposal. As we noted in the proposed rule, we believe that all patients should have an equal opportunity to access their electronic health information without barriers or diminished functionality or quality. We recognize that this was a new requirement proposed for the 2014 Edition EHR certification criteria and in considering the burden concerns identified by commenters and need for greater experience with WCAG generally, we have decided to require Level A conformance instead of Level AA. As some commenters noted starting at Level A will provide a baseline from an accessibility perspective and one on which we can build in future rulemakings. Accordingly, we would like to express our intention to propose requiring Level AA in our next rulemaking cycle and encourage EHR technology developers to take the steps necessary to be on a path towards Level AA conformance. We also clarify, as requested, that the WCAG standards apply to the information that is viewable to the patient or their authorized representative through the capabilities EHR technology includes that would enable them to electronically view, download, and transmit their health information to a 3rd party. Comments. Comments stated that most patients want functions and content provided in a more visually appealing manner than the standard allows. Commenters requested that we clarify for certification whether an EHR technology developer would need to show how the product can be configured for WCAG 2.0 requirements by an implementer or whether the EHR technology must be “preconfigured” to those requirements (e.g. preset for font, contrast, color settings, etc). They stated, for example, that an EHR technology developer might have a configuration choice for accessibility that a consumer could opt for using that would include setting the contrast, font, color scheme, etc. to be conformant to accessibility requirements but allow other users to be able to select other settings as a matter of choice. They suggested that for certification it should be sufficient for an EHR technology developer to show how the settings for accessibility can be configured, but not predefined or [Text truncated at 120,000 characters. The full text is on the page linked above.] --- Source: Frix Law Library, https://www.frixlaw.com/law-library/documents/fr%3A2012-20982. Public record. Not legal advice.