# Voluntary 2015 Edition Electronic Health Record (EHR) Certification Criteria; Interoperability Updates and Regulatory Improvements > Briefs, arguments, decisions, and more. URL: https://www.frixlaw.com/law-library/documents/fr%3A2014-03959 ## Record - **Collection:** Federal Register - **Document type:** Proposed Rule - **Published:** February 26, 2014 - **Citation:** 79 FR 10880 ## Text DEPARTMENT OF HEALTH AND HUMAN SERVICES Office of the Secretary 45 CFR Part 170 RIN 0991-AB92 Voluntary 2015 Edition Electronic Health Record (EHR) Certification Criteria; Interoperability Updates and Regulatory Improvements AGENCY: Office of the National Coordinator for Health Information Technology (ONC), Department of Health and Human Services. ACTION: Notice of proposed rulemaking with comment period. SUMMARY: This notice of proposed rulemaking introduces the beginning of the Office of National Coordinator for Health Information Technology's (ONC's) more frequent approach to health information technology certification regulations. Under this approach ONC intends to update certification criteria editions every 12 to 18 months in order to provide smaller, more incremental regulatory changes and policy proposals. This approach gives stakeholders greater and earlier visibility into our regulatory direction before compliance is required, provides more time for public input on policy proposals under consideration for future rulemakings, and enables our certification processes to more quickly adopt newer industry standards that can enhance interoperability. The 2015 Edition EHR certification criteria proposed in this rule would be voluntary. No EHR technology developer who has certified its EHR technology to the 2014 Edition would need to recertify to the 2015 Edition in order for its customers to participate in the Medicare and Medicaid EHR Incentive Programs (EHR Incentive Programs). Furthermore, eligible professionals, eligible hospitals, and critical access hospitals that participate in the EHR Incentive Programs would not need to “upgrade” to EHR technology certified to 2015 Edition in order to have EHR technology that meets the Certified EHR Technology (CEHRT) definition. Instead, the 2015 Edition EHR certification criteria would accomplish three policy objectives: 1) They would enable a more efficient and effective response to stakeholder feedback; 2) they would incorporate “bug fixes” to improve on 2014 Edition EHR certification criteria in ways designed to make our rules clearer and easier to implement; and 3) they reference newer standards and implementation specifications that reflect our commitment to promoting innovation and enhancing interoperability. Specific revisions to the ONC HIT Certification Program are also included in this proposed rule. These proposals focus on: Improving regulatory clarity; simplifying the certification of EHR Modules that are designed for purposes other than achieving meaningful use; and discontinuing the use of the Complete EHR definition starting with the 2015 Edition. 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 April 28, 2014. ADDRESSES: You may submit comments, identified by RIN 0991-AB92, 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: 2015 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: 2015 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, 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. Roughly 30% of the public comments submitted to our 2014 Edition notice of proposed rulemaking used the provided template, which greatly assisted in our ability to rapidly process and more accurately categorize public comments. 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://www.healthit.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 CDC Centers for Disease Control and Prevention CDS Clinical Decision Support CEHRT Certified Electronic Health Record Technology CFR Code of Federal Regulations CHPL Certified Health Information Technology Product List CLIA Clinical Laboratory Improvement Amendments 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 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 IG Implementation Guide IHE Integrating the Healthcare Enterprise® LOINC® Logical Observation Identifiers Names and Codes MU Meaningful Use OMB Office of Management and Budget ONC Office of the National Coordinator for 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 Table of Contents I. Executive Summary A. Purpose of Regulatory Action B. Summary of Major Provisions 1. Overview of the 2015 Edition EHR Certification Criteria 2. 2017 Edition Rulemaking 3. ONC HIT Certification Program II. Background A. Statutory Basis 1. Standards, Implementation Specifications, and Certification Criteria 2. HIT Certification Programs B. Regulatory History 1. Standards, Implementation Specifications, and Certification Criteria Rules 2. Medicare and Medicaid EHR Incentive Programs Rules 3. ONC HIT Certification Programs Rules III. Provisions of the Proposed Rule Affecting Standards, Implementation Specifications, and Certification Criteria A. 2015 Edition EHR Certification Criteria B. 2014 Edition to 2015 Edition Equivalency Table C. Gap Certification Eligibility Table for 2015 Edition EHR Certification Criteria D. HIT Definitions 1. CEHRT and Base EHR Definitions 2. Complete EHR 3. Common MU Data Set 4. Cross-Referenced FDA Definitions IV. Provisions of the Proposed Rule Affecting the ONC HIT Certification Program A. Applicability B. Non-MU EHR Technology Certification C. ONC Regulations FAQ 28 1. MU EHR Modules 2. Complete EHRs D. Patient List Creation Certification Criteria E. ISO/IEC 17065 F. ONC Certification Mark G. “Certification Packages” for EHR Modules V. Other Topics for Consideration for the 2017 Edition Certification Criteria Rulemaking A. Additional Patient Data Collection B. Medication Allergy Coding C. Certification Policy for EHR Modules and Privacy and Security Certification Criteria D. Provider Directories E. Oral Liquid Medication Dosing F. Medication History G. Blue Button + H. 2D Barcoding I. Duplicate Patient Records J. Disaster Preparedness K. Certification of Other Types of HIT and for Specific Types of Health Care Settings 1. Other Types of HIT 2. Specific Types of Health Care Settings VI. Removal of the 2011 Edition EHR Certification Criteria and Related Standards, Terms, and Requirements and the Temporary Certification Program A. 2011 Edition EHR Certification Criteria B. Temporary Certification Program VII. Response to Comments VIII. Collection of Information Requirements IX. Regulatory Impact Statement A. Statement of Need B. Overall Impact 1. Executive Orders 12866 and 13563—Regulatory Planning and Review Analysis 2. Regulatory Flexibility Act 3. Executive Order 13132—Federalism 4. Unfunded Mandates Reform Act of 1995 C. Request for Comments on 2017 Impact Analysis Methods I. Executive Summary A. Purpose of Regulatory Action On December 6, 2013, CMS announced its intention 1 to pursue rulemaking to modify the start date of meaningful use (MU) Stage 3 for some eligible professionals (EPs), eligible hospitals (EHs), and critical access hospitals (CAHs). As part of this announcement, CMS and ONC also expressed an expectation that our joint rulemaking processes to establish Stage 3 policy and supporting EHR certification criteria would result in published proposed rules in late fall 2014. Given the new (and later than originally planned) regulatory timeline, we (ONC) determined that initiating a more frequent rulemaking approach for the adoption of certification criteria would provide an opportunity to respond to stakeholder concerns regarding our prior rulemakings. Along these lines, we believe a more frequent rulemaking approach would help address both the amount of time that it takes to publish updates to our certification regulations and the corresponding impact that the infrequent, long-cycle approach has had on EHR technology development and deployment. 1 http://www.cms.gov/eHealth/ListServ_Stage3Implementation.html , In the past, ONC has issued certification (program and criteria) regulations solely to support the EHR Incentive Programs. As a result, we have gained five years of process experience and stakeholder feedback. We have learned that as health information technology (HIT or health IT) continues to evolve, a two to three-year regulatory cycle is sub-optimal. Moreover, because these rulemakings have been less frequent, our regulations have had to take into account one to two years' worth of industry effort prior to the rulemaking and established policy that anticipates industry readiness one to two years post-rulemaking. This approach has created cycles of significant peaks and valleys from a health IT development standpoint; resulted in missed opportunities to improve interoperability and programmatic alignment because of mismatched regulatory and standards balloting cycle timelines; and adversely affected EHR technology developers' ability to strategically plan their development and product rollout processes due to uncertain regulatory timelines. To address these challenges, we believe that a more incremental, frequent, and scheduled approach to publishing proposed and final rules (that is, every 12 to 18 months) would benefit the industry. We anticipate, similar to this 2015 Edition rulemaking, that some of these incremental rules would be voluntary in an effort to intentionally give EHR technology developers more time to plan, develop, and implement updated EHR technology for their customers. Overall, we believe this approach will enable ONC to: (A) Adapt our regulations to more effectively and efficiently respond to stakeholder feedback and to support HHS healthcare delivery reform and transformation programs that may seek to leverage health IT certification; (B) Better our regulations by making “bug fixes” and other regulatory improvements as part of a more frequent rulemaking cycle; (C) Chart a course toward enhanced interoperability, information exchange, quality improvement, patient engagement, and patient safety that gives health IT developers more ability to predict ONC's potential next steps; and (D) Deliver smaller, incremental regulatory requirements that are easier to integrate into software development cycles. The 2015 Edition rulemaking begins ONC's new regulatory approach. The proposals for the 2015 Edition in this proposed rule improve on the 2014 Edition EHR certification criteria in numerous ways. Moreover, the proposed 2015 Edition EHR certification criteria would be voluntary. In other words, no EHR technology developer who has certified its EHR technology to the 2014 Edition would need to recertify to the 2015 Edition in order for its customers to participate in the EHR Incentive Programs. Correspondingly, eligible professionals (EPs), eligible hospitals (EHs), and critical access hospitals (CAHs) that participate in the EHR Incentive Programs would not need to “upgrade” to EHR technology certified to 2015 Edition in order to have EHR technology that meets the Certified EHR Technology definition nor to standards or implementation specifications included in the 2015 Edition. As a result, EHR technology developers and EPs, EHs, and CAHs would have the opportunity to move ahead to the 2015 Edition at their own pace and on their own terms. Proposed new capabilities, standards-based requirements, and public comment solicitations on potential future certification criteria also provide EHR technology developers with advance visibility and time to react to the potential requirements ONC is considering for our next planned rulemaking—the 2017 Edition certification criteria (which would be proposed to support meaningful use Stage 3 proposals). We believe the benefits of moving to the 2015 Edition for EHR technology developers and EPs, EHs, and CAHs would be three-fold: (1) The 2015 Edition EHR certification criteria (as proposed) include updated capabilities, standards, and implementation guides (IGs) designed to enhance interoperability; (2) Certain certification criteria changes in the 2015 Edition (as compared to the 2014 Edition and discussed in greater detail later) are designed to spur innovation, open new market opportunities, and provide more choices to EPs, EHs, and CAHs when it comes to electronic health information exchange. (3) EHR technology developers would be able to implement regulatory updates earlier than if we would have otherwise waited another year to propose them under the new rulemaking timeline for the 2017 Edition/MU Stage 3. Along those lines, EHR technology developers that seek 2015 Edition certifications for some or all capabilities may be able to seek “gap certification” for those capabilities if they remain unchanged as part of the eventual 2017 Edition. Thus, EHR technology developer resources and time investments could be more spread out and lead to greater efficiency and time saved through the certification process later on. We note, however, the availability and scope of gap certification for 2015 Edition certified products to the 2017 Edition is contingent both on the outcome of the 2017 Edition rulemaking and the discretion of ONC-ACBs. For further explanation and discussion of gap certification, please see section III.C. “Gap Certification Eligibility Table for 2015 Edition EHR Certification Criteria” of the preamble. B. Summary of Major Provisions 1. Overview of the 2015 Edition EHR Certification Criteria The proposed 2015 Edition EHR certification criteria include many improvements over the 2014 Edition EHR certification criteria ( note: hereafter, all certification criteria editions will simply be referred to by the edition year (e.g., 2015 Edition). Yet, they do not entirely overhaul the full suite of certification criteria. From a 2014 Edition perspective, we are proposing to adopt roughly 60% of the 2014 Edition EHR certification criteria without change as part of the 2015 Edition. The remaining certification criteria proposals for the 2015 Edition generally fall into four general categories: (1) Clarifying revisions —consisting of clarifying regulatory text revisions. These include updating a certification criterion to reflect guidance in an already-issued frequently asked question (FAQ); (2) Standards updates —to have a certification criterion reference a new standard or IG that has been published since the Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, 2014 Edition; Revisions to the Permanent Certification Program for Health Information Technology final rule (“2014 Edition Final Rule”) was published in September 2012 (77 FR 54163 Sept. 4, 2012). In these instances, we have considered the proposed standards consistent with the requirements of the National Technology Transfer and Advancement Act (NTTAA) of 1995 (15 U.S.C. 3701 et. seq.) and the Office of Management and Budget (OMB) Circular A-119, 2 to use, wherever practical, technical standards that are developed or adopted by voluntary consensus standards bodies to carry out policy objectives or activities, with certain exceptions. The NTTAA and OMB Circular A-119 provide exceptions to selecting only standards developed or adopted by voluntary consensus standards bodies, namely when doing so would be inconsistent with applicable law or otherwise impractical. In this proposed rule, we have proposed to adopt or refer to voluntary consensus standards, except for the following government-unique standards: The OMB Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity; the transport standards proposed in § 170.202; the standard that identifies the data elements referenced by clinical quality measures (§ 170.204(c)); and certain standards related to the protection of electronic health information identified in § 170.210. We are aware of no voluntary consensus standards that would serve as alternatives to these standards for the purposes that we have identified; 2 http://www.whitehouse.gov/omb/circulars_a119 . (3) Restructuring —to make the certification criteria clearer and to improve market opportunities for diverse stakeholders to get EHR technology certified. (4) New certification criteria proposals —consisting of a few new certification criteria that represent new functionality when compared to the 2014 Edition as well as some new certification criteria that are the result of splitting certain 2014 Edition certification criteria. 2. 2017 Edition Rulemaking To give the industry advance notice of potential proposals under consideration for future certification criteria editions and regulations (e.g., 2017 Edition), we solicit public comment on revisions we are considering to many existing certification criteria. That is, certification criteria that have been adopted as part of the 2014 Edition and proposed as part of the 2015 Edition. We include a separate preamble section that discusses and requests public comments on potential functionality and requirements for the 2017 Edition (“V. Other Topics for Consideration for the 2017 Edition Certification Criteria Rulemaking”). However, please note that although we will consider the comments we receive on these issues as we develop proposals for future rulemaking, we do not plan to respond to those comments in the final rule for the 2015 Edition that we expect will follow this proposed rule. 3. ONC HIT Certification Program We propose several modifications to the ONC HIT Certification Program's policies. We also solicit public comment on several important future program policy issues we intend to consider for our 2017 Edition rulemaking. We are proposing to simplify the certification of EHR Modules that are designed for purposes other than achieving meaningful use and to discontinue the “Complete EHR” certification concept, which would begin with the 2015 Edition. Every additional ONC HIT Certification Program proposal we have included focuses on clarifying regulatory text, updating existing program polices, and providing clarity for the market as it relates to EHR technology certified under the program. C. Costs and Benefits Our estimates indicate that this proposed rule is not an economically significant rule as its overall costs would be less than $100 million in any one 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 to be tested and certified in accordance with the 2015 Edition EHR certification criteria (and the standards and implementation specifications they include) are represented in monetary terms in Table 1 below. Because the 2015 Edition is not the baseline certification criteria edition required by the CEHRT definition (as the 2014 Edition is), and because we expect our next rulemaking to adopt a 2017 Edition would commence in late calendar year 2014 and conclude in 2015, we do not believe that a large number of EHR technology developers would seek to be tested and certified to the 2015 Edition. We estimate that development and preparation efforts to the 2015 Edition would be split evenly over calendar years 2014 and 2015 and would be confined to these years because, as noted, we expect to issue a 2017 Edition final rule in 2015 and expect that the majority of EHR development and preparation efforts at that time would shift towards meeting the 2017 Edition. The dollar amounts expressed in Table 1 are expressed in 2014 dollars. While we do not expect a majority of EHR technology developers to seek testing and certification to the 2015 Edition, it would still provide several significant benefits to patients, health care providers, and EHR technology developers. Our proposals incorporate stakeholder feedback on particular 2014 Edition issues identified as unnecessarily impeding innovation. Our proposed revisions also seek to continue to improve EHR technology's interoperability through the adoption of updated standards and implementation specifications. Furthermore, our proposal to separate the “content” and “transport” capabilities in the 2015 Edition “transitions of care” certification criterion (compared to the 2014 Edition version of that certification criterion) is aimed at significantly improving the market availability of electronic health information exchange services. Our proposed 2015 Edition “view, download, transmit to 3rd party” certification criterion includes a greater focus on enabling a patient to choose where they want to send their health information. We believe these proposed revisions would open new market opportunities for EPs, EHs, and CAHs to select best of breed products as well as reduce EHR technology developer burdens related to certification. Our proposals and requests for comment in this proposed rule also signal to the industry the future direction we hope to go in with our certification criteria and certification program. This advanced visibility can better assist EHR technology developers plan for the future. Table 1—Distributed Total Development and Preparation Costs for EHR Technology Developers (2-Year Period)—Totals Rounded Year Ratio (percent) Total low cost estimate ($M) Total high cost estimate ($M) Total average cost estimate ($M) 2014 50 9.82 46.63 28.23 2015 50 9.82 46.63 28.23 2-Year Totals 19.65 93.26 56.46 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 Public Health Service Act (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 The HITECH Act established two new Federal advisory committees, 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 for Health Information Technology (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. Main responsibilities of the HITSC include 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.” Overall, section 13201(b) of the HITECH Act requires that with respect to the development of standards and implementation specifications, the Director of the National Institute of Standards and Technology (NIST), in coordination with the HITSC, “shall support the establishment of a conformance testing infrastructure, including the development of technical test beds.” The HITECH Act also indicates that “[t]he development of this conformance testing infrastructure may include a program to accredit independent, non-Federal laboratories to perform testing.” B. Regulatory History 1. Standards, Implementation Specifications, and Certification Criteria Rules The Secretary issued an interim final rule with request for comments titled, “Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology” (75 FR 2014, Jan. 13, 2010) (the “S&CC January 2010 interim final rule”), which adopted an initial set of standards, implementation specifications, and certification criteria. After consideration of the public comments received on the S&CC January 2010 interim final rule, a final rule was issued to complete the adoption of the initial set of standards, implementation specifications, and certification criteria and realign them with the final objectives and measures established for meaningful use (MU) Stage 1 (formally titled: 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) and referred to as the “2011 Edition Final Rule”). The 2011 Edition Final Rule also established the first version of the Certified EHR Technology (CEHRT) definition. Subsequent to the 2011 Edition Final Rule (October 13, 2010), we issued an interim final rule with a request for comment to remove certain implementation specifications related to public health surveillance that had been previously adopted in the 2011 Edition Final Rule (75 FR 62686). The standards, implementation specifications, and certification criteria adopted by the Secretary in the 2011 Edition 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). Subsequently, the Secretary issued a notice of proposed rulemaking with request for comments titled “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” (77 FR 13832, March 7, 2012) (the “2014 Edition NPRM”), which proposed new and revised standards, implementation specifications, and certification criteria. After consideration of the public comments received on the 2014 Edition NPRM, a final rule was issued to adopt the 2014 Edition set of standards, implementation specifications, and certification criteria and realign them with the final objectives and measures established for MU Stage 2 as well as MU Stage 1 revisions (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; (77 FR 54163 Sept. 4, 2012) (the “2014 Edition Final Rule”). On December 7, 2012, an interim final rule with a request for comment was jointly issued by ONC and CMS to update certain standards that had been previously adopted in the 2014 Edition final rule, as well as add an alternative measure for MU Stage 2, correct the regulation text, and modify the case number threshold exemption policy for clinical quality measure reporting under the EHR Incentive Program (77 FR 72985). The standards, implementation specifications, and certification criteria adopted by the Secretary in the 2014 Edition final rule established the capabilities that CEHRT must include in order to, at a minimum, support the achievement of MU Stage 2 by EPs, EHs, and CAHs under the Medicare and Medicaid EHR Incentive Programs Stage 2 final rule (the “EHR Incentive Programs Stage 2 final rule”) (see 77 FR 53968 for more information about the MU Stage 2 requirements). On November 4th, 2013 the Secretary published an interim final rule with a request for comment, 2014 Edition Electronic Health Record Certification Criteria: Revision to the Definition of “Common Meaningful Use (MU) Data Set” (78 FR 65884), to make a minor revision to the Common MU Data Set definition. This revision was intended to allow more flexibility with respect to the representation of dental procedures data for EHR technology testing and certification. 2. Medicare and Medicaid EHR Incentive Programs Rules On January 13, 2010, CMS published the EHR Incentive Programs Stage 1 proposed rule (75 FR 1844). The rule proposed the criteria for Stage 1 of MU 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 2011 Edition 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. On March 7, 2012, CMS published the EHR Incentive Programs Stage 2 proposed rule (77 FR 13698). Subsequently, CMS published a final rule (77 FR 53968) for the EHR Incentive Programs on Sept. 4, 2012, simultaneously with the publication of the 2014 Edition final rule. The EHR Incentive Programs Stage 2 final rule established the objectives, associated measures, and other requirements that EPs, EHs, and CAHs must satisfy to demonstrate MU during Stage 2 as well as revised MU Stage 1. As described above in Section II.B.1, ONC and CMS jointly issued an interim final rule with a request for comment on December 7, 2012 (77 FR 72985). The interim final rule updates certain standards that had been previously adopted in the 2014 Edition final rule, adds an alternative measure for MU Stage 2, corrects the regulation text, and modifies the case number threshold exemption policy for clinical quality measure reporting under the EHR Incentive Program. 3. ONC HIT Certification Program 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”). On May 31, 2011, ONC published a proposed rule (76 FR 31272) titled “Permanent Certification Program for Health Information Technology; Revisions to ONC-Approved Accreditor Processes.” The rule proposed a process for addressing instances where the ONC-Approved Accreditor (ONC-AA) engaged in improper conduct or did not perform its responsibilities under the permanent certification program, addressed the status of ONC-Authorized Certification Bodies in instances where there may be a change in the accreditation organization serving as the ONC-AA, and clarified the responsibilities of the new ONC-AA. All these proposals were finalized in a final rule published on November 25, 2011 (76 FR 72636). The 2014 Edition Final Rule made changes to the permanent certification program. The final rule adopted a proposal to change the Permanent Certification Program's name to the “ONC HIT Certification Program,” revised the process for permitting the use of newer versions of “minimum standard” code sets, modified the certification processes ONC-Authorized Certification Bodies (ONC-ACBs) need to follow for certifying EHR Modules in a manner that provides clear implementation direction and compliance with the new certification criteria, and reduced regulatory burden by eliminating the certification requirement that every EHR Module be certified to the “privacy and security” certification criteria. III. Provisions of the Proposed Rule Affecting Standards, Implementation Specifications, and Certification Criteria A. 2015 Edition EHR Certification Criteria General Context This rule proposes new, revised, and unchanged certification criteria that would establish the technical capabilities and related standards and implementation specifications that could be implemented as part of an EP, EH, or CAH's CEHRT and their demonstration of either MU Stage 1 or MU Stage 2. We refer to these new, revised, and unchanged certification criteria as the “2015 Edition EHR certification criteria” or “2015 Edition” and propose to add this term and its definition to § 170.102. Additionally, we propose to codify the 2015 Edition EHR certification criteria in section 170.315 to set them apart and make it easier for stakeholders to quickly determine the certification criteria the 2015 Edition includes. We discuss the new, revised, and unchanged certification criteria that we propose to adopt as the 2015 Edition EHR certification criteria below. We specify where the proposed certification criteria would be included in § 170.315. We also propose a substantive revision to the 2014 Edition syndromic surveillance certification criterion adopted at § 170.314(f)(3). As we have in prior rulemakings, we include a table at the beginning of the discussion of each certification criterion or criteria that specifies the MU objective the proposed 2015 Edition EHR certification criterion or criteria supports. We also indicate in the table whether the criterion is “eligible” or “ineligible” for “gap certification” between the 2014 Edition and 2015 Edition under the ONC HIT Certification Program depending on whether it would be considered “unchanged” between editions. We provide accompanying rationale for the proposed certification criteria, including citing the recommendations of the HITPC and HITSC, where appropriate. In contrast to our prior rulemakings, we discuss each certification criterion in the chronological order in which it would appear in the Code of Federal Regulations. In other words, the preamble that follows will discuss the proposed certification criteria in § 170.315(a) first, then § 170.315(b), and so on. This approach is designed to improve the preamble's readability and the ease with which commenters can reference back to sections of the proposed rule's preamble when necessary. We propose, and readers should interpret, that the following terms used in proposed 2015 Edition EHR certification criteria have the same meanings we adopted in the 2014 Edition Final Rule (77 FR 54168-54169), in response to public comment: “user,” “record,” “change,” “access,” “incorporate,” “create,” “transmit.” Similarly, we propose that the scope of a 2015 Edition certification criterion is the same as the scope previously assigned to a 2014 Edition certification criterion (for further explanation, see the discussion at 77 FR 54168). That is, certification to proposed 2015 Edition EHR certification criteria at § 170.315 would occur at the second paragraph level of the regulatory section and encompass all paragraph levels below the second paragraph level. We also propose to continue to use the same specific descriptions for the different types of “data summaries” established in the 2014 Edition Final Rule (77 FR 54170-54171) for the proposed 2015 Edition EHR certification criteria (i.e., “export summary,” “transition of care/referral summary,” “ambulatory summary,” “inpatient summary,” and “clinical summary.” Applicability—§ 170.300 Section 170.300 establishes the applicability of subpart C—Certification Criteria for Health Information Technology. We propose to revise paragraph (d) of § 170.300 to add in a reference to § 170.315, which would clarify which specific capabilities within a certification criterion included in § 170.315 have general applicability (i.e., apply to both ambulatory and inpatient settings) or apply only to an inpatient setting or an ambulatory setting. • Computerized Provider Order Entry Section 3000 of the Public Health Service Act, as added by section 13101 of the HITECH Act, requires that computerized provider order entry (CPOE) capabilities be included in CEHRT. We included CPOE capabilities in the Base EHR definition, which is part of the CEHRT definition, under 45 CFR § 170.102. Within the 2011 and 2014 Editions, we adopted CPOE certification criteria that require EHR technology to be capable of performing CPOE for medication, laboratory, and radiology/imaging orders. Based on stakeholder feedback since the 2014 Edition Final Rule, we understand that this approach can prevent EHR technology developers from creating more efficient, provider-specific “adaptations” of EHR technology that support CPOE. 3 For example, a mobile adaptation of CPOE currently must include all of the capabilities listed in the 2014 Edition CPOE certification criterion (i.e., the adaptation must be capable of performing CPOE for each of the three types of orders (medication, laboratory and radiology/imaging)) even though the EHR technology developer's customers may only wish to use the mobile adaptation to enter medication orders away from the office. 3 Please see 77 FR 54267-68 for a discussion of adaptations. Similarly, we can understand why our approach to CPOE certification can be interpreted by some providers as inconsistent with the flexibility provided in the FY/CY 2014 CEHRT definition under § 170.102. For example, the MU Stage 2 CPOE objective for EPs includes three associated measures (one measure for each of the three types of orders) and exclusions for each of those three measures. An EP who could potentially meet an exclusion for one or two of the measures would still need to possess EHR technology certified to the 2014 Edition CPOE certification criterion (that is, CEHRT that includes CPOE capabilities for each of the three types of orders). Additionally, the MU Stage 1 CPOE objective for EPs does not include measures for laboratory and radiology orders, which means EPs attempting this objective also do not necessarily require these additional certified CPOE capabilities. For these reasons, we propose for the 2015 Edition to split the “computerized provider order entry” certification criterion into three separate certification criteria with each criterion focused on one of the three order types. Certification criteria focused on each order type would permit EHR technology developers to develop order-specific CPOE adaptations and provide EPs, EHs, and CAHs with significantly more implementation flexibility. If an EP expects to meet the MU exclusion for one or two of the MU measures (i.e., writing fewer than 100 of each order type during an EHR reporting period), they could choose to adopt EHR technology certified only to the 2015 Edition CPOE certification criterion for the order types reflected in the measure(s) they expect to demonstrate for MU. This approach would permit an EP to meet the Base EHR definition requirements and CEHRT definition without having to adopt EHR technology that includes certified CPOE capabilities they would not expect to use for MU. We caution, however, that the additional flexibility that this proposed approach enables also comes with potential risk for EPs who expect to qualify for one or more of the exclusions from the CPOE measures discussed above, but do not ultimately satisfy the exclusion criteria based on the number of orders written during an EHR reporting period. EPs who choose to possess EHR technology that is not certified for each of the three types of orders may risk not having EHR technology that meets the CEHRT definition if they ultimately fail to meet one or more MU exclusions. In most cases, we expect that EPs' scope of practice and the MU measures they need to meet will inform their decision (and corresponding responsibility) to adopt EHR technology certified to the now separately proposed CPOE capabilities. For example, a chiropractor may never or rarely place medication and laboratory orders and, thus, would not necessarily need EHR technology certified to the specific proposed CPOE certification criteria for those order capabilities. Conversely, an EP practicing obstetrics and gynecology may need EHR technology certified for all three CPOE order types. Overall, we emphasize that EHR technology developers need to be aware that this additional certification flexibility and subsequent certification decisions could have corresponding impacts on EPs who are ultimately responsible for ensuring that their EHR technology meets the CEHRT definition. The 2015 Edition “CPOE” certification criteria omit the “at a minimum” language included in the 2014 Edition and 2011 Edition CPOE certification criteria. This language was included in prior editions to indicate that EHR technology developers could include capabilities that support other types of orders. We believe this language is extraneous because we have consistently maintained that certification criteria (and certification in general) serve as minimum requirements or a baseline. As has always been the case, EHR technology developers may include capabilities in their EHR technology that go beyond all certification requirements. • Computerized Provider Order Entry—Medications MU Objective Use computerized provider order entry (CPOE) for medication, laboratory, and radiology orders directly entered by any licensed healthcare professional who can enter orders into the medical record per state, local and professional guidelines to create the first record of the order. 2015 Edition EHR Certification Criterion § 170.315(a)(1) (Computerized physician order entry—medications). Gap Certification Status Eligible. As discussed above, we propose to adopt a 2015 Edition CPOE certification criterion specific to medication ordering. This proposed criterion is structured substantially similar to the 2014 Edition version, except it does not reference laboratory and radiology/imaging orders. • Computerized Provider Order Entry—Laboratory MU Objective Use CPOE for medication, laboratory, and radiology orders directly entered by any licensed healthcare professional who can enter orders into the medical record per state, local and professional guidelines to create the first record of the order. 2015 Edition EHR Certification Criterion § 170.315(a)(2) (Computerized physician order entry—laboratory). Gap Certification Status Ineligible. The Clinical Laboratory Improvement Amendments (CLIA) of 1988 amended the Public Health Service Act and revised the federal program for certification and oversight of clinical laboratory testing. CLIA applies to all clinical laboratories in the United States (in addition to some international laboratories that receive specimens from the United States for specialized testing not available in the United States) that perform examinations of materials derived from the human body for the purpose of providing information for the diagnosis, prevention, or treatment of any disease or impairment of, or the assessment of the health of human beings. Certain CLIA requirements focus on the communication and receipt of test orders (under pre-analytic systems) and test results (under post-analytic systems) between an ordering provider and a clinical laboratory. Since the implementing regulations for CLIA were established at a time when paper was the dominant method of communication for laboratory orders and results (test requisitions and patient reports), the CLIA regulations governing these activities require each laboratory to establish and follow written policies and procedures for an ongoing mechanism to monitor, assess, and, when indicated, correct identified problems. As electronic methods for ordering and reporting clinical laboratory information become more prevalent and commonplace it is important to ensure that the intent of the CLIA regulations can be fully supported by EHR technology. This is especially important with regard to patient safety, the accurate, reliable ordering of clinical laboratory testing, and the accurate, reliable, and timely reporting of clinical laboratory test results. In light of the accelerating movement toward the electronic exchange of clinical information (including the transmission of laboratory orders and results), CMS issued guidance 4 to clarify specific sections of the CLIA regulations. This guidance specified that clinical laboratories should test and verify the accuracy and reliability of each interface to an EHR technology. Since there are thousands of EHR technologies implemented across provider organizations and each likely has more than one laboratory interface, the task of testing both orders and reporting interfaces can be expensive, labor intensive, and time consuming. Additionally, CLIA requires periodic review of these interfaces so this is not a one-time procedure. 4 http://www.cms.gov/Medicare/Provider-Enrollment-and-Certification/SurveyCertificationGenInfo/Downloads/SCLetter10-12.pdf. As a step toward addressing these issues, we propose to expand (compared to the 2014 Edition versions) the 2015 Edition certification criteria focused on the exchange of laboratory orders and results (§§ 170.315(a)(2) and (b)(4) and (5)). These revised 2015 Edition certification criteria propose certain CLIA-specific requirements and include updated laboratory exchange standards. CLIA-specific requirements have been included in the “electronic incorporation of lab results” standard at § 170.205(j)(2) and the “laboratory orders” standard at § 170.205(l)(1) and we reference these standards in the appropriate proposed certification criteria. Inclusion of CLIA-specific requirements and updated standards will allow for a more comprehensive evaluation of EHR technology's capabilities in regards to supporting compliance with the CLIA regulations. We believe, upon adoption of the 2015 Edition, it would be possible for CMS to issue additional guidance to further clarify how CLIA requirements related to ongoing interface testing could be met if EHR technology were to be certified to these more comprehensive 2015 Edition certification criteria. Accordingly, we propose a “CPOE—laboratory” certification criterion as well as “incorporate laboratory tests and values/results,” and “transmission of electronic laboratory tests and values/results to ambulatory providers” certification criteria (discussed later in this preamble) to include more comprehensive capabilities focused on ensuring EHR technology's ability to perform capabilities consistent with corresponding CLIA regulatory requirements. For the 2015 Edition “CPOE—laboratory” certification criterion, we propose to adopt, for the ambulatory setting, the HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Orders from EHR, Release 1-US Realm, Draft Standard for Trial Use, November 2013 (S&I Framework LOI). 5 Due to the absence of a consensus standard for the purpose of sending laboratory orders from EHRs to labs, this standard was developed in conjunction with laboratories representative of the industry, EHR technology developers, and provider stakeholders through an open consensus-based process under the Standards and Interoperability Framework (S&I Framework) and was balloted and approved through HL7, a standards development organization. We propose to adopt the S&I Framework LOI standard at § 170.205(l)(1). We also propose to require the use of, at a minimum, the version of Logical Observation Identifiers Names and Codes (LOINC®) adopted at § 170.207(c)(2) (version 2.40) as the vocabulary standard for laboratory orders. Last, we propose that laboratory orders must include all the information for a test requisition as specified at 42 CFR 493.1241(c)(1) through (c)(8). The use of these standards and compliance with these requirements should greatly improve the interoperability of laboratory orders sent from ambulatory EHR technology to a laboratory and laboratory compliance with CLIA. 5 http://www.hl7.org/special/committees/projman/searchableprojectindex.cfm?action=edit&ProjectNumber=922. • Computerized Provider Order Entry—Radiology/Imaging MU Objective Use CPOE for medication, laboratory, and radiology orders directly entered by any licensed healthcare professional who can enter orders into the medical record per state, local and professional guidelines to create the first record of the order. 2015 Edition EHR Certification Criterion § 170.315(a)(3) (Computerized physician order entry—radiology/imaging). Gap Certification Status Eligible. As discussed above, we propose to adopt a 2015 Edition CPOE certification criterion specific to radiology/imaging ordering. This proposed criterion is structured substantially similar to the 2014 Edition version, except it does not reference laboratory and medication orders. • Drug-Drug, Drug-Allergy Interaction Checks MU Objective Implement drug-drug and drug-allergy interaction checks. 2015 Edition EHR Certification Criterion § 170.315(a)(4) (Drug-drug, drug-allergy interaction checks). Gap Certification Status Eligible. We propose to adopt a 2015 Edition certification criterion that is the same as the 2014 Edition version. However, we do solicit public comment on several related issues. The 2014 Edition Drug-Drug, Drug-Allergy Interaction Checks certification criterion (45 CFR 170.314(a)(2)) requires EHR technology to be able to automatically and electronically indicate to a user any drug-drug and drug-allergy contraindications (“DDI/DAI”), where such contraindications are based on a patient's medication list and medication allergy list. The criterion further requires that such checks occur before a medication order is completed and acted upon during computerized provider order entry (CPOE). The criterion also requires that EHR technology certified to this criterion be able to adjust severity levels for drug-drug interaction checks and that such ability be limited to an identified set of users or available as a system administrative function. Because DDI/DAI checks are intended to identify potential medical errors before they occur, these checks can be valuable tools for improving patient safety and for improving overall health outcomes. In order for DDI/DAI checks to be effective, however, action must be taken in response to a notification. When health care providers ignore a notification for DDI/DAI, the very benefit that such checks provide is eliminated. Given the positive impact we believe DDI/DAI checks can have on patient safety, we are considering whether a future certification criterion edition could require DDI/DAI capable EHR technology to track user responses to DDI/DAI notifications (“response tracking”) and whether commenters believe this would be a positive potential step toward improving user experience with DDI/DAI checking. The purpose of including this type of capability in a certification criterion would be to equip health care providers with response data that they could use to improve their own performance and the safe use of their EHR technology. With such response tracking data, health professionals could analyze the notifications that are often ignored or missed and could work with clinicians to learn why they ignored or missed them. Understanding clinician decisions related to DDI/DAI notifications also can help health professionals make such notifications more effective, and potentially eliminate ineffective notification methods. This information also may be helpful for EHR technology developers as they design DDI/DAI checks and notifications. We therefore seek comment on whether we should consider adopting a certification criterion as part of a future edition of certification criteria that would require EHR technology to be able to track health professionals' responses to the DDI/DAI checks that are performed and whether such a capability should track if and when the health professional viewed, accepted, declined, ignored, overrode, or otherwise commented on the product of a DDI/DAI check. We also seek comment on who should be permitted to review the data collected by the DDI/DAI check tracking capability, who should be able to adjust its configuration settings, whether the data tracked should be limited in scope or specificity, and whether EHR technology should be able to track when an adverse event occurs for which a DDI/DAI check was missed or ignored. Last, we seek comment on whether a DDI/DAI tracking capability should only track inaction or responses related to certain drug-drug and drug-allergy reactions, such as only tracking DDI/DAI alerts that if missed or ignored would cause severe reactions in patients. We also seek comment on what factors, definitions, standards, or existing consensus should be considered in determining whether a likely DDI/DAI reaction should be considered severe. • Demographics MU Objective Record the following demographics: preferred language; sex; 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. 2015 Edition EHR Certification Criterion § 170.315(a)(5) (Demographics) Gap Certification Status Ineligible. We propose to adopt a 2015 Edition “demographics” certification criterion that revises the 2014 Edition version. Our two proposals for the 2015 Edition criterion address a new standard for recording preferred language and that EHR technology must be capable of enabling a user to electronically record, change, and access the date of death and the preliminary cause of death. Preliminary Cause of Death and Date of Death We propose to include in the 2015 Edition the capability to enable a user to electronically record, change, and access the “date of death” as a required capability that EHR technology designed for the inpatient setting must demonstrate. We previously included this capability as part of the 2011 Edition “demographics” certification criterion and inadvertently omitted it from the 2014 Edition. Thus, this change would more accurately track the data required by the meaningful use criteria. To note, this functionality would be in addition to the inclusion in the 2015 Edition “demographics” certification criterion of the same capability to enable a user to electronically record, change, and access “preliminary cause of death” in case of mortality as is included in the 2014 Edition “demographics” certification criterion. Preferred Language Based on specific HITSC recommendations, we adopted ISO 639-2 constrained by ISO 639-1 for recording preferred language in the 2014 Edition “demographics” certification criterion. More specifically, this means that EHR technology is required to be capable of using the alpha-3 codes of ISO 639-2 to represent the corresponding alpha-2 code in ISO-639-1. To provide further clarity, we issued FAQ 27 6 in which we stated that where both a bibliographic code and terminology code are present for a required ISO 639-2 language, EHR technology is expected to be capable of representing the language in accordance with the (T) terminology codes (ISO 639-2/T) for the purposes of certification. 6 http://www.healthit.gov/policy-researchers-implementers/27-question-10-12-027. After we issued FAQ 27, we issued FAQ 43 7 in which we acknowledge that our constrained approach to the use of ISO 639-2 unintentionally excluded multiple languages that are currently in use, such as sign language and Hmong. Additionally, ISO 639-2 is meant to support written languages, which may not be the language with which patients instinctively respond when asked for their preferred language. To improve this situation, we propose to adopt one of the following three options for the 2015 Edition “demographics” certification criterion: 7 http://www.healthit.gov/policy-researchers-implementers/43-question-11-13-043. Option 1: Adopt ISO 639-2 8 codes—in full—as part of certification to the 2015 Edition “demographics” certification criterion. We note, however, that as mentioned in FAQ 43, the ISO-639-2 standard was “intended for written languages primarily.” For instance, “Chinese” is represented by its official language, Mandarin, in the code list. This would not account for the commonly spoken Cantonese language/dialect or other spoken Chinese languages/dialects. As a result, EHR technology developers may find that particular spoken languages are not in all cases sufficiently supported by the constrained standard we adopted for 2014 Edition certification. We have proposed this option in our regulatory text and propose to adopt the full ISO-639-2 codes at § 170.207(g)(2). Note, to implement this proposal, we would have to modify the regulatory text hierarchy in § 170.207(g) to designate the standard referenced by the 2014 Edition version of this certification criterion at § 170.207(g) to be at § 170.207(g)(1). 8 http://www.loc.gov/standards/iso639-2/iso639-2ra.html Option 2: Adopt ISO 639-3. 9 We chose not to adopt ISO 639-3 as part of the 2014 Edition “demographics” certification criterion in response to one comment on our proposed 2014 Edition criterion because we believed it exceeded the baseline necessary for certification and we had insufficient stakeholder feedback. ISO 639-3 is a code set that aims to define three-letter identifiers for all known human languages. ISO 639-3 attempts to provide as complete an enumeration of languages as possible, including living, extinct, ancient, and constructed languages, whether major or minor, written or unwritten. We seek comment on its appropriateness as the baseline standard for recording preferred language as part of the 2015 Edition “demographics” certification criterion. 9 http://www-01.sil.org/iso639-3/ Option 3: Adopt Request for Comments (RFC) 5646. 10 RFC 5646 entitled “Tags for Identifying Languages, September 2009” is the coding system that is commonly used to encode languages on the web and is the most current RFC for this purpose and listed as a “best current practice.” The first part of the code relies on the shortest ISO-639 code for the language. That means a 2-character code if the language is specified in ISO 639-1 or a 3-character code from ISO 639-2 or -3, if the language is only listed in one of those two ISO codes. We are also aware that RFC 5646 supports dialects. 10 http://www.rfc-editor.org/info/rfc5646 We welcome comments on which standard should be required for recording preferred language as part of the 2015 Edition “demographics” certification criterion. Additionally, we propose in a later section of this rule that the chosen standard would also become the preferred language standard for the “Common MU Data Set” definition. Please see section III.D.3 “Common MU Data Set” of this preamble for further discussion of this associated proposal. • Vital Signs, Body Mass Index, and Growth Charts MU Objective Record and chart changes in the following vital signs: height/length and weight (no age limit); blood pressure (ages 3 and over); calculate and display body mass index (BMI); and plot and display growth charts for patients 0-20 years, including BMI. 2015 Edition EHR Certification Criterion § 170.315(a)(6) (Vital signs, body mass index, and growth charts) Gap Certification Status Eligible We propose to adopt a 2015 Edition certification criterion that is the same as the 2014 Edition version. However, we solicit public comment on the following issues. In the 2014 Edition Final Rule (77 FR 54203), we declined to revise the certification criterion at § 170.314(a)(4) in response to comments that recommended we require EHR technology to record vital signs in standardized vocabularies (e.g., LOINC, SNOMED CT, and UCUM). At the time, we believed that it was too complex and burdensome for technology developers to map workflows, templates, and forms used to capture vital signs to standardized vocabularies. We also expressed concern that such a requirement could cause EHR technology developers to map vital signs to a standardized terminology in one workflow but perhaps not others. We were concerned that such an approach could cause providers to be forced to use a given workflow, form, or template to achieve MU that is inconsistent with optimal workflow and usability. However, we noted that EHR technology developers would not be precluded from using standardized vocabularies to meet this 2014 Edition EHR certification criterion. We have continued to receive stakeholder feedback that we should consider adopting standardized vocabularies for recording vital signs (e.g., LOINC for observations). However, we have also received feedback that we should continue to allow flexibility in how vital signs are recorded. As a result, we solicit comment on whether we should adopt standardized vocabularies for recording vital signs (specifically, whether we should adopt LOINC (for observations), SNOMED CT (for qualitative results), and UCUM (for units of measure)) in this certification criterion for the 2017 Edition. In addition to these vocabularies, we also solicit comment on whether other vocabularies would be better for recording vital signs. In the 2014 Edition Final Rule, we stated that we intended to require that EHR technology be able to record all vital signs according to standardized technologies in the next EHR certification criteria edition (77 FR 54203). This was intended to be an incremental step toward interoperability at a more granular level. At the time of publication, we anticipated that the next certification criteria edition would be published with the MU Stage 3 rulemaking. However, given our modified approach to the rulemaking timeline discussed at the beginning of the preamble, we are using this intermediate 2015 Edition rulemaking to solicit more detailed comment on this issue to inform our policy decisions for the 2017 Edition. For recording vital signs, we are considering two different approaches: • Option 1 would be to require that EHR technology be able to record vital signs data natively using the aforementioned standards as part of the vital signs certification criterion. For the majority of our 2014 Edition certification criteria, we only require vocabulary standard(s) be used as part of a transmission rather than natively within the EHR. While it is not the norm, we have already set precedent for certain 2014 Edition certification criteria (e.g., smoking status) to require EHR technology to demonstrate the ability to natively record data in a particular standard as opposed to only having to apply that standard when data is exchanged. One potential benefit of this approach is that the standardized vocabularies are applied to the data as it is collected (e.g., to provide contextual information about the data to assist with interpretation). A downside, however, is that it could require more upfront work on the part of providers to capture the data in a standardized way and that certain local approaches to data collection may need to be discontinued. • Option 2 would be to require that EHR technology be able to represent such data in the aforementioned standards in any certification criterion that references vital signs when such data would be exchanged . For example, when exchanging a summary care record, the EHR technology would need to ensure blood pressure is represented in the CCDA formatted summary care record in the appropriate standard. Presumably, this option would be less burdensome on providers. It would also continue to allow them to collect vitals in local and non-standardized ways within their own EHR technology. However, it could also result in lost precision regarding the context associated with the vitals recorded. Last, additional feedback we have received from stakeholders indicated that if we were to pursue option 2, we would be best served to require EHR technology to record additional metadata related to the context around how the vital signs were collected. Stakeholders indicated that this additional information would provide context and comparability for the data if a standard vocabulary is not used when the data is recorded. For recording vitals, it is our understanding that unless particular contextual information associated with data collection is captured locally, data may be misinterpreted by a receiving party. Without certain kinds of contextual information, vitals data cannot be cross-walked or coded correctly. For example, a single blood pressure measurement may not represent a patient's true blood pressure. In older patients, the American Heart Association (AHA) 11 recommends taking the patient's blood pressure twice while standing, recording the average of the two, and then taking the patient's blood pressure twice while sitting and using the sitting average as the final reading. The standing average is to be used as a reference point only. If this information (e.g., whether the patient was sitting or standing, if the measure is the first, second, or average) is not recorded in the EHR along with the blood pressure measurement itself, the readings may not be correctly understood by a receiving party, such as another provider or caregiver. Therefore, we are also soliciting comment on whether we should prioritize our attention toward making sure EHR technology can capture this kind of contextual information or other metadata and what kinds of data would be best or most helpful for EHR technology certification to require. Please note we are not proposing that blood pressure must be recorded according to the AHA's recommendations. Rather, we use their recommendations to illustrate how contextual information about vital signs may be important to prevent misinterpretation. Finally, we solicit comments on whether vocabularies (and other metadata) are sufficient for the reuse of more granular data elements and whether continued work through initiatives (e.g., the Clinical Information Modeling Initiative (CIMI), Fast Health Interoperable Resources (FHIR)) to support capturing clinical entity models or other approaches for representing more granular data elements is needed. 11 New AHA Recommendations for Blood Pressure Measurement. Am Fam Physician. 2005 Oct 1;72(7):1391-1398. • Problem List MU Objective Maintain an up-to-date problem list of current and active diagnoses. 2015 Edition EHR Certification Criterion § 170.315(a)(7) (Problem list) Gap Certification Status Eligible We propose to adopt a 2015 Edition certification criterion that is the same as the 2014 Edition version. • Medication List MU Objective Maintain active medication list. 2015 Edition EHR Certification Criterion § 170.315(a)(8) (Medication list) Gap Certification Status Eligible We propose to adopt a 2015 Edition EHR certification criterion that is the same as the 2014 Edition version. • Medication Allergy List MU Objective Maintain active medication allergy list. 2015 Edition EHR Certification Criterion § 170.315(a)(9) (Medication allergy list) Gap Certification Status Eligible We propose to adopt a 2015 Edition certification criterion that is the same as the 2014 Edition version. • Clinical Decision Support MU Objective Use clinical decision support to improve performance on high-priority health conditions. 2015 Edition EHR Certification Criterion § 170.315(a)(10) (Clinical decision support) Gap Certification Status Ineligible We propose to adopt a 2015 Edition certification criterion that revises the 2014 Edition version in several ways. The 2014 Edition EHR certification criterion for CDS (§ 170.314(a)(8)) requires EHR technology to perform certain capabilities based on “demographics” data. Since the 2014 Edition Final Rule's publication, we have received many clarifying questions on whether EHR technology presented for certification must demonstrate the capability to use more than one of the demographics data categories listed in the “Demographics” certification criterion adopted at § 170.314(a)(3). Similar to the proposed 2015 Edition “Patient List Creation” certification criterion's modification of the 2014 Edition version, we are also proposing to adopt a 2015 Edition CDS certification criterion that incorporates the guidance we provided in FAQ 39. 12 Specifically, the text of the 2015 Edition “CDS” certification criterion provides that EHR technology must demonstrate the capability to use at least one of the more specific data categories included in the “demographics” certification criterion (45 CFR 170.315(a)(5)) (e.g., sex or date of birth). 12 http://www.healthit.gov/policy-researchers-implementers/39-question-04-13-039. The 2014 Edition EHR certification criterion for CDS also requires EHR technology to provide Infobutton 13 -enabled diagnostic and therapeutic reference information (§ 170.314(a)(8)(ii)(2)) in accordance with one of the Infobutton implementation specifications at § 170.204(b)(1) or § 170.204(b)(2). Since the 2014 Edition Final Rule's publication, we received clarifying feedback that the Infobutton standard does not support vital signs and medication allergies data for linked referential CDS and subsequently issued FAQ 34 14 to clarify how 2014 Edition testing and certification would handle this limitation. 15 As a result, we propose that the 2015 Edition CDS certification criterion will not require compliance with the Infobutton-enabled capability for vital signs nor medication allergies data. We also propose to discontinue referencing “laboratory values/results” data as we understand from stakeholder feedback that the Infobutton standard cannot support this specific data. Further, we propose to adopt the HL7 Implementation Guide: Service-Oriented Architecture Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain, Release 1, August 2013 (at § 170.204(b)(3)) in place of the older version referenced by the 2014 Edition certification criterion. 13 “Infobutton” is typically the shorthand name used to refer to the formal standard's name: HL7 Version 3 Standard: Context-Aware Retrieval Application (Infobutton). 14 http://www.healthit.gov/policy-researchers-implementers/34-question-12-12-034. 15 http://www.healthit.gov/policy-researchers-implementers/34-question-12-12-034. Health eDecisions Proposal Launched in June 2012, an ONC Standards & Interoperability Framework initiative known as Health eDecisions (HeD) focused on defining and harmonizing standards that could facilitate the emergence of systems and services for shareable CDS. Since that time, the HeD Working Group has developed two use cases with functional requirements, defined and balloted relevant standards, developed IGs, and is in the process of conducting pilots and performing data collection for analysis. HeD use case (UC) 1 defines the functional requirements needed to build a standard schema for the contents of three “CDS Knowledge Artifact” 16 types: event condition action (ECA) rules, order sets, and documentation templates. 17 UC 1 is based on the scenario of a “CDS Knowledge Artifact supplier” making a computable CDS Knowledge Artifact available to a “CDS Artifact integrator.” The HeD Working Group created the HL7 Implementation Guide: Clinical Decision Support Knowledge Artifact Implementation Guide, Release 1 (January 2013) (“HeD standard”) 18 as a companion document for the CDS Knowledge Artifact schema (described in the HeD standard IG). The HeD standard includes additional background, contextual information, and detailed documentation and guidance to support schema implementation. 19 Overall, implementation of the HeD standard would greatly assist the industry in producing and sharing machine readable files for representations of clinical guidance. 16 A CDS Knowledge Artifact is the encoding of structured CDS content as a rule to support clinical decision making in many areas of the health care system, including quality and utilization measures, disease outbreaks, comparative effectiveness analysis, efficacy of drug treatments, and monitoring health trends. 17 HL7 Implementation Guide: Clinical Decision Support Knowledge Artifact Implementation Guide, Release 1 (January 2013) (“HeD standard”). 18 http://wiki.siframework.org/file/detail/implementation_guide_working_final_042413_lse_uploaded-1.docx. 19 Background documents and implementation guides can be found at http://wiki.siframework.org/Health+eDecisions+Homepage. HeD UC 2 defines the interface requirements needed to send patient data and receive CDS guidance based on one scenario: a request for clinical guidance made to a CDS guidance supplier. 20 The HeD Working Group considered the following interactions with a CDS guidance supplier: drug dosing calculation; immunization forecasting; disease management; quality measure evaluation; transition of care support; prediction rule evaluation (e.g., APACHE score, AHRQ Pneumonia Severity Index); and severity of illness assessment (e.g., Charlson Index). The HeD Working Group created the HL7 Decision Support Service Implementation Guide, Release 1, Version 1 (December 2013) 21 , which defines SOAP and REST Web service interfaces for CDS guidance services. The implementation of this IG would promote systems whereby a health care provider can send a question about a patient to a CDS guidance supplier and receive CDS guidance back in near real-time. 20 HL7 Decision Support Service Implementation Guide, Release 1, Version 1 (December 2013). 21 http://wiki.siframework.org/file/view/20130830_DSS_IG_R1_for_201309_ballot.zip/448259852/20130830_DSS_IG_R1_for_201309_ballot.zip. The functionality discussed above could significantly enhance the scalability and time to market of new clinical knowledge and improve care. We also believe, with the progress made by the HeD initiative since its launch, that this proposed rule serves as an opportunity to propose the HeD standard for testing and certification. Further, its proposal as part of the 2015 Edition permits EHR technology developers and other interested stakeholders to provide feedback on its readiness for inclusion in the 2017 Edition. We therefore propose to adopt the HL7 Implementation Guide: Clinical Decision Support Knowledge Artifact Implementation Guide, Release 1 (January 2013) (“HeD standard”) as a standard at § 170.204(d) and to require that EHR technology be able to electronically process a CDS artifact formatted in the HeD standard. We also propose to adopt the HL7 Decision Support Service Implementation Guide, Release 1, Version 1 (December 2013) as a standard at § 170.204(e) and to require that EHR technology demonstrate the ability to make an information request, send patient data, and receive CDS guidance according to the interface requirements defined in the Decision Support Service IG. To supplement our proposals, we solicit comment on: • What specifically ONC should focus on when it comes to testing and certification for acceptance and incorporation of CDS Knowledge Artifacts; • The feasibility of implementing the interface requirements defined in the Decision Support Service IG to make an information request, send patient data, and receive CDS guidance in near real-time; • The ease with which EHR technology could be developed to consume CDS Knowledge Artifacts; • Whether we should work to distinguish between complex CDS Knowledge Artifacts and simple Knowledge Artifacts and to require only acceptance and incorporation of simple Knowledge Artifacts in the 2015 Edition, with increasing expectations of more complex capabilities in future editions; • The ability to store and auto-configure a CDS Knowledge Artifact in EHR technology; and • The ability to map the CDS Knowledge Artifact standard to data within the EHR technology (including medications, laboratory, and allergies information). • Electronic Notes MU Objective Record electronic notes in patient records. 2015 Edition EHR Certification Criterion § 170.315(a)(11) (Electronic notes) Gap Certification Status Ineligible We propose to adopt a 2015 Edition certification criterion that revises the 2014 Edition version. We propose a 2015 Edition “electronic notes” certification criterion that would include one new requirement compared to the 2014 Edition “electronic notes” certification criterion. Specifically, for the 2015 Edition certification criterion, we propose that EHR technology have the capability to search for information across separate notes within the EHR technology rather than just within one particular note. This expanded requirement is intended to reduce the time providers spend looking for specific patient information. The requirement to search across notes is not limited to a specific method . Instead, we are primarily concerned that the outcome expressed is demonstrated. We expect and encourage EHR technology developers to create innovative ways to achieve this functionality. As with the 2014 Edition “electronic notes” certification criterion, “search” continues to mean the ability to search free text and data fields of electronic notes. While we propose to adopt the “search across notes” capability for the 2015 Edition, we request comment on the following: • Whether this functionality should extend to all patient electronic notes stored in the EHR or just to a specific patient's electronic notes or specific types of patient notes; • Whether we should require this functionality in the 2015 Edition or wait to include it in a potential 2017 Edition “electronic notes” certification criterion; and • Health care provider opinions on whether the availability of such functionality (either searching across a specific patient's electronic notes stored in the EHR or all patients' electronic notes stored in an EHR) is so widespread that it would be unnecessary to require it as a condition of certification. We note that the “electronic notes” objective and measure for MU Stage 2 requires that notes be text searchable, but does not require searching across electronic notes. • Whether additional metadata should be required as part of electronic notes (such as the HL7 R2 header) to assist in both searching of notes, but also to make exporting electronic notes for patient data portability easier. • Drug Formulary Checks MU Objective Implement drug formulary checks. 2015 Edition EHR Certification Criterion § 170.315(a)(12) (Drug formulary checks) Gap Certification Status Eligible We propose to adopt a 2015 Edition certification criterion that is the same as the 2014 Edition version. However, we solicit public comment on the following issues. In the 2014 Edition EHR certification criteria final rule, we strongly encouraged EHR technology developers to use the updated Medicare Part D e-prescribing standards, including a new version of the NCPDP Formulary and Benefit standard (NCPDP Formulary and Benefit Standard 3.0), if or when it was finalized as an official Part D E-Prescribing standard (77 FR 45022). At the time, we did not believe it was necessary to require the use of the NCPDP Formulary and Benefit Standard 3.0 if/when it became the official Part D E-Prescribing standard as a condition of certification because our certification criterion was flexible and permitted EHR technology to access and store external drug formularies in support of meaningful use. CMS agreed with comments on the CY 2013 Physician Fee Schedule proposed rule that suggested the adoption of the NCPDP Formulary and Benefit Standard 3.0 as the official Part D E-Prescribing standard should be delayed until after July 1, 2014, which was expected to be the “sunset date” when NCPDP would cease to support version 1.0 (77 FR 68892). Furthermore, CMS determined that it should also delay recognition of the NCPDP Formulary and Benefit Standard 3.0 as a backward compatible version of NCPDP Formulary and Benefits Standard 1.0 because it did not believe that two versions of a standard should be used over an extended period of time (77 FR 68892). Having come within a year of the originally proposed sunset date, CMS recently re-proposed and finalized a proposal to recognize NCPDP Formulary and Benefit Standard v.3.0 as a backward compatible version of NCPDP Formulary and Benefit Standard 1.0 for the period of July 1, 2014 through February 28, 2015, and to retire version 1.0 and adopt version 3.0 as the official Part D E-Prescribing standard on March 1, 2015 (77 FR 74787-74789). 22 22 CMS originally proposed retiring V1.0 on July 1, 2014, but subsequently decided to postpone the retirement date to March 1, 2015, in response to comments to allow the industry adequate time to implement the necessary changes and testing to implement v3.0 (78 FR 74789). The NCPDP Formulary and Benefit Standard 3.0 includes updates based on industry feedback and new or modified business needs. For a full discussion of the changes that were made to previous versions of the NCPDP Formulary and Benefit Standard that NCPDP ultimately developed toward NCPDP Formulary and Benefit Standard 3.0, see 77 FR 45023-45024). The HITSC has discussed the current structure of the NCPDP Formulary and Benefit Standard v.4.0 23 and has noted potential limitations. These include: 24 23 V.4.0 has minor changes compared to v.3.0, including removal of values from an unused diagnosis code, typographical changes, and a change to the standard length of the name field. CMS has proposed adopting v.3.0 (CY2014 Physician Fee Schedule proposed rule), which includes the substantive changes from previous versions. 24 Clinical Operations Workgroup Update to the HITSC on June 19, 2013. http://www.healthit.gov/FACAS/sites/faca/files/clinical_operations_wg_update_062013_0.pdf. • That large files are needed to provide the formulary and benefit data; • that the data are submitted in batch rather than in real-time; • the provider cannot see patient-specific variations in drug-specific benefits; • an assumption that the patient's current drug plan is identified through a successful eligibility check based on a five-point identifier rather than the actual pharmacy data; • the inability to detect differences in primary and secondary prescription benefit coverage; • that the provider must manually pull updated formulary and benefit data rather than being pushed the updates. In order to resolve the limitations of NCPDP Formulary and Benefit Standard v.4.0, the HITSC has discussed that a new or updated standard or transaction is needed for EHRs to develop the functionality to run patient-specific formulary checks against the patient's actual drug benefit for a specific drug and dose in a timely manner. However, this is a long-term potential suggestion. Despite the NCPDP Formulary and Benefit Standard v.4.0's limitations, it does support providers' ability to know what drugs are included in the formulary, which can assist them in helping patients make decisions about their care. In the meantime, the NCPDP Formulary and Benefit Standard v.3.0 appears to be the best standard available for this particular use case. As described above, CMS has recently finalized a proposal to recognize NCPDP Formulary and Benefit Standard v.3.0 as a backward compatible version of NCPDP Formulary and Benefit Standard 1.0 starting on July 1, 2014, and v.4.0 includes minor changes compared to v.3.0. For a long-term potential solution, the NCPDP Telecommunications Standard used for pharmacy-to-payer transactions may offer some solutions when used in conjunction with the NCPDP Formulary and Benefit Standard v.4.0, specifically for certifying patient-level eligibility and prescription drug benefits with detailed information defining reimbursement or denial of compensation with explanations. However, to date, the NCPDP Telecommunications Standard has been used mostly for real-time billing of pharmacy transactions. In light of these circumstances and challenges, we solicit comment on whether we should leave this certification criterion as-is (in its flexible form) as we consider 2017 Edition policy or if it would be advantageous for us to adopt a standard in this 2015 Edition certification criterion for which compliance would be required. We also solicit comment on: • The appropriateness of using the NCPDP Telecommunications Standard in conjunction with the NCPDP Formulary and Benefit Standard v.3.0 or v.4.0 to support expanded use cases such as real-time benefit checks; and • Whether there are other standards or solutions that can address the potential limitations identified by HITSC and the use case of real-time benefit checks. • Smoking Status MU Objective Record smoking status for patients 13 years old or older. 2015 Edition EHR Certification Criterion § 170.315(a)(13) (Smoking status) Gap Certification Status Eligible We propose to adopt a 2015 Edition certification criterion that is the same as the 2014 Edition version. • Image Results MU Objective Imaging results and information are accessible through Certified EHR Technology. 2015 Edition EHR Certification Criterion § 170.315(a)(14) (Image results) Gap Certification Status Eligible We propose to adopt a 2015 Edition certification criterion that is the same as the 2014 Edition version. • Family Health History MU Objective Record patient family health history as structured data. 2015 Edition EHR Certification Criterion § 170.315(a)(15) (Family health history) Gap Certification Status Ineligible We propose to adopt a 2015 Edition certification criterion that revises the 2014 Edition version. The 2014 Edition “family health history” certification criterion requires EHR technology to demonstrate that it is capable of enabling a user to electronically record, change, and access a patient's family health history according to certain standards. In support of the MU Stage 2 requirement that family health history be captured in structured data, we adopted two standards for recording family health history: Systematized Nomenclature of Medicine—Clinical Terms (SNOMED CT®) terms for familial conditions and the HL7 Pedigree standard. In adopting SNOMED CT®, we acknowledged that HL7 Pedigree was a relatively new standard and that an implementation guide had not yet been published. 25 As such, we stated that the use of SNOMED CT® was perhaps the best intermediate step for coding family health history in structured data if one was not to use the HL7 Pedigree standard. 26 25 77 FR 54174 (September 4, 2012). 26 77 FR 54174 (September 4, 2012). In April 2013, an HL7 Pedigree IG, HL7 Version 3 Implementation Guide: Family History/Pedigree Interoperability, Release 1, 27 was published. With the publication of this IG, we propose to adopt a 2015 Edition “family health history” certification criterion that requires solely the recording of family health history according to the HL7 Pedigree standard and the HL7 Version 3 Implementation Guide: Family History/Pedigree Interoperability, Release 1 (i.e., it omits SNOMED CT® as an option). We believe that convergence to this single standard and IG will ensure more precise electronic recording of family health history data and, more importantly, improve the interoperability of family health history information. As part of the 2014 Edition Final Rule, we incorrectly assigned the HL7 Pedigree standard to § 170.207 where we adopt “vocabulary” standards. Accordingly, for the 2015 Edition proposal we have placed the HL7 Pedigree standard and its IG in § 170.205(m)(1) to more accurately place it in the “content” exchange standards section. 27 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=301. • Patient List Creation MU Objective Use clinically relevant information to identify patients who should receive reminders for preventive/follow-up care. 2015 Edition EHR Certification Criterion § 170.315(a)(16) (Patient list creation) Gap Certification Status Eligible We propose to adopt a 2015 Edition “patient list creation” certification criterion that revises the 2014 Edition version to incorporate our guidance provided in FAQ 39. 28 Specifically, the text of the 2015 Edition “patient list creation” certification criterion provides that EHR technology must demonstrate its capability to use at least one of the more specific data categories included in the “demographics” certification criterion (45 CFR 170.315(a)(5)) (e.g., sex or date of birth). 28 http://www.healthit.gov/policy-researchers-implementers/39-question-04-13-039. For a potential 2017 Edition “patient list creation” certification criterion, we request comment on four issues for EHR technology certification: (1) Whether patient communication preferences should be a requirement for the inpatient setting; (2) Whether a minimum list of patient communication preferences should be more specifically defined in order to require that EHR technology be capable of creating patient reminder lists based on a patient's preferred communication medium (e.g., electronically through secure email or a patient portal, paper/regular mail, or phone); (3) Whether EHR technology should be able to use a patient's preferred language as a filter; and (4) Because this certification criterion also supports the meaningful use objective and measure related to “patient reminders,” whether we should include within this certification criterion or adopt a new certification criterion that would require EHR technology be able to provide patient reminders according to identified patient preferences and preferred language (for example, if the patient preference for a reminder was “email” and preferred language was English, the EHR technology would have to demonstrate that it could send reminders in English via email). • 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. 2015 Edition EHR Certification Criterion § 170.315(a)(17) (Patient-specific education resources) Gap Certification Status Ineligible We propose to adopt a 2015 Edition “patient-specific education resources” certification criterion that revises the 2014 Edition version in three ways. Our first proposal is to adopt this certification without the requirement that EHR technology be capable of electronically identifying patient-specific education resources based on “laboratory values/results.” We understand from stakeholder feedback on the 2014 Edition version of this criterion that the Infobutton standard cannot support this level of data specificity, and we do not expect EHR technology developers to develop an alternative method that could electronically identify patient-specific education resources based on laboratory values/results. Our second proposal is to adopt the HL7 Implementation Guide: Service-Oriented Architecture Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain, Release 1, August 2013. This is the updated IG of the Draft Standard for Trial Use (DSTU) version we adopted for the 2014 Edition “patient-specific education resources” certification criterion. To clearly distinguish this IG in the regulation text from the DSTU version, we propose a technical amendment to § 170.204(b)(2) to note that the version is the DSTU version. Finally, our third proposal is to revise the regulation text to be more consistent with the intent and interpretation of the 2014 Edition certification criterion regulation text we expressed in the 2014 Edition final rule. 29 The text of the 2015 Edition certification criterion makes clear that the EHR technology must demonstrate the capability to electronically identify patient-specific education resources using Infobutton and an alternative method that does not rely on Infobutton. To note, we propose that the guidance we provided in FAQ 40 30 would still be applicable to the 2015 Edition “patient-specific education resources” certification criterion. 29 77 FR 54216 30 http://www.healthit.gov/policy-researchers-implementers/40-question-04-13-040. We request comment on whether we should adopt a different approach related to the methods EHR technology uses to electronically identify patient-specific education resources for the 2015 Edition, a potential 2017 Edition “patient-specific education resources” certification criterion, or both. The 2014 Edition and the proposed 2015 Edition EHR certification criteria require EHR technology to demonstrate the capability to electronically identify for a user patient-specific education resources using Infobutton and an alternative method. We seek comment on whether we should: (1) Maintain this approach; (2) require EHR technology to demonstrate only the use of Infobutton, but permit EHR technology to be certified to other methods upon an EHR technology developer's request for the purpose of an EP, EH, or CAH being able to use the alternative certified method for MU (to count such use toward meeting the measure); or (3) certify only the use of Infobutton and consult with CMS regarding a meaningful use policy change that would permit the use of any method (certified or not) to electronically identify patient-specific education resources, provided that the EP, EH, or CAH has EHR technology certified to perform the Infobutton capability. We also seek comment on whether we should require that EHR technology be capable of providing patient-specific education resources in a patient's preferred language in the 2015 Edition, in a potential 2017 Edition certification criterion, or in both. • 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). 2015 Edition EHR Certification Criterion § 170.315(a)(18) (Inpatient setting only—electronic medication administration record) Gap Certification Status Eligible We propose to adopt a 2015 Edition certification criterion that is the same as the 2014 Edition version. • Advance Directives MU Objective Record whether a patient 65 years old or older has an advance directive. 2015 Edition EHR Certification Criterion § 170.315(a)(19) (Inpatient setting only—advance directives) Gap Certification Status Eligible We propose to adopt a 2015 Edition certification criterion that is the same as the 2014 Edition version. • Implantable Device List MU Objective N/A 2015 Edition EHR Certification Criterion § 170.315(a)(20) (Implantable Device List) Gap Certification Status Ineligible We propose to adopt a new 2015 Edition certification criterion that would require EHR technology to be able to record and display a unique device identifier (UDI) 31 and other information about a patient's implantable devices. This proposed certification criterion represents a first step towards enabling EHR technology to facilitate the widespread capture and use of UDI data to prevent device-related medical errors, improve the ability of hospitals and clinicians to respond to device recalls and device-related patient safety information, and achieve other important patient safety and public health benefits consistent with the fundamental aims of the HITECH Act 32 and the July 2, 2013 HHS Health Information Technology Patient Safety Action and Surveillance Plan. 33 31 A UDI is a unique numeric or alphanumeric code that consists of two parts: (1) A device identifier (DI), a mandatory, fixed portion of a UDI that identifies the labeler and the specific version or model of a device, and (2) a production identifier (PI), a conditional, variable portion of a UDI that identifies one or more of the following when included on the label of a device: The lot or batch number within which a device was manufactured; the serial number of a specific device; the expiration date of a specific device; the date a specific device was manufactured; the distinct identification code required by 21 CFR § 1271.290(c) for a human cell, tissue, or cellular and tissue-based product (HCT/P) regulated as a device. http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/UniqueDeviceIdentification/ . 32 Specifically, the certification criteria supports the National Coordinator's responsibility under the HITECH Act to ensure that the nation's health IT infrastructure supports activities that “reduce[] medical errors,” “improve[] health care quality,” “improve[] public health activities,” and “facilitate[] the early identification and rapid response to public health threats and emergencies . . . .” 42 U.S.C. § 300jj-11(b)(2) & (7). 33 Available at http://www.healthit.gov/policy-researchers-implementers/health-it-and-patient-safety. The first objective of the Health IT Patient Safety Plan is to “use health IT to make care safer.” See id. at 7. The Plan specifically contemplates that ONC will update its standards and certification criteria to improve safety-related capabilities and add new capabilities that enhance patient safety. FDA issued the Unique Device Identification System Final Rule on September 24, 2013. 34 This FDA rule implements a statutory directive to establish a “unique device identification system” for medical devices that will enable adequate identification of devices through distribution and use. 35 It accomplishes this objective by requiring that a UDI be included on the label of most medical devices distributed in the United States. In addition, for each device with a UDI, a standard set of identifying elements will be publicly available through the FDA's Global Unique Device Identification Database (GUDID). 36 FDA is scheduled to fully implement the UDI system for devices that are implantable, life-saving, and life sustaining by September 2015. 37 34 78 FR 58786. 35 21 U.S.C. § 360i(f). 36 The FDA's draft guidance on the GUDID is available at http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/UniqueDeviceIdentification/ . 37 Pursuant to 21 U.S.C. § 360i(f), FDA must implement the Unique Device Identification System Final Rule with respect to devices that are implantable, life-saving, and life sustaining not later than two years after the rule was finalized. Other implementation and compliance dates are detailed in the final rule. We believe that EHR technology will play a key role in the widespread adoption and utilization of UDIs and that its use of UDIs can help reduce device-related medical errors and provide other significant patient safety, health care quality, and public health benefits. Specifically, EHR technology could be leveraged in conjunction with automated identification and data capture (AIDC) technology or other technologies to streamline the capture and exchange of UDIs and associated device data in clinical and administrative workflows. Moreover, patients' UDI data in EHR technology could pave the way for new CDS and help health care providers more rapidly and accurately identify a patient's devices and key information about the safe and effective use of such devices. Further, EHR technology could facilitate better and more accurate reporting of adverse events and other information to reporting systems and registries and enable more effective corrective and preventative action in response to device recalls and alerts and other device-related information related to patient safety. 38 38 These and other potential benefits of UDIs and the UDI system established by FDA are described in detail in the Unique Device Identification System Notice of Proposed Rulemaking, 77 FR 40736. We recognize that additional standards and technical specifications will be required to support the full range of capabilities contemplated above. Indeed, efforts to identify or develop these standards are already underway. 39 Nevertheless, we believe that it is both feasible and important for EHR technology developers to begin implementing at least the baseline functionality necessary to capture, store, and retrieve UDIs and other contextually relevant information associated with a patient's medical devices, specifically implantable devices. By their nature, these devices cannot be inspected with the naked eye and are more susceptible to misidentification, which can result in patient harm. Moreover, once a device is implanted, it is separated from its UDI, which is attached only to the device's labeling and not directly marked on the device itself. Under the FDA's accelerated implementation timeline, UDIs will be available for all implantable devices no later than September 2015. 39 For example, the HL7 Technical Steering Committee has initiated a UDI Task Force to ensure that UDI is implemented in a consistent and interoperable manner across the suite of HL7 standards. See http://hl7tsc.org/wiki/index.php?title=TSC_Minutes_and_Agendas . FDA is collaborating with the Engelberg Center for Health Care Reform at the Brookings Institute to develop a roadmap for the successful adoption and implementation of UDI throughout the healthcare system. See http://www.brookings.edu/about/centers/health/projects/development-and-use-of-medical-devices/udi . AHRQ has incorporated UDI and associated data attributes in its Common Formats for adverse event reporting. See http://www.pso.ahrq.gov/formats/brochurecmnfmt.htm . Also see AHRQ Data Dictionary, Common Formats Hospital Version 1.2, at 87, available at https://www.psoppc.org/c/document_library/get_file?p_l_id=375680&folderId=431263&name=DLFE-15061.pdf . Through an S&I Framework Structured Data Capture Initiative, ONC, FDA, and other stakeholders are pursuing the inclusion of UDI data in FDA adverse event reporting. See http://wiki.siframework.org/Structured+Data+Capture+Initiative. The inclusion of UDI data in FDA adverse event reporting is being pursued through an ONC S&I Framework Structured Data Capture Initiative, see http://wiki.siframework.org/Structured+Data+Capture+Initiative . We propose to adopt a 2015 Edition certification criterion focused on EHR technology's ability to record UDI information about implantable devices. More specifically, EHR technology would have to enable a user to electronically record the UDI of an implantable device and other relevant information (such as a procedure note or additional information about the device) as part of a patient's “implantable device list.” EHR technology would also be required to allow a user to electronically access and view a patient's list of UDIs and other relevant information associated with a patient's implantable devices. In addition, the EHR technology would need to be able to parse the UDI in order to extract and allow a user to view the “device identifier” and “production identifier” portions of the UDI. The purpose of this requirement is to ensure that a user will be able to use the device identifier to manually retrieve associated data elements from an authoritative source based on the GUDID, once available and, similarly, to ensure that a user will be able to manually use the production identifier in the event of a device recall. We expect that EHR technology would be able to automate these processes once appropriate standards and technical specifications are developed. As previously indicated, we believe EHR technology should also facilitate the UDI's exchange in order to increase the overall availability and reliability of information about patients' implants and other devices. Thus, we propose to reference “the UDI(s) for a patient's implantable device(s)” in the following proposed 2015 Edition EHR certification criteria which also propose the adoption of the newest version of the Consolidated CDA. 40 We understand that this data can already be accommodated in the current Consolidated CDA version and is best placed in the “Product Instance” data element which is part of the Procedures template (see section 5.65 of the current Consolidated CDA version adopted at 45 CFR 170.205(a)(3) and incorporated by reference at 45 CFR 170.299(f)(8)). We seek comment from Consolidated CDA experts on whether there is a better location to place this information so that we may provide updated guidance in a final rule or FAQ. For clarity and context purposes each impacted proposed certification criterion will include a reminder about our proposal here. However, to reduce redundancy, this proposal and its rationale serves as the basis for the UDI's inclusion in each of those criteria. 40 This version is Release 2 of the Draft Standard for Trial Use, which is discussed in further detail under the 2015 Edition “transitions of care” certification criterion. • 170.315(b)(1)—Transitions of care. • 170.315(b)(6)—Data portability. • 170.315(e)(1)—View, download, and transmit to third party. • 170.315(e)(2)—Clinical summary. We have also proposed elsewhere in this Proposed Rule to modify § 170.102 to include new definitions for “implantable device,” “unique device identifier,” “device identifier,” and “production identifier.” This will prevent any interpretation ambiguity and ensure that each term's specific meaning reflects the same meaning given to them in the Unique Device Identification System Final Rule and in 21 CFR 801.3. We seek public comment on additional EHR technology capabilities we are considering including as part of the 2017 Edition rulemaking. Based on stakeholder input and in consultation with FDA, we believe that the following EHR technology capabilities could help achieve our stated objectives: • Record a minimum set of data elements for each UDI in a patient's implantable device list, including: ○ Labeler Name (Manufacturer); ○ Brand Name; ○ Version or Model; ○ Global Medical Device Nomenclature Name; ○ Single Use indicator; ○ Labeled as containing natural rubber latex or dry natural rubber; and ○ MRI Safety Status. • Accept electronic UDI data via automatic identification and data capture (AIDC) or other assistive technologies used in health care systems (e.g., bar code scanners and radio frequency identification). • Use the device identifier portion of the UDI to obtain and incorporate GUDID device identification attributes in the patient's implantable device list. • Use the device identifier or production identifier portions of the UDI to generate lists of patients with a particular implantable device. • Make a UDI and its associated identification attributes accessible to the EHR technology for reporting purposes (e.g., adverse event reporting, registry population, recalls). • Exchange a UDI and UDI data with procedure reporting systems (including adverse event incident reporting systems and medical specialty reporting systems) and other systems that associate a patient with a device. • Expand these and other capabilities to additional types of devices used by patients. We solicit comment on whether to propose these capabilities (or a subset thereof) for adoption in a subsequent rulemaking. We also request comment on other standards, capabilities, or certification criteria that we have not identified but that would further our stated aims. Finally, we specifically seek input on the list of data elements that we have identified and whether we should propose these or other data elements in connection with this criterion. • 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. 2015 Edition EHR Certification Criteria § 170.315(b)(1) (Transitions of care) Gap Certification Status Ineligible We propose to adopt a single 2015 Edition certification criterion for “transitions of care” (ToC). This proposed criterion would include significant modifications when compared to the two related 2014 Edition criteria adopted in the 2014 Edition Final Rule. This proposed criterion also reflects corresponding structural and clarifying changes that we have made to the proposed 2015 Edition “clinical information reconciliation and incorporation” certification criterion (discussed right after this criterion) and to the “view, download, transmit to third party (VDT)” certification criterion. Our overall rationale for these proposed modifications is three-fold: 1) to further improve interoperability for ToC; 2) to improve the market availability of certified electronic exchange services for transport (and, thus, increase EPs, EHs, and CAHs' abilities to choose such services to demonstrate MU) by decoupling the 2014 Edition's ToC requirement to demonstrate both “content” and “transport” capabilities together in order to meet the two ToC certification criteria; and 3) to make the work-flow sequence we had in mind when we drafted the 2014 Edition criterion (at 45 CFR 170.314(b)(1)) clearer. Interoperability for ToC is one of ONC's top priorities. ONC follows the definition of “interoperability” provided by the Institute for Electrical and Electronics Engineering Computer Dictionary which defines interoperability to mean: “ the ability of two or more systems or components to exchange information and to use the information that has been exchanged.” 41 With the adoption of a single content standard (Consolidated CDA) and “transport”/transmission standards as part of the 2014 Edition ToC certification criteria as well as the requirement that all EHR technology be certified to support transmissions in accordance with the Applicability Statement for Secure Health Transport (the primary Direct Project specification), 42 we made significant strides toward this definition. 41 See IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries (New York, NY: 1990). 42 http://wiki.directproject.org/file/view/Applicability+Statement+for+Secure+Health+Transport+v1.1.pdf. With that in mind, the 2014 Edition certification criteria and corresponding MU Stage 2 measures have generated a significant amount of questions, requests for clarifications, and feedback related to how the ToC certification requirements could be improved in light of on-the-ground experience and challenges. We have reviewed and considered all of this feedback since the 2014 Edition Final Rule and now propose a suite of changes that we believe will address stakeholder concerns as well as enhance interoperability for this priority use case. “Decoupling” Content and Transport In the 2014 Edition Final Rule, we adopted two ToC certification criteria. The first, § 170.314(b)(1), requires EHR technology to be able to “receive, display, and incorporate” transition of care/referral summaries. The second, § 170.314(b)(2), requires EHR technology to be able to “create and transmit” transition of care/referral summaries. These two 2014 Edition certification criteria require that EHR technology be able to “receive” and “transmit” a Consolidated CDA (“transition of care/referral summary”) in accordance with the Applicability Statement for Secure Health Transport (the primary Direct Project specification). Beyond the required transport standard (the primary Direct Project specification), we also included the option for EHR technology to be tested and certified to two other transport capabilities (i.e., Direct +XDR/XDM and SOAP + XDR/XDM). As we indicated at the beginning of the preamble, the “scope” of a certification criterion begins at the second paragraph level of the regulatory section and encompasses all paragraph levels below the second paragraph level. Therefore, all capabilities under § 170.314(b)(1) and (b)(2)—including the transmission capabilities—must be demonstrated to meet each criterion as a whole. This means that under the 2014 Edition there is no way for EHR technology to be certified solely to perform the transport capabilities specified in each criterion. Since the 2014 Edition Final Rule's publication, ONC has received specific feedback that this constraint or the “binding” of transport and content capabilities within the scope of a single certification criterion could impede innovation and limit EPs, EHs, and CAHs' market choices for electronic health information exchange services. Stakeholders also indicated that we had incorrectly imposed the coupling of technical capabilities that can be adequately performed by two different systems. They stated that content capabilities and transport capabilities should be separately tested and certified as the standard that supports one may change over time while the other remains the same. This issue is best illustrated by the requirement in both 2014 Edition ToC criteria that EHR technology demonstrate its conformance to the primary Direct Project specification. As shown in the figure below, the primary Direct Project specification is not an “end-to-end” specification. Rather, the primary Direct Project specification is applicable to capabilities that are typically performed by what are called Health Information Service Providers or HISPs. At times, an EHR technology may be designed with fully integrated HISP functions, but it is equally likely that third-party intermediaries will perform these capabilities. As a result, our 2014 Edition ToC criteria have resulted in HISP functionality being built into EHR technology (or, conversely, EHR functionality being built into a HISP solely for the HISP to meet the certification criteria). • Figure 1: Th [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%3A2014-03959. Public record. Not legal advice.