# 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-4430 ## Record - **Collection:** Federal Register - **Document type:** Proposed Rule - **Published:** March 7, 2012 - **Citation:** 77 FR 13832 ## 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: Proposed rule. SUMMARY: Under section 3004 of the Public Health Service Act, the Secretary of Health and Human Services is proposing to revise the initial set of standards, implementation specifications, and certification criteria adopted in an interim final rule published on January 13, 2010, and a subsequent final rule that was published on July 28, 2010, as well as to adopt new standards, implementation specifications, and certification criteria. The proposed new and revised certification criteria would establish the technical capabilities and specify the related standards and implementation specifications that Certified Electronic Health Record (EHR) Technology would 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 notice of proposed rulemaking also proposes revisions to the permanent certification program for health information technology, which includes changing the program's name. DATES: To be assured consideration, written or electronic comments must be received at one of the addresses provided below, no later than 5 p.m. on May 7, 2012. ADDRESSES: You may submit comments, identified by RIN 0991-AB82, by any of the following methods (please do not submit duplicate comments). Because of staff and resource limitations, we cannot accept comments by facsimile (FAX) transmission. • Federal eRulemaking Portal: Follow the instructions for submitting comments. Attachments should be in Microsoft Word, Microsoft Excel, or Adobe PDF; however, we prefer Microsoft Word. http://www.regulations.gov. • Regular, Express, or Overnight Mail: Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, Attention: 2014 Edition EHR Standards and Certification Criteria Proposed Rule, Hubert H. Humphrey Building, Suite 729D, 200 Independence Ave. SW., Washington, DC 20201. Please submit one original and two copies. • Hand Delivery or Courier: Office of the National Coordinator for Health Information Technology, Attention: 2014 Edition EHR Standards and Certification Criteria Proposed Rule, Hubert H. Humphrey Building, Suite 729D, 200 Independence Ave. SW., Washington, DC 20201. Please submit one original and two copies. (Because access to the interior of the Hubert H. Humphrey Building is not readily available to persons without federal government identification, commenters are encouraged to leave their comments in the mail drop slots located in the main lobby of the building.) Enhancing the Public Comment Experience: To enhance the accessibility and ease with which the public may comment on this proposed rule, a copy will be made available in Microsoft Word format. We believe this version will make it easier for commenters to access and copy portions of the proposed rule for use in their individual comments. Additionally, a separate document will be made available for the public to use to provide comments on the proposed rule. This document is meant to provide the public with a simple and organized way to submit comments on the certification criteria and associated standards and implementation specifications and respond to specific questions posed in the preamble of the proposed rule. While use of this document is entirely voluntary, we encourage commenters to consider using the document in lieu of unstructured comments or to use it as an addendum to narrative cover pages. Because of the technical nature of this proposed rule, we believe that use of the document may facilitate our review and understanding of the comments received. The Microsoft Word version of the proposed rule and the document that can be used for providing comments can be found at http://www.regulations.gov as part of this proposed rule's docket and on ONC's Web site ( http://healthit.hhs.gov ). Inspection of Public Comments: All comments received before the close of the comment period will be available for public inspection, including any personally identifiable or confidential business information that is included in a comment. Please do not include anything in your comment submission that you do not wish to share with the general public. Such information includes, but is not limited to: A person's social security number; date of birth; driver's license number; state identification number or foreign country equivalent; passport number; financial account number; credit or debit card number; any personal health information; or any business information that could be considered proprietary. We will post all comments that are received before the close of the comment period at http://www.regulations.gov. Docket: For access to the docket to read background documents or comments received, go to http://www.regulations.gov or the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, Hubert H. Humphrey Building, Suite 729D, 200 Independence Ave. SW., Washington, DC 20201 (call ahead to the contact listed below to arrange for inspection). 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: Commonly Used Acronyms CAH Critical Access Hospital CDA Clinical Document Architecture CDS Clinical Decision Support CEHRT Certified EHR Technology 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-CM International Classification of Diseases, 10th Revision, Clinical Modification ICD-10-PCS International Classification of Diseases, 10th Revision, Procedure Coding System 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. Initial Set of Standards, Implementation Specifications, and Certification Criteria Interim Final and Final Rules 2. Medicare and Medicaid EHR Incentive Programs Stage 1 Proposed and Final Rules 3. HIT Certification Programs Proposed Rule and the Temporary and Permanent Certification Programs Final Rules III. Provisions of the Proposed Rule affecting Standards, Implementation Specifications and Certification Criteria A. 2014 Edition EHR Certification Criteria 1. Applicability 2. Scope of a Certification Criterion for Certification 3. Explanation and Revision of Terms Used in Certification Criteria 4. New Certification Criteria a. Ambulatory and Inpatient Setting b. Ambulatory Setting c. Inpatient Setting 5. Revised Certification Criteria a. Ambulatory and Inpatient Setting b. Ambulatory Setting c. Inpatient Setting 6. Unchanged Certification Criteria a. Refinements to Unchanged Certification Criteria b. Unchanged Certification Criteria Without Refinements 7. Gap Certification B. Redefining Certified EHR Technology and Related Terms 1. Proposed Revisions to the Definition of Certified EHR Technology 2. Base EHR 3. Complete EHR 4. Certifications Issued for Complete EHRs and EHR Modules 5. Adaptations of Certified Complete EHRs or Certified EHR Modules IV. Provisions of the Proposed 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. Base EHR Representation V. Request for Additional Comments A. Certification and Certification Criteria for Other Health Care Settings B. 2014 Edition EHR Accounting of Disclosures Certification Criterion C. Disability Status D. Data Portability E. EHR Technology Price Transparency VI. Response to Comments VII. Collection of Information Requirements VIII. Regulatory Impact Statement A. Statement of Need B. Overall Impact 1. 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 Costs Over a 3-Year Period iii. Costs for Reporting Test Results Hyperlinks b. Benefits 2. Regulatory Flexibility Act Analysis 3. Executive Order 13132—Federalism 4. 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. This proposed rule serves as the Secretary's publication of 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 adoption by the Secretary, under sections 3004(a)(3) and 3004(b)(3) of the PHSA, of the standards, implementation specifications, and certification criteria proposed in this rule would 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”) beginning with the EHR reporting periods in Federal fiscal year (FY) 2014 for EHs and CAHs and calendar year (CY) 2014 for EPs (hereafter referred to as “FY/CY 2014”). Consistent with Executive Order 13563, we have undertaken a retrospective review of our regulations. The proposed rule introduces multiple means for reducing regulatory burden and increasing regulatory flexibility for stakeholders, including proposed changes to current regulatory requirements and approaches. B. Summary of Major Provisions 1. Overview of the 2014 Edition EHR Certification Criteria We propose to adopt certification criteria that will support the proposed changes to the EHR Incentive Programs, including the new and revised objectives and measures for Stages 1 and 2 of MU proposed by CMS. The certification criteria we propose for adoption would also enhance care coordination, patient engagement, and the security, safety, and efficacy of EHR technology. For clarity, we refer to the certification criteria proposed for adoption as the 2014 Edition EHR certification criteria and the currently adopted certification criteria as the 2011 Edition EHR certification criteria. To permit efficient certification methods and reduce regulatory burden, we have identified those certification criteria that we propose to include in 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 would 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.7 of this preamble). 2. Certified EHR Technology Since the publication of the Standards and Certification Criteria final rule in July 2010, HHS has received significant feedback from stakeholders suggesting 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, this rule proposes to revise the definition of CEHRT. Of most significance, beginning with the EHR reporting periods in FY/CY 2014, we are proposing a revised definition of CEHRT that would provide more flexibility for EPs, EHs, and CAHs. In sum, in order to have EHR technology that meets the definition of CEHRT for FY and CY 2014 and subsequent years, EPs, EHs, and CAHs would be required to have a Base EHR (EHR technology that includes fundamental capabilities all providers would need to have) as well as the additional EHR technology necessary to meet the MU objectives and measures for the stage of MU that they seek to meet and to capture, calculate, and report clinical quality measures. We further discuss this proposal, including the concept of a “Base EHR” in section III.C (Redefining Certified EHR Technology and Related Terms). 3. ONC HIT Certification Program This rule proposes revisions to the permanent certification program which aim to 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 rule also proposes to revise the process for permitting the use of newer versions of “minimum standard” code sets. The proposed new approach seeks to reduce regulatory complexity and burden by providing the industry with the flexibility to quickly utilize newer versions of adopted “minimum standard” code sets. The rule proposes to modify the certification processes ONC-Authorized Certification Bodies (ONC-ACBs) would need to follow for certifying EHR Modules as a means of providing clear implementation direction and compliance with proposed new certification criteria, and also proposes to reduce 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 that must be a part of every EP's, EH's, and CAH's CEHRT. To increase clarity for the HIT market, we propose methods for clearly representing certified Complete EHRs and certified EHR Modules, including the representation of a “Base EHR.” Finally, we propose to require that test results used for the certification of EHR technology be available to the public in an effort to increase transparency around the certification process. C. Costs and Benefits We determined that this proposed rule is not an economically significant rule as its overall costs will be less than $100 million per year. We have, however, estimated the costs and benefits of the proposed rule. 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 proposed 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 proposed revised definition of CEHRT for FY/CY 2014. We assume this factor will cause a greater number of developers to prepare EHR technology for testing and certification towards the end of 2012 and throughout 2013, rather than in 2014. As a result, we believe, as represented in Table 1, that the costs attributable to this proposed rule will be distributed as follows: 40% for 2012, 50% for 2013, and 10% for 2014. The dollar amounts expressed in Table 1 are expressed in 2012 dollars. There are multiple potential benefits from the adoption of the proposed certification criteria in this rule. Foremost, EHR technology certified to the proposed certification criteria would be capable of supporting EPs, EHs, and CAHs' attempts to demonstrate MU under the EHR Incentive Programs. The certification criteria also 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. Proposals such as the revised definition of CEHRT, the availability of gap certification, and the proposed revisions to the permanent certification program, will, as noted, increase regulatory clarity, improve transparency, and add flexibility, while also reducing the regulatory burden on the HIT industry. Finally, we believe the proposals in this rule will support other initiatives, such as the Partnership for Patients. Table 1—Estimated Costs of the Proposed Rule: Distributed Total 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) Total average cost estimate ($M) 2012 40 36.80 95.01 65.91 2013 50 46.01 118.76 82.38 2014 10 9.20 23.75 16.48 3-Year Totals 92.01 237.52 167.53 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, while 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. Initial Set of Standards, Implementation Specifications, and Certification Criteria Interim Final and Final 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) (the “S&CC July 2010 final rule”). 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 “EHR Incentive Programs Stage 1 final rule”) (see 75 FR 44314 for more information about MU and the Stage 1 requirements). 2. Medicare and Medicaid EHR Incentive Programs Stage 1 Proposed and Final 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 EHR Incentive Programs 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. 3. HIT Certification Programs Proposed Rule and the Temporary and Permanent Certification Programs Final 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”). III. Provisions of the Proposed Rule Affecting Standards, Implementation Specifications, and Certification Criteria In the S&CC July 2010 final rule, the Secretary adopted certification criteria in title 45, part 170, §§ 170.302, 170.304, and 170.306 of the Code of Federal Regulations. To make a clear distinction between these previously adopted certification criteria and the ones discussed in this proposed rule, we will refer to 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” and propose to revise § 170.102 to add this definition. A. 2014 Edition EHR Certification Criteria This rule proposes 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 refer to these new, revised, and unchanged certification criteria as the “2014 Edition EHR certification criteria” and propose to add this term and its definition to § 170.102. Additionally, we propose to codify the 2014 Edition EHR certification criteria in section 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. This approach, coupled with our reference to the 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 we propose to include in the 2014 Edition EHR certification criteria. Further, we believe the inclusion of all 2014 Edition EHR certification criteria in one regulatory section will simplify the regulatory framework for stakeholders. Many of the certification criteria that we propose in this rule are intended to support the MU objectives and measures proposed in the CMS Medicare and Medicaid EHR Incentive Programs Stage 2 proposed rule (Stage 2 proposed rule) 1 as well as the reporting of MU objectives and measures and clinical quality measures (CQMs) to CMS. To the extent CMS may change (e.g., add, revise, or remove) MU objectives, measures, or reporting requirements in a final rule, we may also find it necessary or appropriate to change proposed supporting certification criteria. Commenters recommending changes to the proposed MU objectives and measures, CQMs, or reporting requirements should consider whether changes to the certification criteria would also be needed and offer those suggested changes. Similarly, commenters should consider and specify whether any of their suggested revisions to the proposed certification criteria would impact the proposals in CMS's Stage 2 proposed rule. 1 When we refer to CMS's Medicare and Medicaid EHR Incentive Programs Stage 2 proposed rule, we are referring to the NPRM published elsewhere in this issue of the Federal Register . We discuss the new, revised, and unchanged certification criteria that we propose to adopt as the 2014 Edition EHR certification criteria in sections A.4 through A.6 below. We specify where the proposed certification criteria would be included in § 170.314. We include a table at the beginning of the discussion of each certification criterion or criteria that specifies the MU objective that the proposed 2014 Edition EHR certification criterion or criteria and associated standards and implementation specifications support. The objective cited is either a proposed Stage 1 or Stage 2 objective that would be effective for the EHR reporting periods in FY/CY 2014. We provide this frame of reference because we propose that beginning in FY/CY 2014 EHR technology would need to be certified to the 2014 Edition EHR certification criteria to meet the definition of CEHRT and the table permits commenters to easily associate the certification criterion with the MU objective it supports. We provide the rationale for the proposed certification criteria, including citing the recommendations of the HITPC and HITSC, where appropriate. Last, in certain instances, we specifically request comment on the maturity and industry-acceptance of various standards and implementation specifications. 1. 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 propose to revise § 170.300 to reflect our proposed regulatory structure for the 2014 Edition EHR certification criteria. We propose 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 propose 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. 2. Scope of a Certification Criterion for Certification In the certification programs final rules (75 FR 36176, 76 FR 1290-91) and the S&CC July 2010 final rule (75 FR 44622), we clarified that a single certification criterion would encompass all of the specific capabilities referenced below the first paragraph level. As an example in the Permanent Certification Program final rule, we stated that the certification criterion at 45 CFR 170.302, paragraph “(f)” (the first paragraph level) identifies that the certification criterion relates to recording and charting vital signs. The certification criterion includes three specific capabilities at (f)(1), (2), and (3) (the second paragraph level): The ability to record, modify, and retrieve patients' vital signs; the ability to calculate body mass index (BMI); and the ability to plot and display growth charts. We stated that we viewed the entire set of specific capabilities required by paragraph “(f)” (namely, (f)(1), (2), and (3)) as one certification criterion, and that the specific capability to calculate BMI would not be equivalent to one certification criterion. Based on our proposal to codify all the 2014 Edition EHR certification criteria in § 170.314, we are clarifying that certification to the certification criteria at § 170.314 would occur at the second paragraph level of the regulatory section. The first paragraph level in § 170.314 would be used to organize the certification criteria into categories. These categories would be: 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, for this proposed rule, a certification criterion in § 170.314 would be 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). For example, we propose to adopt the revised certification criterion for demographics 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 in accordance with the standard specified in § 170.207(k). Consequently, to meet the proposed certification criterion for demographics, 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. 3. Explanation and Revision of Terms Used in Certification Criteria Certain terms are repeatedly used in the proposed 2014 Edition EHR certification criteria. Based on our experience and stakeholder feedback related to how terms in the 2011 Edition EHR certification criteria have been interpreted, we have determined that it is necessary in certain cases to select different terms. The following is a list of terms we repeatedly use in the proposed 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 further clarify 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 are replacing 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. 2 In certification criteria in which this term is used, 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. 2 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 are proposing 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 note 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 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 only propose 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 are proposing to replace the term “generate” used in the 2011 Edition EHR certification criteria with “create.” We believe “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. 4. New Certification Criteria In the Permanent Certification Program final rule (76 FR 1302), we described new certification criteria as those that specify capabilities for which the Secretary has not previously adopted certification criteria. We further stated that new certification criteria also include certification criteria that were previously adopted for Complete EHRs or EHR Modules designed for a specific setting and are subsequently adopted for Complete EHRs or EHR Modules designed for a different setting (for example, if the Secretary previously adopted a certification criterion only for Complete EHRs or EHR Modules designed for an ambulatory setting and then subsequently adopts that certification criterion for Complete EHRs or EHR Modules designed for an inpatient setting). Based on our experience trying to appropriately categorize the certification criteria we propose to be part of the 2014 Edition EHR certification criteria, we have determined that our description of new certification criteria needs to be clarified. Accordingly, we list below the 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. We propose to adopt new certification criteria that will support new MU objectives and associated measures, the reporting of MU measures, and will enable EHR technology to enhance patient engagement. Some of the new criteria would apply to both ambulatory and inpatient settings, while some certification criteria would only apply to one of the settings or would be new for a particular setting. a. Ambulatory and Inpatient Setting We propose to adopt 8 certification criteria that would be new certification criteria for both the ambulatory and inpatient settings. • Electronic notes MU Objective Record electronic notes in patient records. 2014 Edition EHR Certification Criterion § 170.314(a)(9) (Electronic notes) The HITSC recommended a certification criterion similar to the 2014 Edition EHR certification criterion we propose at § 170.314(a)(9) (with specific reference to “physician, physician assistant, or nurse practitioner” electronic notes) to support the MU objective and measure recommended by the HITPC. CMS has not proposed the MU objective and measure for Stage 2, but has requested public comment on whether the objective and measure should be incorporated into Stage 2. Consistent with our discussion in the preamble section titled “Explanation and Revision of Terms Used in Certification Criteria,” we have replaced the terms “modify” and “retrieve” in the recommended criterion with “change” and “access,” respectively. Additionally, we are providing the following clarifications for the electronic “search” capability. “Search” means the ability to search free text and data fields of electronic notes. It also means the ability to search the notes that any licensed health care professional has included within the EHR technology, including the ability to search for information across separate notes rather than just within notes. We believe that this certification criterion would encompass the necessary capabilities to support the performance of the MU objective and measure as discussed in the MU Stage 2 proposed rule. • Imaging MU Objective Imaging results and information are accessible through Certified EHR Technology. 2014 Edition EHR Certification Criterion § 170.314(a)(12) (Imaging) We propose to adopt the 2014 Edition EHR certification criterion at § 170.314(a)(12) to support the performance of the proposed MU objective and measure. We clarify that the phrase “immediate electronic access” is intended to mean that a user should be able to electronically access images and their narrative interpretations directly and without, for example, having to login to a separate electronic system or repository. This access could be provided by multiple means, including, but not limited to, “single sign-on” and “secure identity parameter passing.” We also note that there are data format standards for the transmission of imaging data (Digital Imaging and Communications in Medicine (DICOM)) that we reviewed for this certification criterion, but do not believe that the adoption of these standards is necessary to enable users to electronically access images and their narrative interpretations, as required by this certification criterion. We request public comment regarding whether there are appropriate and necessary standards and implementation specifications for this certification criterion. • 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 propose to adopt the 2014 Edition EHR certification criterion at § 170.314(a)(13) to support the performance of the proposed MU objective and measure. In defining family health history, this capability requires, at minimum, the ability to electronically record, change, and access the health history of a patient's first-degree relatives. As proposed in the Stage 2 proposed rule, a first degree relative is a family member who shares about 50 percent of their genes with a particular individual in a family (first degree relatives include parents, offspring, and siblings). We considered adopting specific standards for this certification criterion, including the HL7 Pedigree standard 3 and the use of Systematized Nomenclature of Medicine—Clinical Terms (SNOMED-CT®) 4 terms for familial conditions. We seek comments on the maturity and breadth of industry adoption of the HL7 Pedigree standard format for export and import of family health history and the use of SNOMED-CT® terms for familial conditions and their inclusion, where appropriate, on a patient's problem list. We also note that the Surgeon General has 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. 5 We seek 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. 4 http://www.nlm.nih.gov/research/umls/Snomed/snomed_main.html. 5 https://familyhistory.hhs.gov. • 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 propose to adopt the 2014 Edition EHR certification criterion at § 170.314(d)(4). Based on HITPC recommendations submitted to the National Coordinator on July 25, 2011, the HITSC recommended two versions of a draft 2014 Edition EHR certification criterion for amendments. As part of its recommendation, the HITPC (based on the work done by its Privacy and Security Tiger Team) noted that the technical capabilities included in a certification criterion should be “kept as simple as possible and evolve over time to greater complexity, including potentially greater standardization and automation.” The HITPC also recommended that this certification criterion be adopted to assist stakeholders by providing them with some of the technical tools to comply with parts of the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Privacy Rule requirements specified at 45 CFR 164.526. In addition, the HITPC considered issues related to “data integrity and quality when a clinician corrects errors that were not reported by the patient or needs to communicate updates to a patient's information.” We agree with the HITPC and HITSC recommendations, including that a certification criterion should be adopted that provides some of the basic technical tools necessary to comply with the HIPAA Privacy Rule. The proposed certification criterion does not address all of the requirements specified at 45 CFR 164.526 and we note that EHR technology certification is not a substitute for, or guarantee of, HIPAA Privacy Rule compliance. However, we believe that by adopting the proposed certification criterion, EPs, EHs, and CAHs would be provided some of the basic technical tools for compliance with 45 CFR 164.526. We specifically request 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. • 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) Standards § 170.204(a) (Web Content Accessibility Guidelines (WCAG) 2.0, Level AA Conformance); § 170.205(a)(3) (Consolidated CDA); § 170.205(j) (DICOM PS 3-2011); § 170.207(f) (OMB standards for the classification of federal data on race and ethnicity); § 170.207(j) (ISO 639-1:2002 (preferred language)); § 170.207(l) (smoking status types); § 170.207(a)(3) (SNOMED-CT® International Release January 2012); § 170.207(m) (ICD-10-CM); § 170.207(b)(2) (HCPCS and CPT-4) or § 170.207(b)(3) (ICD-10-PCS); § 170.207(g) (LOINC version 2.38); § 170.207(h) (RxNorm February 6, 2012 Release); § 170.202(a)(1) (Applicability Statement for Secure Health Transport) and § 170.202(a)(2) (XDR and XDM for Direct Messaging); and § 170.210(g) (synchronized clocks) The HITPC issued a 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 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 criteria, the criterion should replace the certification criteria previously adopted at §§ 170.304(f), 170.304(g), 170.306(d), and 170.306(e) because the new criterion encompassed the data elements required by these capabilities and was seen as a more efficient and effective means for patients to access their health information. We have made several refinements to the recommended certification criterion, while maintaining the critical elements recommended by the HITSC. In addition to the view and download capabilities recommended by the HITSC, we propose to include a third specific capability in this certification criterion—the ability to transmit a summary care record to a third party. Given that this objective is about making health information more accessible to patients and their caregivers, we believe that patients should have another option available to access their health information. We also believe that in certain cases patients may want to direct their health care provider(s) to transmit a copy of their electronic health information to another entity the patient might use for centralizing their health information (e.g., a personal health record). This additional capability is consistent with, and supports, the right of access standard at 45 CFR 164.524 of the HIPAA Privacy Rule as expanded by section 13405(e) of the HITECH Act with respect to covered entities that use or maintain an EHR on an individual. Section 13405(e) states that, in applying 45 CFR 164.524, an “individual shall have a right to obtain from [a HIPAA] covered entity a copy of such information in an electronic format and, if the individual chooses, to direct the covered entity to transmit such copy directly to an entity or person designated by the individual* * *.” Coupled with this addition, we have proposed that EHR technology would need to be capable of transmitting a summary care record according to both transport standards we propose to adopt. These transport standards include the two transport specifications developed under the Direct Project 6 : (1) Applicability Statement for Secure Health Transport 7 and (2) External Data Representation (XDR) and Cross-Enterprise Document Media Interchange (XDM) for Direct Messaging. 8 The Applicability Statement for Secure Health Transport specification describes how electronic health information can be securely transported using simple mail transport protocol (SMTP), Secure/Multipurpose Internet Mail Extensions (S/MIME), and X.509 certificates. The XDR and XDM for Direct Messaging specification describes the use of XDR and XDM as a means to transport electronic health information and serve as a bridge between entities using/following Web services and SMTP transport methods. We believe that these transport standards are ideal for these purposes and will make it possible for patients to transmit a copy of their summary care record to the destination of their choice. Additionally, because we have 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 summary care record” certification criterion, we have determined that it is not 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 believe that to include the 2011 Edition EHR certification criterion would be redundant and that our proposed approach more explicitly ties security to a particular transmission. 6 http://wiki.directproject.org/Documentation+Library. 7 http://wiki.directproject.org/Applicability+Statement+for+Secure+Health+Transport. 8 http://wiki.directproject.org/XDR+and+XDM+for+Direct+Messaging. At the recommendation of the HITSC, this proposed certification criterion requires 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 (i.e., record the user identification, the user's actions, and the health information viewed, downloaded, or transmitted) and make that information available to the patient. We have required this specific capability within this certification criterion because we believe that it is 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 propose to adopt at § 170.314(d)(2) due to the proposed policy change we specify in section IV.C.1 below related to EHR Modules and privacy and security. Thus, this express requirement guarantees 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 do 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 provide 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, 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 propose for the “patient accessible log” capability to require that the date and time each action occurs be recorded 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). These are final standards published by the Internet Engineering Task Force, a voluntary consensus standards body. Having correctly synchronized clocks is an information security best practice and the NTP, especially version 3, has been widely used and implemented since its publication in 1992. 9 RFC 5905 NTPv4 was published in 2010 10 and is backwards compatible with NTPv3. It does, however, include a modified protocol header to accommodate the Internet Protocol version 6 (IPv6) address family. For the same reasons we discuss here, we have included in the new certification criterion for electronic medication administration proposed for adoption at § 170.314(a)(17) and the auditing standard proposed for adoption at § 170.210(e) this same “synchronized clocks” standard because each includes a capability that requires date and time to be recorded. As a general best practice, we highly encourage and expect EHR technology developers that associate date and/or time with capabilities included in certification criteria not specifically mentioned here to utilize a system clock that has been synchronized following NTPv3 or NTPv4. Additionally, the HITSC recommended that we require as a condition of certification other privacy and security oriented capabilities such as single factor authentication and secure download. We did not include these additional capabilities in our proposals because we believe their technical implementations are commonplace and ubiquitous. Thus, there would seem to be little value added by requiring that these capabilities be demonstrated as a condition of certification. 9 http://www.ietf.org/rfc/rfc1305.txt. 10 http://www.ietf.org/rfc/rfc5905.txt. We propose to require EHR technology to be capable of enabling images formatted according to the Digital Imaging and Communications in Medicine (DICOM) standard 11 to be downloaded and transmitted to a third party. We believe 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. In fact, the National Institutes of Health has recently funded activities focused on personally controlled sharing of medical images 12 and published a solicitation notice on the same topic. 13 11 ftp://medical.nema.org/medical/dicom/2011/. 12 http://report.nih.gov/recovery/investmentreports/ViewARRAInvRpt.aspx?csid=211. 13 https://www.fbo.gov/index?s=opportunity&mode=form&id=ccb2340f4d8711b16f9e625b6b519371&tab=core&_cview=0 [solicitation #: NHLBI-CSB-EB-2012-5-RP]. We believe that all patients should have an equal opportunity to access their electronic health information without barriers or diminished functionality or quality. Thus, after consultation with the HHS Office for Civil Rights and HHS Office on Disability and reviewing the efforts of other Federal agencies, we propose that the viewing capability must meet Level AA conformance with the most recent set of the Web Content Accessibility Guidelines (WCAG). Federal agencies are considering, or proposing to adopt, WCAG 2.0 Level AA conformance for industries and technology they regulate. The Architectural and Transportation Barriers Compliance Board (Access Board) is considering applying WCAG 2.0 Level AA conformance to Federal agencies and telecommunications accessibility, which apply to telecommunication manufacturers. 14 The Department of Transportation is proposing to require WCAG 2.0 Level AA conformance for air carrier Web sites and airport kiosks. 15 14 76 FR 76640 (December 8, 2011). http://www.gpo.gov/fdsys/pkg/FR-2011-12-08/pdf/2011-31462.pdf#page=1. 15 76 FR 59307 (September 26, 2011). http://www.gpo.gov/fdsys/pkg/FR-2011-09-26/pdf/2011-24298.pdf. The WCAG were developed through an open process by the World Wide Web Consortium (W3C 16 ). 17 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. 18 Each guideline offers 3 levels of conformance: A, AA, and AAA. Level A conformance corresponds to the most basic requirements for displaying Web content. Level AA conformance provides for a stronger level of accessibility by requiring conformance with Level A success criteria as well as Level AA specific success criteria. Level AAA conformance comprises the highest level of accessibility within the WCAG guidelines and includes all Level A and Level AA success criteria as well as success criteria unique to Level AAA. We are proposing 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. For example, success criteria unique to Level AA include specifications of minimum contrast ratios for text and images of text, and a requirement that text can be resized without assistive technology up to 200 percent without loss of content or functionality. In addition to WCAG 2.0 Level AA conformance, we are interested in whether commenters believe additional standards are needed for certification to ensure accessibility for the viewing capability, such as the User Agent Accessibility Guidelines (UAAG). 19 Version 2.0 of the UAAG is designed to align with WCAG 2.0, but is currently only in draft form. 16 http://www.w3.org/Consortium/. 17 http://www.w3.org/WAI/intro/wcag. 18 http://www.w3.org/TR/WCAG20/. 19 http://www.w3.org/WAI/intro/uaag.php. The HITSC recommended that we move to one summary care record standard. We agree with this recommendation and believe that moving to one summary care record standard would lead to increased interoperability and spur innovation. The Consolidated CDA is 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 a summary care record that includes all of the data elements that CMS is proposing be available to be populated in a summary care record. Accordingly, we are proposing to require that EHR technology be capable of providing the information that CMS is proposing be required in a summary care record that is provided to patients or their authorized representatives. In certain instances in § 170.314(e)(1), we propose to require that the capability be demonstrated in accordance with the specified vocabulary standard. These vocabulary standards have been previously adopted or are proposed for adoption in this proposed rule consistent with the recommendations of the HITSC. With the exception of the four standards discussed below (LOINC, ICD-10-CM, ICD-10-PCS, and HCPCS), the vocabulary standards included in this certification criterion are discussed elsewhere in this preamble 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 propose the use of ICD-10 (ICD-10-CM and ICD-10-PCS, respectively). We request 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 are interested in whether commenters believe 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 ask 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 propose 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, 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 propose 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 at § 170.207(b)(3) and (m), respectively. In August 2011, we published an advance notice of proposed rulemaking (ANPRM) (76 FR 48769) to seek public comment on the metadata standards we could propose for adoption in this proposed rule. In the ANPRM, we stated: We are considering whether to propose, as a requirement for certification, that EHR technology be capable of applying the metadata standards in the context of the use case selected by the HIT Policy Committee (i.e., when a patient downloads a summary care record from a health care provider's EHR technology or requests for it to be transmitted to their PHR). For example, if a patient seeks to obtain an electronic copy of her health information, her doctor's EHR technology would have to be capable of creating a summary care record and subsequently assigning metadata to the summary care record before the patient receives it. We noted in the ANPRM that, after reviewing public comments, we would re-consider our proposals and use this proposed rule to seek further public comment on more specific proposals. Given our proposed adoption of solely the Consolidated CDA standard for summary care records and the fact that this standard requires EHR technology developers to follow the requirements specified in the “US Realm Header” (section 2.1 of the Consolidated CDA), which includes the metadata elements we were considering for patient identity and provenance, we do not believe that it would be necessary or prudent to propose separate metadata standards at this time. Accordingly, we believe that for the first use case we identified in the ANPRM our policy goals can be accomplished through the adoption of the Consolidated CDA standard. This approach also addresses the HITSC's recommendation for this certification criterion to include “data provenance” with any health information that is downloaded. Finally, consistent with public comments on the ANPRM, we are not proposing metadata standards for “privacy” and intend to continue to work with the industry to further flesh out what such metadata standards could be. However, we note that one of the metadata elements required by the US Realm Header is the ConfidentialityCode which should be populated with a value from the value set of BasicConfidentialityKind (this value set includes 3 possible values: “N” Normal, “R” Restricted, and “V” Very Restricted). We intend to continue to work with SDOs and other stakeholders on some of the HITSC recommendations discussed in the ANPRM relative to the CDA header. For example, we welcome comment on, and will consider moving from, the use of object identifiers (OIDs) to uniform resource identifiers (URIs). • Automated numerator recording MU Objective N/A 2014 Edition EHR Certification Criterion § 170.314(g)(1) (Automated numerator recording) To complement the “automated measure calculation” certification criterion adopted at § 170.302(n) (and now proposed for adoption as a revised certification criterion at § 170.314(g)(2)), we propose to adopt a 2014 Edition EHR certification criterion which would apply solely to EHR Modules that include capabilities for an MU objective with a percentage-based measure. This certification criterion would focus on the EHR Module's capability to automatically record the numerator for those measures. While a Complete EHR would need to be capable of meeting the automated measure calculation certification criterion which requires the capability to accurately calculate MU denominators, we do not believe that it would be practicable for an EHR Module to do the same because, in most cases, an EHR Module would likely be unable to record or have access to an accurate denominator, especially in the case where multiple certified EHR Modules are being used by an EP, EH, or CAH. That said, we believe that EHR Modules presented for certification to certification criteria that include capabilities for supporting an MU objective with a percentage-based measure should at least be able to readily and accurately record the numerator for those capabilities. Therefore, we propose to adopt this new certification criterion at § 170.314(g)(1). As noted, a Complete EHR would need to be certified to the proposed automated measure calculation criterion (§ 170.314(g)(2)). We would consider a Complete EHR certified to § 170.314(g)(2) as having met the proposed automated numerator recording certification criterion at § 170.314(g)(1) and, thus, there would be no need for the Complete EHR to be separately certified to § 170.314(g)(1). However, as discussed under section IV.C.2 of this preamble, EHR Modules that are presented for certification to certification criteria that include capabilities for supporting an MU objective with a percentage-based measure would need to be certified to this proposed certification criterion. This would not preclude an EHR Module from being certified to the automated measure calculation certification criterion if the EHR Module developer sought such certification. In such instances, similar to our stance on Complete EHR certification to § 170.314(g)(2), there would be no need for the EHR Module to be separately certified to § 170.314(g)(1). • Non-percentage-based measure use report MU Objective N/A 2014 Edition EHR Certification Criterion § 170.314(g)(3) (Non-percentage-based measure use report) Standard § 170.210(g) (synchronized clocks) To further complement the certification criteria proposed for adoption at § 170.314(g)(1) and (g)(2), we propose to adopt a new 2014 Edition EHR certification criterion at § 170.314(g)(3) which would apply to any EHR technology presented for certification that includes capabilities associated with MU objectives and measures that are not percentage based. This certification criterion would focus on a Complete EHR's or EHR Module's capability to record that a user had certain EHR technology capabilities enabled during an EHR reporting period and had used those capabilities to demonstrate MU. We also propose to require that the date and time be recorded according to the “synchronized clocks” standard that we explain in more detail in the preamble discussion of the new “view, download, and transmit to 3rd party” certification criterion proposed for adoption at § 170.314(e)(1). In consultation with CMS, we believe that EPs, EHs, and CAHs would benefit from this type of capability being required as a condition of certification. Additionally, we believe that such a capability could provide EPs, EHs, and CAHs with valuable evidence in the event of an MU audit. We propose that any EHR technology presented for certification to any one of the following certification criteria would need to be certified to this certification criterion. 170.314(a)(2) Drug-drug, drug-allergy interaction checks. 170.314(a)(8) Clinical decision support. 170.314(a)(10) Drug-formulary checks. 170.314(a)(14) Patient lists. 170.314(a)(17) Electronic medication administration record. 170.314(f)(2) Transmission to immunization registries. 170.314(f)(4) Transmission to public health agencies (surveillance). 170.314(f)(6) Transmission of reportable laboratory tests and values/results. 170.314(f)(8) Transmission to cancer registries. EHR technology that is presented for certification to any of these certification criteria would need to be able to record the date and time and enable a user to create a report that indicates when each capability was enabled and disabled, and/or executed. We intend for the term “executed” to apply only to the certification criteria in the table above except those proposed for adoption at § 170.314(a)(2) and (17). The MU measures associated with § 170.314(a)(2) and (17) require that the capabilities CEHRT include be “enabled” or “implemented” for an entire EHR reporting period. Moreover, they do not require unique action(s) by an EP, EH, or CAH. Last, we clarify that the privacy and security certification criteria proposed for adoption in § 170.314(d) which are associated with the MU objective “protect electronic health information created or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities” and measure which is not percentage based would not be included within the scope of this certification criterion. We do not believe that EHR technology would be able to capture that a security risk analysis was performed by an EP, EH, or CAH except through a manual entry by the EP, EH, or CAH affirming the completion of the risk analysis. • Safety-enhanced design MU Objective N/A 2014 Edition EHR Certification Criterion § 170.314(g)(4) (Safety-enhanced design) The International Organization for Standardization (ISO) defines usability as “[t]he extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use.” 20 Many industry stakeholders have acknowledged that a gap exists between optimal usability and the usability offered by some current EHR technologies. However, to date, little consensus has been reached on what might help close this gap and what role, if any, the Federal government should play related to the usability of EHR technology. In June 2011, the HITPC issued a report to ONC that explored the challenges associated with EHR technology usability and user-centered design (UCD). In its report, the HITPC identified certain “desired outcomes of improved usability” including improved safety and reduced cost, clinician frustration, training time, and cognitive load for clinical and non-clinical users alike. 20 ISO 9241-11. In November 2011, the Institute of Medicine (IOM) released a report titled “Health IT and Patient Safety: Building Safe Systems for Better Care,” in which the usability of EHR technology and quality management was often referenced. The IOM noted that “[w]hile many vendors already have some types of quality management principles and processes in place, not all vendors do and to what standard they are held is unknown.” Moreover, given this concern, the IOM recommended that “[t]he Secretary of HHS should specify the quality and risk management process requirements that health IT vendors must adopt, with a particular focus on human factors, safety culture, and usability.” We fundamentally agree with the sentiment expressed by both the HITPC and the IOM. As we consider the shared goals stated by stakeholders from all sides of this discussion, we believe that a significant first step toward improving overall usability is to focus on the process of UCD. While valid and reliable usability measurements exist, including those specified in NISTIR 7804 “Technical Evaluation, Testing and Validation of the Usability of Electronic Health Records,” 21 we are concerned that it would be inappropriate at this juncture for ONC to seek to measure EHR technology in this way. Recognizing that EHR technologies exist and are in use today, we have prioritized eight certification criteria 22 and associated capabilities to which this proposed certification criterion would require UCD to have been applied. We chose these eight because we believe they pose the greatest risk for patient harm and, therefore, the greatest immediate opportunity for error prevention and user experience improvement. We believe this approach limits this new certification criterion's potential burden while providing for a much needed focus on the application of UCD to medication-related certification criteria. 21 http://www.nist.gov/healthcare/usability. 22 § 170.314(a)(1) (CPOE); § 170.314(a)(2) (Drug-drug, drug-allergy interaction checks); § 170.314(a)(6) (Medication list); § 170.314(a)(7) (Medication allergy list); § 170.314(a)(8) (Clinical decision support); § 170.314(a)(17) (Electronic medication administration record); § 170.314(b)(3) (Electronic prescribing); and § 170.314(b)(4) (Clinical information reconciliation). The methods for how an EHR technology developer could employ UCD are well defined in documents and requirements such as ISO 9241-11, ISO 13407, ISO 16982, and NISTIR 7741. Presently, we believe it is best to enable EHR technology developers to choose their UCD approach and not to prescribe one or more specific UCD processes that would be required to meet this certification criterion. Thus, the use of any one of these processes to apply UCD would meet this certification criterion. Moreover, we acknowledge and expect that EHR technology developers who have already followed UCD in past development efforts for the identified certification criteria would be performing a retrospective analysis to document for the purposes of testing and certification that UCD had been applied to the specified certification criteria. However, if UCD had not been previously applied to capabilities associated with any of the certification criteria proposed, the EHR technology would ultimately need to have such UCD processes applied before it would be able to be certified. We propose to adopt this certification criterion at § 170.314(g)(4). If we adopt this certification criterion in a final rule, we anticipate that testing 23 to this certification criterion would entail EHR technology developers documenting that their UCD incorporates, in any form or format, all of the data elements defined in the Customized Common Industry Format Template for EHR Usability Testing (NISTIR 7742). We note that with respect to demonstrating compliance with this certification criterion that this information would need to be available to an ONC-ACB for review. This documentation would become a component of the publicly available testing results on which a certification is based (see section IV.D of this preamble for our proposal to make the test results used for certification publicly available). 23 The National Voluntary Laboratory Accreditation Program, as administered by NIST, is responsible for testing under the permanent certification program (“ONC HIT Certification Program”) (76 FR 1278). In addition to our proposed safety-enhanced design certification criterion, we request comment on two other safety-related certification criteria under consideration for adoption by the Secretary. Quality Systems The IOM also recommended that we “[establish] quality management principles and processes in health IT.” Working with other Federal agencies, we intend to publish a quality management document that is customized for the EHR technology development lifecycle and expresses similar principles to those included in ISO 9001, IEC 62304, ISO 13485, ISO 9001, and 21 CFR 820. The document would provide specific guidance to EHR technology developers on best practices in software design processes in a way that mirrors established quality management systems, but would be customized for the development of EHR technology. We understand that some EHR technology developers already have processes like these in place, but do not believe, especially in light of the IOM recommendation, that the EHR technology industry as a whole consistently follows such processes. We expect that this document would be published around the same time as this proposed rule and would be available for public comment. 24 Accordingly, we are considering including in the final rule an additional certification criterion that would require an EHR technology developer to document how their EHR technology development processes either align with, or deviate from, the quality management principles and processes that would be expressed in the document. We emphasize that this certification criterion would not require EHR technology developers to comply with all of the document's quality management principles and processes in order to be certified. Rather, to satisfy the certification criterion, EHR technology developers would need to review their current processes and document how they do or do not meet principles and processes specified in the document (and where they do not, what alternative processes they use, if any). We expect that this documentation would be submitted as part of testing and would become a component of the publicly available testing results on which a certification is based. 24 The quality management document will be published on ONC's Web site during the public comment period of this proposed rule and notice of its availability will be made through a notice published in the Federal Register . We are considering adopting this additional certification criterion as part of the 2014 Edition EHR certification criteria for three reasons. First, all EHR technology developers that seek certification of their EHR technology would become familiar with quality management processes. Second, the public disclosure of the quality management processes used by EHR technology developers would provide transparency to purchasers and stakeholders, which could inform and improve the development and certification of EHR technology. Last, EHR technology developers' compliance with the certification criterion would establish a foundation for the adoption of a more rigorous certification criterion for quality management processes in the future without placing a significant burden on developers. We request public comment on this additional certification criterion and the feasibility of requiring EHR technology developers to document their current processes. Patient Safety Events We are considering adopting a certification criterion (as mandatory or optional) that would require EHR technology to enable a user to generate a file in accordance with the data required by the Agency for Healthcare Research and Quality (AHRQ) Common Format, 25 including the “Device or Medical/Surgical Supply, including HIT v1.1a.” 26 The Common Formats are designed to capture information about patient safety events. In line with IOM's recommendations, we believe that requiring this capability for certification could be an essential first step in creating the infrastructure that would support the reporting of potential adverse events involving EHR technology to patient safety organizations (PSOs). We request public comment on whether we should adopt such a certification criterion and what, if any, challenges EHR technology developers would encounter in implementing this capability. 25 http://www.pso.ahrq.gov/formats/commonfmt.htm. 26 https://psoppc.org/web/patientsafety/ahrq-common-formats-device-or-medical/surgical-supply-including-hit-device. b. Ambulatory Setting We propose to adopt 3 certification criteria that would be new certification criteria for the ambulatory setting. • Secure messaging MU Objective Use secure electronic messaging to communicate with patients on relevant health information. 2014 Edition EHR Certification Criterion § 170.314(e)(3) (Ambulatory setting only—secure messaging) Standard § 170.210(f) The HITSC recommended two versions (based in large part on the work of the Implementation Workgroup and Privacy and Security Workgroup) of the 2014 Edition EHR certification criterion for secure messaging to support the MU objective and measure recommended by the HITPC, and now proposed by CMS. We agree with the direction provided by both recommendations and have merged the two into a refined certification criterion. We have also included what we believe should be the baseline standard in terms of encryption and hashing algorithms used to implement secure messaging. More specifically, we are proposing that only those identified in FIPS 140-2 Annex A be permitted to be used to meet this criterion. As such, we propose to adopt a new standard in § 170.210(f) to refer to FIPS 140-2 Annex A's encryption and hashing algorithms. Additionally, we are proposing, consistent with the HITSC's recommendations, that methods for meeting this certification criterion could include, but would not be limited to, designing EHR technology to meet the following standards: IETF RFC 2246 (TLS 1.0) and SMTP/SMIME as well as implementation specifications such as NIST Special Publication 800-52 (“Guidelines for the Selection and Use of TLS Implementations”) and specifications developed as part of nationwide health information network initiatives. We propose to adopt this new certification criterion at § 170.314(e)(3). • Cancer registry MU Objective Capability to identify and report cancer cases to a State cancer registry, except where prohibited, and in accordance with applicable law and practice. 2014 Edition EHR Certification Criteria § 170.314(f)(7) (Ambulatory setting only—cancer case information) § 170.314(f)(8) (Ambulatory setting only—transmission to cancer registries) Standards and Implementation Specifications § 170.205(i) (HL7 CDA, Release 2 and Implementation Guide for Healthcare Provider Reporting to Central Cancer Registries, Draft, February 2012); § 170.207(a)(3) (SNOMED CT® International Release January 2012); and § 170.207(g) (LOINC version 2.38) The HITPC provided recommendations that CMS consider requiring EPs to submit reportable cancer conditions. CMS has proposed this as a new objective and measure for EPs. We propose to adopt two new 2014 Edition EHR certification criteria to enable the performance of the objective and measure with the use of CEHRT. The proposed adoption of two criteria, one focused on the data capture and the other focused on the formatting and transmission of such data in the proposed standards is consistent with the HITSC recommendation to consider splitting the public health certification criteria in this manner. In consultation with the Centers for Disease Control and Prevention (CDC), we propose to adopt HL7 CDA, Release 2 as the content exchange standard. We also propose to adopt SNOMED CT® International Release January 2012 and LOINC version 2.38 as the vocabulary standards. Additionally, we propose to adopt the Implementation Guide for Healthcare Provider Reporting to Central Cancer Registries, Draft, February 2012. This implementation guide was jointly developed by the CDC and the North American Association of Central Cancer Registries (NAACCR) and is available at http://www.cdc.gov/ehrmeaningfuluse . CDC will consider comments received on this proposed rule in finalizing the guide. Assuming CDC finalizes the guide, we would consider adopting the final version of the guide in a final rule with consideration of public comment on the appropriateness of the guide for certification. We propose to adopt these certification criteria at § 170.314(f)(7) and (8). We propose to adopt the HL7 CDA standard and implementation guide at § 170.205(i). We propose to adopt SNOMED CT® International Release January 2012 and LOINC version 2.38 at § 170.207(a)(3) and (g), respectively. c. Inpatient Setting We propose to adopt 3 certification criteria that would be new certification criteria for the inpatient setting. • Electronic medication administration record MU Objective Automatically track medications from order to administration using assistive technologies in conjunction with an electronic medication administration record (eMAR). 2014 Edition EHR Certification Criterion § 170.314(a)(17) (Inpatient setting only—electronic medication administration record) Standard § 170.210(g) (synchronized clocks) The HITSC recommended a new 2014 Edition EHR certification criterion to support the MU objective and measure recommended by the HITPC, now proposed by CMS, for EHs and CAHs to automatically track medications from order to administration. We have refined the recommended certification criterion to clearly state the capabilities that must be tested and certified. The certification criterion continues to reflect the intent of the HITPC and HITSC, including the basic “rights” (right patient, right medication, right dose, right route, and right time). It is our intent, consistent with the HITSC's recommendation, to permit a range of acceptable technical solutions for certification. However, we wish to make clear that in order to demonstrate compliance with this certification criterion, EHR technology must enable a user to electronically confirm the “rights” in relation to the medication(s) to be administered in combination with an assistive technology (such as bar-coding, location tracking, and radio-frequency identification (RFID)) which provides automated information on the “rights.” An electronic “checklist” through which a user would manually confirm the “rights” without any automated and assistive feedback from EHR technology would not be sufficient to demonstrate compliance with this certification criterion. We believe this clarification and distinction are important because an electronic medication administration record together with some type of assistive technology has been shown to decrease medication errors 27 and it is not our intent to digitize a paper process that would not realize the safety benefits that could be provided with the use of an assistive technology. We propose to adopt this new certification criterion at § 170.314(a)(17) with inclusion of the “synchronized clocks” standard as discussed earlier in this preamble under the “view, download, and transmit to 3rd party” certification criterion. 27 Poon EG, Keohane CA, Yoon CS, et al. (2010) Effect of Bar-Code Technology on the Safety of Medication Administration New England Journal of Medicine 362:1698-1707. • Electronic prescribing MU Objective Generate and transmit permissible discharge prescriptions electronically (eRx). 2014 Edition EHR Certification Criterion § 170.314(b)(3) (Electronic prescribing) Standards § 170.205(b)(2) (NCPDP SCRIPT version 10.6) and § 170.207(h) (RxNorm February 6, 2012 Release) In response to the HITPC's recommendation for a new MU Stage 2 objective and measure for e-prescribing of discharge medications by EHs and CAHs (now proposed by CMS), the HITSC recommended a certification criterion for electronic prescribing of discharge medications. As part of the HITSC recommendation, it was recommended that we require as a condition of certification for the inpatient setting that certain HL7 standards be adopted for exchange within a legal entity. We did not accept this part of the recommendation because it is inconsistent with our approach of adopting standards for the electronic exchange of health information between different legal entities. We are proposing to adopt for the inpatient setting the same revised electronic prescribing certification criterion we propose to adopt for the ambulatory setting (i.e., we propose to adopt the certification criterion at § 170.314(b)(3) for both settings). We discuss this revised certification criterion in further detail under the ambulatory setting subsection of the revised certification criteria section of this preamble. • Transmission of electronic laboratory tests and values/results to ambulatory providers MU Objective Provide structured electronic laboratory results to eligible professionals. 2014 Edition EHR Certification Criterion § 170.314(b)(6) (Inpatient setting only—transmission of electronic laboratory tests and values/results to ambulatory providers) Standards and Implementation Specifications § 170.205(k) (HL7 2.5.1 and HL7 Version 2.5.1 Implementation Guide: Standards and Interoperability Framework Lab Results Interface, Release 1 (US Realm)); and § 170.207(g) (LOINC version 2.38) The HITSC recommended a new 2014 Edition EHR certification criterion to support the MU objective and measure recommended by the HITPC for EHs and CAHs to send electronic laboratory tests and values/results to eligible professionals. CMS has not proposed the MU objective and measure for Stage 2, but has requested public comment on whether the objective and measure should be incorporated into Stage 2. We have refined the recommended certification criterion, primarily to include the standards and implementation guide recommended by the HITSC and HITPC. The HITSC recommended that we consider requiring the Standards and Interoperability Framework Laboratory Results Interface Initiative (S&I Framework LRI). 28 The S&I Framework LRI was created to reduce the variability of ambulatory laboratory interfaces as well as reduce the cost and time to initiate new electronic laboratory tests and values/results interfaces between clinical labs and ambulatory EHR technology. The S&I Framework LRI focused on the identification of a consistent set of data content that would need to be exchanged when laboratory tests and values/results are electronically delivered. We believe that our proposal to require for certification that inpatient EHR technology be capable of creating for transmission laboratory tests and values/results formatted in accordance with the LRI specification could make it more cost effective for electronic laboratory results interfaces to be set up in an ambulatory setting (i.e., minimal additional configuration and little to no additional/custom mapping) and that the electronic exchange of laboratory tests and values/results would improve. 28 http://wiki.siframework.org/Lab+Results+Interface+%28LRI%29+Initiative. To further reduce costs and improve the electronic exchange of laboratory tests and values/results, we are building off the HITSC recommendation and are proposing to adopt a revised certification criterion for the ambulatory setting that would require EHR technology to be capable of incorporating laboratory tests and values/results according to the standards and implementation specifications discussed here, including the LRI implementation guide (see discussion of proposed § 170.314(b)(5) under the revised certification criteria section below). We are also proposing to adopt LOINC version 2.38 as the vocabulary standard. The HITPC recommended using LOINC where available and the HITSC expressed agreement with this approach during their deliberations. Moreover, the LRI implementation guide requires the use of LOINC for laboratory tests. With respect to testing and certification for this certification criterion, we expect, among other aspects, that inpatient EHR technology would need to demonstrate its compliance with the “Common Profile Component” and other required profiles included within the LRI implementation guide. We propose to adopt this new certification criteria for the 2014 Edition EHR certification criteria at § 170.314(b)(6). We propose to adopt the HL7 2.5.1 standard and LRI implementation guide at § 170.205(k), acknowledging that the LRI specification is currently undergoing HL7 balloting. We intend to continue to monitor its progress and anticipate that a completed specification will be available before we publish a final rule. We propose to adopt LOINC version 2.38 at § 170.207(g). 5. Revised Certification Criteria In the Permanent Certification Program final rule (76 FR 1302) we described revised certification criteria as certification criteria previously adopted by the Secretary that are modified to add, remove, or otherwise alter the specified capabilities and/or the standard(s) or implementation specification(s) referred to by the certification criteria. We also stated that revised certification criteria may also include certification criteria that were previously adopted as optional, but are subsequently adopted as mandatory. Again, based on our experience in trying to appropriately categorize the certification criteria we propose to be part of the 2014 Edition EHR certification criteria we have determined that our description of revised certification criteria needs to be refined. Accordingly, we list below the factors that we would consider when determining whether a certification criterion is “revised:” • The certification criterion includes changes to capabilities that were specified in the previously adopted certification criterion; • The certification criterion has a new mandatory capability that was not included in the previously adopted certification criterion; or • The certification criterion was previously adopted as “optional” for a particular setting and is subsequently adopted as “mandatory” for that setting. To clarify, in some cases, a certification criterion could be both “revised” and “new.” For example, a previously adopted certification criterion could have been adopted for only the ambulatory setting. Subsequently, we could revise the certification criterion by adding a new capability and making it mandatory for both the ambulatory and inpatient settings. Once adopted, the certification criterion would be “new” for the inpatient setting and “revised” for the ambulatory setting. We propose to adopt revised certification criteria that will support proposed revisions to MU objectives and measures and that will increase the interoperability, functionality, utility, safety, and security of EHR technology. a. Ambulatory and Inpatient Setting We propose to adopt the following revised certification criteria for both the ambulatory and inpatient settings. • Drug-drug, drug-allergy interaction checks MU Objective Implement drug-drug and drug-allergy interaction checks. 2014 Edition EHR Certification Criterion § 170.314(a)(2) (Drug-drug, drug-allergy interaction checks) The HITSC recommended a revised certification criterion for the 2014 Edition EHR certification criteria to eliminate the ability for EHR technology to permit users to adjust drug-allergy interaction checks and to provide additional clarity for the capabilities that EHR technology must demonstrate. The HITSC reasoned that it would be clinically inappropriate to allow users to adjust drug-allergy interaction checks. The HITSC also reasoned that clarity could be provided with additional revisions. The HITSC recommended replacing the term “real-time” with “before the order is executed.” The HITSC also recommended revising the language to specify that notifications should happen during CPOE. Additionally, the HITSC recommended specifying that the level of severity of the notifications is what can be adjusted. The HITSC also recommended limiting the ability to make adjustments to an identified set of users or available as a system administrative function. Last, the HITSC recommended that drug-allergy contraindications should be interpreted to include adverse reaction contraindications. We agree with all of the HITSC's recommendations. We have revised and refined the language of the HITSC's recommended certification criterion, but otherwise have included all the recommended capabilities. As to the phrase “identified set of users,” we clarify that the EHR technology must enable an EP, EH, and CAH to assign only certain users (e.g., system administrator) with the ability to adjust severity levels. In other certification criteria that use the phrase “identified set of users,” a similar principle would apply (i.e., assigning the capability to only certain users). We believe this revised language more clearly indicates the intent of the criterion. We propose to adopt this revised certification criterion at § 170.314(a)(2). • Demographics MU Objective Record the following demographics: preferred language; gender; race; ethnicity; date of birth; and for the inpatient setting only, date and preliminary cause of death in the event of mortality in the EH or CAH. 2014 Edition EHR Certification Criterion § 170.314(a)(3) (Demographics) Standards § 170.207(f)(OMB standards); § 170.207(j) (ISO 639-1:2002); and § 170.207(k) (ICD-10-CM ) The HITSC recommended that we adopt a revised “demographics” certification criterion that requires the use of ISO 639-1 as the vocabulary standard for preferred language. 29 We agree with the HITSC's recommendation because it appropriately limits the burden on EHR technology developers since the ISO 639-1 code set which uses an alpha-2 code for language names is roughly 40% that of the ISO 639-2 code set which uses an alpha-3 code. We also propose to adopt ICD-10-CM for recording the preliminary cause of death. We believe that the use of ICD-10-CM will permit additional specificity for this data element. As for the Office of Management and Budget (OMB) standards for the classification of federal data on race and ethnicity, we note that the standard for classifying federal data according to race and ethnicity requires that the option for selecting one or more racial designations be provided. The standard also permits the use of more than the minimum standard categories for race and ethnicity as long as the data can be aggregated to the minimum standard categories, which would be confirmed through the testing and certification processes. We also propose to clarify the reference to the adopted standard as the “Revisions to the Standards for the Classification of Federal Data on Race and Ethnicity,” which was issued on October 30, 1997, as referenced at § 170.207(f). Last, we propose to revise this criterion to require that EHR technology be capable of recording that a patient declined to specify his or her race, ethnicity, and/or preferred language. This proposed revision would ensure inclusion of such patients in the numerator of the MU percentage-based measure. We propose to adopt this revised certification criterion for the 2014 Edition EHR certification criteria at § 170.314(a)(3) and the proposed standards at § 170.207(j) and (k). 29 http://www.loc.gov/standards/iso639-2/php/code_list.php —Also note that The Library of Congress has been designated the ISO 639-2/RA for the purpose of processing requests for alpha-3 language codes comprising the International Standard. • Problem list MU Objective Maintain an up-to-date problem list of current and active diagnoses. 2014 Edition EHR Certification Criterion § 170.314(a)(5) (Problem list) Standards § 170.207(a)(3) (SNOMED CT® International Release January 2012) Consistent with our discussion in the preamble section titled “Explanation and Revision of Terms Used in Certification Criteria,” we have replaced the terms “modify” and “retrieve” in the recommended criterion with “change” and “access,” respectively. Further, consistent with the interpretation we provided in the S&CC July 2010 final rule, we are reiterating and clarifying that “ longitudinal care ” is used to mean over an extended period of time. For the ambulatory setting, this would be over multiple office visits. For the inpatient setting, this would be for the duration of an entire hospitalization, which would include the patient moving to different wards or units (e.g., emergency department, intensive care, and cardiology) within the hospital during the hospitalization. The HITSC suggested that we consider longitudinal care to cover multiple hospitalizations, but we believe this could be difficult to achieve and may not offer added value based on the duration of time between a patient's hospitalizations and the reason for the hospitalizations. To note, our clarification of the meaning of longitudinal care applies equally to its use in other certification criteria, such as “medication list” and “medication allergy list.” If we were to change our interpretation of longitudinal care as suggested by the HITSC, it would apply to these certification criteria as well and could constitute a change in the capabilities included in the criteria, which in turn would cause them to become revised certification criteria. We welcome comments on our interpretation of longitudinal care. We also welcome comments on whether a term other than “longitudinal care” could and should be used to express the capability required by this certification criterion and the other referenced certification criteria (“medication list” and “medication allergy list”). We understand that the longitudinal care description we use for the purposes of EHR technology certification may differ from the meaning that providers attribute to it, including the meaning given to it by the Longitudinal Coordination of Care Workgroup within the Standards and Interoperability Framework. 30 30 http://wiki.siframework.org/Longitudinal+Coordination+of+Care+WG. The HITSC recommended that we adopt the appropriate version of SNOMED CT® for the revised criterion. We have determined, and propose to adopt, the International Release January 2012 version of SNOMED CT.® This is the most recent version of the code set. 31 The HITSC also recommended that ICD-9-CM be replaced with ICD-10-CM. We agree that the use of ICD-9-CM should no longer be required due to the pending move to ICD-10-CM. However, we do not believe it would be appropriate to require the use of ICD-10-CM for problem lists. SNOMED CT® (and not ICD-10-CM) will be required for calculation of CQMs. Therefore, we propose that only SNOMED CT® is an appropriate standard for the recording of patient problems in a problem list. This does not, however, preclude the use of ICD-10-CM for the capture and/or transmission of encounter billing diagnoses. We propose to adopt this revised certification criterion for the 2014 Edition EHR certification criteria at § 170.314(a)(5) and the International Release January 2012 version of SNOMED CT® at § 170.207(a)(3). 31 http://www.nlm.nih.gov/research/umls/licensedcontent/snomedctfiles.html. • Clinical decision support MU Objective Use clinical decision support to improve performance on high-priority health conditions. 2014 Edition EHR Certification Criterion § 170.314(a)(8) (Clinical decision support) Standard § 170.204(b)(1) (HL7 Context-Aware Knowledge Retrieval (“Infobutton”) Standard, International Normative Edition 2010) The HITSC recommended a revised clinical decision support (CDS) certification criterion for the 2014 Edition EHR certification criteria. We have refined the recommended certification criterion to provide a clearer understanding of the capabilities that must be tested and certified and to provide greater flexibility to EHR technology developers in designing EHR technology to meet this proposed certification criterion. We also propose to require the use of the HL7 Context-Aware Knowledge Retrieval (“Infobutton”) Standard, International Normative Edition 2010, for retrieving diagnostic or therapeutic reference information and specifically require the use of CDS with the incorporation of a summary care record. We have replaced the term “clinical decision support rule” used in the 2011 Edition EHR certification criteria and the HITSC recommended criterion with the term “clinical decision support intervention” to better align with, and clearly allow for, the variety of decision support mechanisms available that help improve clinical performance and outcomes. A CDS intervention is not simply an alert, notification, or explicit care suggestion. Rather, it should be more broadly interpreted as the user-facing representation of evidence-based clinical guidance. Our goal in clarifying the nomenclature is to focus more on the representation of the guidance (the CDS intervention) that the EHR technology should offer to the user rather than prescribe the form of either the logical representation of the clinical guidance or how the intervention interacts with the user. Referential sources such as medical texts, primary research articles, and clinical practice guidelines have long been available in electronic form, but the means and manner of accessing them have historically been disconnected from the points in providers' patient care workflows when the immediate availability of the reference sources would optimize clinical decisions. Increasingly, these tools are being made available through links in EHRs, offering information at relevant points within the clinical workflow. The Infobutton standard has been in active use for several years with many reference content vendors now providing their products in this form, and we propose to adopt its most recent edition (International Normative Edition 2010) in order to enable a user to retrieve diagnostic or therapeutic reference information. The use of standard reference information retrieval formats will accelerate the delivery of content to providers and hospitals, and will enhance the flexibility of such implementations because these formats reduce the need to “hard wire” the content databases to installed EHR technology. This flexibility allows EPs, EHs, and CAHs more choices and easier migration across content providers, encouraging innovation and competitiveness among these content providers. We believe it is important for CDS interventions to be triggered when new information is incorporated into EHR technology as a result of a care transition. Therefore, we are proposing that EHR technology enable interventions to be triggered when the specified data elements are incorporated into a summary care record pursuant to the capability specified at § 170.314(b)(1) (transitions of care—incorporate summary care record). We are also considering whether EHR technology should be capable of importing or updating value sets for the expression of CDS vocabulary elements using the HL7 Common Terminology Services, Revision 1, standard. We request comment on industry readiness to adopt this standard and on the benefits it could provide if required as a part of this certification criterion. Consistent with the HITSC stated intent, for EHR technology to be certified to this criterion it must be capable of providing interventions and the reference resources in paragraph (a)(8)(ii)(A) of § 170.314 by leveraging each one or any combination of the patient-specific data elements listed in paragraphs (a)(8)(i) and (ii) of § 170.314 as well as one or any combination of the user context data points listed in paragraph (a)(8)(iii)(A) of § 170.314. EHR technology must also be capable of generating interventions automatically and electronically when a user is interacting with the EHR technology. Last, the HITSC recommended that the source attributes of suggested interventions be displayed or available for users. We agree that this capability is important, but believe further clarification is necessary regarding what types of information must be provided for EHR technology to meet this criterion. We believe that, at a minimum, a user should be able to review the: bibliographic citation (i.e., the clinical research/guideline) including publication; developer of the intervention (i.e., the person or entity who translated the intervention from a clinical guideline into electronic form, for example, Company XYZ or University ABC); funding source of the intervention development; and release and, if applicable, revision date of the intervention. The availability of this information will enable the user to fully evaluate the intervention. The availability of this information will also enhance the transparency of all CDS interventions, and thus improve their utility to healthcare professionals and patients. We propose to adopt this revised certification criterion at § 170.314(a)(8) and the Infobutton standard at § 170.204(b)(1). • Patient-specific education resources MU Objective Use clinically relevant information from Certified EHR Technology to identify patient-specific education resources and provide those resources to the patient. 2014 Edition EHR Certification Criterion § 170.314(a)(16) (Patient-specific education resources) Standard § 170.204(b)(1) (HL7 Context-Aware Knowledge Retrieval (Infobutton) Standard, International Normative Edition 2010) We propose to adopt a revised 2014 Edition EHR certification criterion that does not have the language “as well as provide such resources to the patient” at the end of the paragraph. This language is in the 2011 Edition EHR certification criterion, but is redundant of the capability expressed at the beginning of the paragraph. Additionally, we propose to adopt the HL7 Context-Aware Knowledge Retrieval (Infobutton) Standard, International Normative Edition 2010, as the required standard. Infobutton is being increasingly used by more providers to electronically identify and provide patient-specific education resources. Therefore, we believe it is appropriate now to require EHR technology to enable a user to identify and provide patient-specific education resources based on the specified data elements and in accordance with Infobutton. We propose to adopt this revised certification criterion at § 170.314(a)(16) and the Infobutton standard at § 170.204(b)(1). • Transitions of care MU Objective The EP, EH, or CAH who transitions their patient to another setting of care or provider of care or refers their patient to another provider of care should provide summary care record for each transition of care or referral. 2014 Edition EHR Certification Criteria § 170.314(b)(1) (Incorporate summary of care record) § 170.314(b)(2) (Create and transmit summary care record) Standards § 170.205(a)(3) (Consolidated CDA); § 170.207(f) (OMB standards for the classification of federal data on race and ethnicity); § 170.207(j) (ISO 639-1:2002 (preferred language)); § 170.207(l) (smoking status types); § 170.207(a)(3) (SNOMED-CT® International Release January 2012); § 170.207(m) (ICD-10-CM); § 170.207(b)(2) (HCPCS and CPT-4) or § 170.207(b)(3) (ICD-10-PCS); § 170.207(g) (LOINC version 2.38); § 170.207(h) (RxNorm February 6, 2012 Release); and § 170.202(a)(1) (Applicability Statement for Secure Health Transport); § 170.202(a)(2) (XDR and XDM for Direct Messaging); and § 170.202(a)(3) (SOAP-Based Secure Transport RTM version 1.0) The HITSC recommended a merged revised certification criterion for the 2014 Edition EHR certification criteria that would be generally applicable to both the ambulatory and inpatient settings, with a deviation based on the setting-specific information that would be included in the summary care record. We have made refinements to the recommended certification criterion. We believe that the criterion should be split into two separate certification criteria based on the capabilities required. We base this revision on stakeholder feedback received after the publication of the S&CC July 2010 final rule, which explained that (especially for inpatient settings) two different EHR technologies are sometimes used to perform the capabilities of incorporation and creation of a summary care record. Consequently, adopting two separate certification criteria provides developers greater flexibility for certification. The first proposed certification criterion would require EHR technology to be able to incorporate a summary care record formatted according to the Consolidated CDA, and the second certification criterion would require that EHR technology be capable of generating and transmitting a summary care record in accordance with the Consolidated CDA, with certain specified vocabulary standards, and two specified transport standards. For the same reasons we discussed for the new “view, download, and transmit to 3rd party” certification criterion (§ 170.314(e)(1)), we believe that adopting the Consolidated CDA for this certification criterion is advantageous since its template structure can accommodate the formatting of a summary care record that includes all of the data elements that CMS is proposing be available to be populated in a summary care record. We recognize that care plan, additional care team members, referring or transitioning provider's name and contact information as well as certain hospital discharge information are not explicitly required to be captured by separate certification criteria, unlike most other data elements included in the clinical summary. The ability to capture these data elements is both implicit and necessary to satisfy this certification criterion (as well as the other certification criteria that rely on the same data). Therefore, we considered, but have not proposed, adopting separate data capture certification criteria for each of these data elements in order to make it clear that they are required to be captured. We request public comment on whether in the final rule we should create separate certification criteria for all of these data elements. For certain other data elements in § 170.314(b)(2), we propose to require that the capability to provide the information be demonstrated in accordance with the specified vocabulary standard. These vocabulary standards have been previously adopted or are proposed for adoption in this proposed rule consistent with the recommendations of the HITSC. Additionally, we request public comment on whether we should require, as part of the “incorporate summary care record” certification criterion proposed at § 170.314(b)(1), that EHR technology be able to perform some type of demographic matching or verification between the patient in the EHR technology and the summary care record about to be incorporated. This would help prevent two different patients summary care records from being combined. As with the “view, download, and transmit to 3rd party” certification criterion, we are proposing that EHR technology be capable of transmitting a summary care record according to both the transport standards we propose to adopt to enable directed exchange. We believe the use of these standards is a critical first step in achieving a common means of transporting health information to support MU and future exchange needs. For this certification criterion, we also propose to adopt as an optional standard at § 170.202(a)(3) the SOAP-Based Secure Transport RTM version 1.0 32 which was developed under the nationwide health information network Exchange Initiative and to which we believe EHR technology should be able to be certified. We believe including this option provides added flexibility to those EPs, EHs, or CAHs that may seek to use EHR technology with the ability to transmit health information using SOAP as a transport standard in addition to SMTP to meet MU. While we would only permit EHR technology to be certified to these two transport standards, we intend to monitor innovation around transport and would consider including additional transport standards, such as a RESTful implementation, in this certification criterion. The inclusion of additional standards in this certification criterion would permit EHR technology to be certified to added transport standard(s) and could ultimately enable EPs, EHs, and CA [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-4430. Public record. Not legal advice.