Voluntary 2015 Edition Electronic Health Record (EHR) Certification Criteria; Interoperability Updates and Regulatory Improvements, 10879-10946 [2014-03959]
Download as PDFAgencies
[Federal Register Volume 79, Number 38 (Wednesday, February 26, 2014)] [Proposed Rules] [Pages 10879-10946] From the Federal Register Online via the Government Printing Office [www.gpo.gov] [FR Doc No: 2014-03959] [[Page 10879]] Vol. 79 Wednesday, No. 38 February 26, 2014 Part II Department of Health and Human Services ----------------------------------------------------------------------- 45 CFR Part 170 Voluntary 2015 Edition Electronic Health Record (EHR) Certification Criteria; Interoperability Updates and Regulatory Improvements; Proposed Rule Federal Register / Vol. 79 , No. 38 / Wednesday, February 26, 2014 / Proposed Rules [[Page 10880]] ----------------------------------------------------------------------- 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. https://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 https://www.regulations.gov as part of this proposed rule's docket and on ONC's Web site (https://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 https://www.regulations.gov. Docket: For access to the docket to read background documents or comments received, go to https://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). [[Page 10881]] 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[supreg] LOINC[supreg] 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[supreg] 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\ https://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, [[Page 10882]] 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 Sec. 170.202; the standard that identifies the data elements referenced by clinical quality measures (Sec. 170.204(c)); and certain standards related to the protection of electronic health information identified in Sec. 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\ https://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. [[Page 10883]] 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 ---------------------------------------------------------------------------------------------------------------- Total average Year Ratio (percent) Total low cost Total high cost cost estimate estimate ($M) estimate ($M) ($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 [[Page 10884]] 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 [[Page 10885]] 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 Sec. 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 Sec. 170.315. We also propose a substantive revision to the 2014 Edition syndromic surveillance certification criterion adopted at Sec. 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 Sec. 170.315(a) first, then Sec. 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, [[Page 10886]] certification to proposed 2015 Edition EHR certification criteria at Sec. 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--Sec. 170.300 Section 170.300 establishes the applicability of subpart C-- Certification Criteria for Health Information Technology. We propose to revise paragraph (d) of Sec. 170.300 to add in a reference to Sec. 170.315, which would clarify which specific capabilities within a certification criterion included in Sec. 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 Sec. 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 Sec. 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 Sec. 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. [[Page 10887]] 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 Sec. 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\ https://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 (Sec. Sec. 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 Sec. 170.205(j)(2) and the ``laboratory orders'' standard at Sec. 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 Sec. 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[supreg]) adopted at Sec. 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\ https://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 Sec. 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 [[Page 10888]] Sec. 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 Sec. 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\ https://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\ https://www.healthit.gov/policy-researchers-implementers/43-question-11-13-043. --------------------------------------------------------------------------- [[Page 10889]] 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 Sec. 170.207(g)(2). Note, to implement this proposal, we would have to modify the regulatory text hierarchy in Sec. 170.207(g) to designate the standard referenced by the 2014 Edition version of this certification criterion at Sec. 170.207(g) to be at Sec. 170.207(g)(1). --------------------------------------------------------------------------- \8\ https://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\ https://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\ https://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 Sec. 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 Sec. 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 [[Page 10890]] 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 Sec. 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 Sec. 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 Sec. 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 Sec. 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 (Sec. 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 Sec. 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\ https://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 (Sec. 170.314(a)(8)(ii)(2)) in accordance with one of the Infobutton implementation specifications at Sec. 170.204(b)(1) or Sec. 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 Sec. 170.204(b)(3)) in [[Page 10891]] 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\ https://www.healthit.gov/policy-researchers-implementers/34-question-12-12-034. \15\ https://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\ https://wiki.siframework.org/file/detail/implementation_guide_working_final_042413_lse_uploaded-1.docx. \19\ Background documents and implementation guides can be found at https://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\ https://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 Sec. 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 Sec. 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 Sec. 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; [[Page 10892]] 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 Sec. 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. https://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 [[Page 10893]] Sec. 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 Sec. 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 Sec. 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[supreg]) terms for familial conditions and the HL7 Pedigree standard. In adopting SNOMED CT[supreg], 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[supreg] 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[supreg] 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 Sec. 170.207 where we adopt ``vocabulary'' standards. Accordingly, for the 2015 Edition proposal we have placed the HL7 Pedigree standard and its IG in Sec. 170.205(m)(1) to more accurately place it in the ``content'' exchange standards section. --------------------------------------------------------------------------- \27\ https://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 Sec. 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\ https://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 Sec. 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 Sec. 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 [[Page 10894]] 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\ https://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 Sec. 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 Sec. 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 Sec. 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 Sec. 1271.290(c) for a human cell, tissue, or cellular and tissue-based product (HCT/P) regulated as a device. https://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. Sec. 300jj-11(b)(2) & (7). \33\ Available at https://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. Sec. 360i(f). \36\ The FDA's draft guidance on the GUDID is available at https://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/UniqueDeviceIdentification/. \37\ Pursuant to 21 U.S.C. Sec. 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 [[Page 10895]] 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 https://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 https://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 https://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 https://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 https://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 Sec. 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: [cir] Labeler Name (Manufacturer); [cir] Brand Name; [cir] Version or Model; [cir] Global Medical Device Nomenclature Name; [cir] Single Use indicator; [cir] Labeled as containing natural rubber latex or dry natural rubber; and [cir] 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 [[Page 10896]] 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 Sec. 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\ https://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, Sec. 170.314(b)(1), requires EHR technology to be able to ``receive, display, and incorporate'' transition of care/ referral summaries. The second, Sec. 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 Sec. 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 [[Page 10897]] 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: The primary Direct Project specification's applicability. [GRAPHIC] [TIFF OMITTED] TP26FE14.000 We agree with stakeholder feedback that we should enable transport capabilities to be tested and certified separately from content capabilities. We also believe that permitting separate testing and certification for these capabilities would enable more transport- specific services to be certified as EHR Modules and, thus, would provide EPs, EHs, and CAHs with more choices in terms of the electronic health information exchange services they can use to demonstrate MU. Accordingly, we propose to adopt a single 2015 ToC certification criterion that focuses on content capabilities (create, receive, and display) and an EHR technology's ability to connect to a service that is conformant with the primary Direct Project specification through the use of a newly developed, ``ONC Implementation Guide for Direct Edge Protocols, Version 1.0, January 10, 2014'' (IG for Direct Edge Protocols),\43\ which we propose to adopt at Sec. 170.202(e). This proposal, in addition to our proposed revisions to the Base EHR definition to reference the 2015 Edition, continues to maintain and reinforce our overall policy that Certified EHR Technology must be able to perform transmissions in accordance with the primary Direct Project specification. The difference is that it enables transport capabilities to be separately tested and certified and separately implemented by EPs, EHs, and CAHs as a means to meet the Certified EHR Technology definition. We discuss our specific ``transmission'' certification criteria later in the preamble and our proposal to include them in a new regulatory paragraph ``(h)'' within Sec. 170.315. --------------------------------------------------------------------------- \43\ https://wiki.directproject.org/file/detail/Implementation+Guide+for+Direct+Edge+Protocols+v1.0.pdf. --------------------------------------------------------------------------- Edge Protocol for EHR to HISP Connectivity for ``Direct'' Transmissions As illustrated by Figure 1 and the arrows labeled with ``edge,'' the primary Direct Project specification focuses on HISP-to-HISP transactions and not on EHR-to-HISP transactions. Since the 2014 Edition Final Rule, the stakeholder community that participates in the Direct Project has produced a new implementation guide to clarify for EHR technology developers the standardized protocols that should be used to connect to a HISP (i.e., EHR-to-HISP). This new implementation guide specifies that both a ``Direct Edge System'' (i.e., EHR technology) and a ``Direct HISP System'' must support at least one of the following protocols: IMAP4, POP3, SMTP, or IHE XDR. While we propose a separate certification criterion for conformance to the primary Direct Project specification, we seek to maintain the same policy outcome we set in the 2014 Edition (i.e., that every EHR technology certified to ToC is capable of performing transmissions in accordance with the primary Direct Project specification). As a result, we propose that the 2015 Edition ToC certification criterion specify that EHR technology demonstrate it can send and receive transition of care/referral summaries in a transmission--that conforms to the IG for Direct Edge Protocols--which is used by a service that has implemented the primary Direct Project specification. In other words, testing and certification to this portion of proposed 2015 Edition ToC certification criterion would require that EHR technology be able connect to a HISP following the IG for Direct Edge Protocols and enable that HISP to subsequently transmit the transition of care/referral summary using the primary Direct Project specification to a recipient. We emphasize that while the standard adopted at Sec. 170.202(a) is still referenced in this proposed criterion, its reference is to solely express the technical outcome we expect to be demonstrated by EHR technology--that a transmission from EHR-to-HISP is successful in that the HISP can subsequently transmit the transition of care/referral summary. Again, these proposed revisions are to make clear that as a result of our proposal, we would no longer require testing and certification to the primary Direct Project specification as a condition of meeting this certification criterion. Updated Consolidated CDA Standard As expressed in the 2014 Edition Final Rule, the Consolidated CDA standard is now the single standard permitted for certification and the representation of summary care records. It is referenced in four proposed 2015 Edition certification criteria (ToC, VDT, Clinical Summary, Data Portability). Industry stakeholders have continued to work to improve and refine the Consolidated CDA standard since the 2014 Edition Final Rule.\44\ An updated version, HL7 Implementation Guide for CDA[supreg] Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Release 2.0,\45\ was balloted in August and September 2013. A reconciliation of comments received during balloting will be completed prior to the issuance of a final rule for this proposed rule. The currently balloted version includes the following changes which we believe provide important clarifications and enhancements: --------------------------------------------------------------------------- \44\ https://wiki.siframework.org/Companion+Guide+to+Consolidated+CDA+for+MU2. \45\ Access to the standard can be found at the following link, which requires the creation of an HL7 account: https://www.hl7.org/documentcenter/public/ballots/2013SEP/downloads/CDAR2_IG_CCDA_CLINNOTES_DSTUR2_D1_2013SEP.zip. --------------------------------------------------------------------------- Addition of new structural elements: new document sections and data entry templates: [cir] New Document Templates for: Care Plan; Referral Note; Transfer Summary. [cir] New Sections for: Goals; Health Concerns; Health Status Evaluation/Outcomes; Mental Status; Nutrition; Physical Findings of Skin. [cir] New organizers and many new entries (e.g. Wound Observation). Some sections/entries were deprecated (i.e., not in use any longer). [[Page 10898]] Updates to (versioning of) template/section/entry object identifiers (OIDs). [cir] This includes new chapter describing HL7's approach to template versioning. Tighter data constraints/requirements. [cir] For example, some data elements with a ``MAY'' requirement now have a ``SHOULD'' requirement. Likewise, some with a ``SHOULD'' requirement now have a ``MUST'' requirement. Updated Vocabulary/Value Set constraints. [cir] For example: two SNOMED CT codes were added to Current Smoking Status value set and Tobacco Use value set to support the 2014 Edition vocabulary requirements for patient smoking status. [cir] NLM's VSAC was named as reference for Value Sets used in CCDA. Accordingly, we propose to adopt the updated Consolidated CDA standard in Sec. 170.205(a)(4) and we propose to reference its use in the proposed 2015 Edition ToC certification criterion as well as the three other certification criteria previously mentioned. We also propose to require (for reasons already provided as part our proposal for the ``implantable device list'' certification criterion) that EHR technology must be capable of including the UDI(s) for a patient's implantable device(s) as data within a created Consolidated CDA formatted document. Shifting ``Incorporation'' From ToC to Clinical Information Reconciliation The 2014 Edition ToC certification criterion at Sec. 170.314(b)(1)(A) and (B) requires EHR technology to demonstrate ``[u]pon receipt of a transition of care/referral summary formatted according to the standard adopted at Sec. 170.205(a)(3)'' that it can properly match the transition of care/referral summary received to the correct patient; and electronically incorporate medications, problems, and medication allergy data. At the beginning of the 2014 Edition Final Rule we responded to comments on our proposed description for ``incorporate'' (77 FR 54168-54169) and stated that, ``[w]e had revised our description of incorporation to reflect the common interpretation commenters stated they assigned to the term. Thus, when the term incorporate is used within a certification criterion it is intended to mean to electronically process structured information from another source such that it is combined (in structured form) with information maintained by EHR technology and is subsequently available for use within the EHR technology by a user.'' We also responded to comments on this issue at 77 FR 54218 and offered a more nuanced response in the context of the 2014 Edition ToC certification criterion at Sec. 170.314(b)(1) and the clinical information reconciliation certification criterion at Sec. 170.314(b)(4): [A]s we clarified in the beginning of this final rule, we intended for the term ``incorporate'' to mean that EHR technology would be able to process the structured data contained in those three Consolidated CDA sections (medications, problems, medication allergies) such that it could be combined (in structured form) with data already maintained by EHR technology and would subsequently be available for use, such as to be used as part of the clinical information reconciliation capabilities (expressed in the certification criterion adopted at (Sec. 170.314(b)(4)). Stakeholders have indicated confusion regarding this preamble explanation and questioned the workflow assumption we had in mind when placing the ``incorporation'' capability in the ToC certification criterion. They indicated that in a typical workflow, inbound data is first reconciled and then incorporated (which makes it subsequently available for use within the EHR technology). Thus, our explanation that incorporated information as part of the ToC certification criterion would ``subsequently be available for use, such as to be used as part of the clinical information reconciliation capabilities'' misstated the workflow. To avoid future confusion, the proposed 2015 Edition ToC certification no longer references the 2014 Edition's ``incorporation'' capabilities at Sec. 170.314(b)(1)(A) and (B) and instead, we propose to place those capabilities in the proposed 2015 Edition ``clinical information reconciliation and incorporation'' certification criterion. We believe this revision will clarify the interplay between these two certification criteria and will clear up any misconceptions about the anticipated workflow. The specific capabilities for ``section views'' expressed at Sec. 170.314(b)(1)(C) would continue to remain as part of our proposed 2015 Edition ToC criterion because they focus on content capabilities. ToC Interoperability and MU Stage 2 ``Cross-Vendor'' Exchange Proposals As part of the EHR Incentive Programs Stage 2 proposed rule, CMS proposed a new measure for its ``Transitions of Care objective'' that would have limited the new measure's numerator to only permit electronic transmissions to count if they were made to recipients that were: ``(1) Not within the organization of the transmitting provider; and (2) did not have Certified EHR Technology from the same EHR vendor'' (77 FR 13724). This proposal sought to use the EHR Incentive Programs to reward this outcome and, by virtue of setting this outcome, give EPs, EHs, and CAHs as well as EHR technology developers an explicit reason to implement solutions that promote interoperable electronic health information exchange. Public comment on these proposals raised numerous concerns, including (among other issues) geographic market share constraints and undue burden because both limitations would be hard to do determine in an automated way. In response, CMS ultimately decided not to retain either of the proposed numerator limitations (77 FR 54019). CMS did, however, adopt a third ToC measure for MU Stage 2 that requires EPs, EHs, and CAHs to ``conduct one or more successful electronic exchanges of a summary of care document, which is counted in measure 2 with a recipient who has EHR technology designed by a different EHR technology developer than the sender's EHR technology certified to 45 CFR 170.314(b)(2); or conduct one or more successful tests with the CMS designated test EHR during the EHR reporting period.'' While the measurement burden associated with the ``cross vendor'' numerator limitation proved too difficult a concept to implement, we have continued to consider ways to reach this same outcome. First, we keep in mind that the proposed cross-vendor numerator limitation was imposed on the ``sender.'' The sender, upon transmission of a summary care record, would need to know if the recipient had a different EHR technology developer's product than they did in order to determine whether that transmission could be counted in the numerator. Second, we considered solutions. One theoretical solution we considered would be to automate the sender's measurement. This would require EHR technology (through certification) to send an acknowledgement with the EHR technology developer's name or other identifier upon receipt of a summary care record. This ``solution,'' however, would require modifications to existing technical standards and would be insufficient (and really a partial solution) because EPs, EHs, and CAHs, can (today) electronically transmit summary care records to non-MU providers for ToC and count such transmissions in their numerator. Thus, health care providers who have no incentive to adopt CEHRT would not necessarily have the capability to [[Page 10899]] respond with this kind of acknowledgement and there would still be situations where EPs, EHs, and CAHs would have to manually count transmissions. As we took a step back to assess this proposal's viability, we realized its purpose would be to solve a measurement problem and not an interoperability problem. Thus, we reassessed the true ``problem'' we (ONC) were trying to solve--interoperability--and, more specifically, the ``use'' aspect of the interoperability definition we follow. Given that our 2014 Edition ToC certification criteria require EHR technology to be able to receive and transmit Consolidated CDAs in accordance with the primary Direct Project specification, EPs, EHs, and CAHs will have the ability to ``exchange'' with any other EHR technology. However, it remains unclear whether each individual EP, EH, or CAH will be able to effectively use the Consolidated CDA it receives. While the Consolidated CDA is the only standard we permit for summary care record creation, its specifications permit a certain level of optionality and variability. As a result, while two different certified EHR technologies can accomplish ``exchange'' with a validly implemented Consolidated CDA, the recipient may be unable to correctly or accurately parse a part or all of the Consolidated CDA. Early feedback from a handful of stakeholders has indicated that such events do occur. We believe that EHR technology certification can improve this aspect of interoperability and, in turn, get us closer to the ultimate outcome that was intended by the original MU Stage 2 proposal--which is that an EP, EH, or CAH could both exchange a Consolidated CDA with any other EHR technology and be able to subsequently use the Consolidated CDA it receives. This is a fundamental capability needed beyond MU and will be critical to help advance delivery reform goals. Achieving this interoperability goal also closes a gap that meaningful use policy is not well positioned to impact (i.e., the capabilities of a recipient of electronically transmitted health information). To do this, we propose to adopt a ``performance standard'' that would require EHR technology to successfully electronically process validly formatted Consolidated CDAs no less than 95% of the time. Note that this creates different capability requirements for certification within this criterion for ``receive'' than it does for the capabilities associated with creation of a Consolidated CDA for transmission. In other words, for certification, EHR technology would be permitted to create a Consolidated CDA that conformed to a particular and acceptable variation of the Consolidated CDA standard (given the optionality in the standard). However, for receipt of Consolidated CDAs, EHR technology would need to be able to receive no less than 95% of all of the possible variations that could be implemented under the standard. We also clarify that this performance standard's scope would be limited to the Consolidated CDAs' implementation of the data we require in this certification criterion (i.e., testing for the performance standard would not go beyond the header requirements and specific data required by the certification criterion). This proposed outcome has the effect of requiring EHR technology to be resilient when it comes to receiving Consolidated CDAs that have been configured differently (i.e., able to handle differently formatted Consolidated CDA without failing). While it is not unreasonable (from a user's perspective) to expect their EHR technology to perform with 99% or greater accuracy when it comes to processing Consolidated CDAs, we believe that 95% would be an appropriate initial performance threshold to adopt while still ensuring that users are not adversely impacted by poor performance. As discussed in the S&CC January 2010 interim final rule (75 FR 2021), we defined the term ``standard'' in 45 CFR 170.102 and stated, ``[w]e believe the types of standards envisioned by Congress in the HITECH Act that would be most applicable to HIT are standards that are technical, functional, or performance-based.'' Accordingly, we propose to adopt this new performance standard in section 212 of part 170 entitled ``Performance Standards for Health Information Technology.'' Further, we propose to reference this performance standard in the proposed 2015 Edition ToC certification criterion as a capability that must be demonstrated to meet the certification criterion. We seek comment on whether the performance level should be set to 95% and request that commenters provide accompanying rationale for why it should be lower or higher. Further, our early thoughts around the testing approach for this part of the certification criterion are that it would involve EHR technology receiving some number of Consolidated CDAs (e.g., 100 to 1000) each formatted slightly (but validly) differently, or produced by different EHR technologies previously through testing, or both. Given that testing could be conducted in numerous different ways, we seek input on and suggestions on the best way(s) to test this proposal. We also seek input from industry stakeholders on the best ways to identify additional guidance for the Consolidated CDA that will further reduce its implementation variability and, ultimately, make achieving this performance standard simply a byproduct of implementing a tightly specified implementation guide. While there is still a risk that EHR technology developers could deploy electronic transmission capabilities in ways that continue to make it difficult for EPs, EHs, and CAHs to exchange Consolidated CDAs with EHR technologies designed by different EHR technology developers, we believe that this proposal in combination with potential future proposals in MU to increase electronic exchange requirements can achieve the overall outcome EPs, EHs, and CAHs expect--that they will be able to exchange summary care records and upon receipt be able to use them without additional burden. ``Create'' and Patient Matching Data Quality In 2011, both the HITPC and HITSC made recommendations to ONC on patient matching. The HITPC made recommendations in the following five categories: Standardized formats for demographic data fields, internally evaluating matching accuracy, accountability, developing, promoting and disseminating best practices, and supporting the role of the individual/patient.\46\ The HITSC made four recommendations: Detailing patient attributes that could be used for matching (in order to understand the standards that are needed), data quality, formats for these data elements, and what data are returned from a match request.\47\ The standards recommended by the HITSC are as follows: --------------------------------------------------------------------------- \46\ https://www.healthit.gov/sites/default/files/hitpc-transmittal-letter-priv-sectigerteam-020211.pdf. \47\ https://www.healthit.gov/FACAS/sites/default/files/standards-certification/8_17_2011Transmittal_HITSC_Patient_Matching.pdf. --------------------------------------------------------------------------- Basic Attributes: Given Name; Last Name; Date of Birth; Administrative Gender.\48\ --------------------------------------------------------------------------- \48\ Despite its inclusion of the word ``gender,'' ``Administrative Gender'' is generally used in standards to represent a patient's ``sex'' as male, female, or undifferentiated. See: https://ushik.ahrq.gov/ViewItemDetails?system=hitsp&itemKey=83680000. --------------------------------------------------------------------------- Other Attributes: Insurance Policy Number; Medical Record Number; Social Security Number (or last 4 digits); Street Address; Telephone Number; Zip Code. [[Page 10900]] Potential Attributes: Email Address; Voluntary Identifiers; Facial Images; Other Biometrics. In July 2013, ONC launched an initiative to reinvigorate public discussion around patient matching, to perform a more detailed analysis of patient matching practices, and to identify the standards, services, and policies that would be needed to implement the HITPC and HITSC's recommendations. Although this initiative's first phase focused on a common set of patient attributes that could be leveraged from current data and standards referenced in our certification criteria, we recognize that additional, broader industry needs exist when it comes to methods related to patient matching and the attributes with which matching is performed. Some of these broader needs include the ability to link patient data across time for a longitudinal record, linking across different data sources in a health information exchange organization/network, and linking administrative data to clinical data for outcomes research. Additionally, new matching techniques that are beginning to leverage novel and large data sources suggest that now is the right time to review patient matching needs across the industry at large and how EHR technology can be one part of the solution. Given these initial findings, we propose to include a limited set of standardized data as a part of the ``Create'' portion of the ToC criterion to improve the quality of the data included in outbound summary care records. We seek comment on additional data to include and other constraints that could be applied to this data to improve its quality. To be clear, this proposal does not require EHR technology to capture the data upon data entry, but rather at the point when the data is exchanged (an approach commonly used for matching in HL7 transactions, IHE specifications,\49\ Consolidated CDA (C-CDA) specification, and the eHealth Exchange). The proposed standardized data include: First name, last name, middle name (or middle initial in cases where only it exists/is used), suffix, date of birth, place of birth, maiden name, current address, historical address, phone number, and sex. Additional feedback we have received suggests that use of data elements that do not change over time (e.g., place of birth, maiden name) could improve the patient matching results. In the bulleted list below, we identify more constrained specifications for some of the standardized data we propose. Based on our own research, we do not believe that the proposed constraints to these data conflict with the Consolidated CDA. That being said, some proposed constraints may further restrict the variability as permitted by existing specifications and others may create new restrictions that do not currently exist within the Consolidated CDA. We propose that: --------------------------------------------------------------------------- \49\ https://www.ihe.net/Technical_Frameworks/. --------------------------------------------------------------------------- For ``last name/family name'' the CAQH Phase II Core 258: Eligibility and Benefits 270/271 Normalizing Patient Last Name Rule version 2.1.0 \50\ (which addresses whether suffix is included in the last name field) be followed. --------------------------------------------------------------------------- \50\ https://www.caqh.org/pdf/CLEAN5010/258-v5010.pdf. --------------------------------------------------------------------------- For ``suffix,'' that the suffix should follow the CAQH Phase II Core 258: Eligibility and Benefits 270/271 Normalizing Patient Last Name Rule version 2.1.0 (JR, SR, I, II, III, IV, V, RN, MD, Ph.D., ESQ) \51\ and that if no suffix exists, the field should be marked as null. --------------------------------------------------------------------------- \51\ https://www.caqh.org/pdf/CLEAN5010/258-v5010.pdf. --------------------------------------------------------------------------- For ``date of birth,'' that the year, month and date of birth should be required fields while hour, minute and second should be optional fields. If hour, minute and second are provided then either time zone offset should be included unless place of birth (city, region, country) is provided; in the latter local time is assumed. If date of birth is unknown, the field should be marked as null. For ``current address'' and ``historical address,'' be represented in United States Postal Service (USPS) \52\ format. And, if a historical address is unavailable, that the value should be entered as null. --------------------------------------------------------------------------- \52\ https://pe.usps.com/text/pub28/. --------------------------------------------------------------------------- For ``phone numbers,'' the ITU format specified in ITU-T E.123 \53\ and ITU-T E.164 \54\ be followed and that the capture of home, business, and cell phone numbers be allowed.\55\ Further, that if multiple phone numbers are present in the patient's record, all should be included in the Consolidated CDA and transmitted. --------------------------------------------------------------------------- \53\ https://www.itu.int/rec/T-REC-E.123-200102-I/e. \54\ https://www.itu.int/rec/T-REC-E.164-201011-I/en. \55\ https://www.hl7.org/implement/standards/product_brief.cfm?product_id=186. --------------------------------------------------------------------------- For ``sex'' we propose to require developers to follow the HL7 Version 3 Value Set for Administrative Gender, which includes M (Male), (Female) and UN (Undifferentiated) as options.\56\ --------------------------------------------------------------------------- \56\ https://phinvads.cdc.gov/vads/ViewValueSet.action?oid=2.16.840.1.113883.1.11.1. --------------------------------------------------------------------------- We seek comment on the proposed standardized data to improve patient matching, including whether other data or constraints on proposed data should be modified to better support patient matching practices and work flow. For example, stakeholders have suggested that using the United States Postal Service (USPS) ``Address Information'' application program interface (API) that standardizes addresses as a way to ensure addresses are formatted in a consistent manner. While we believe this idea has merit, the USPS terms and conditions \57\ currently appear to exclude this API's use for this purpose because it only permits users to ``use the USPS Web site, APIs and USPS data to facilitate USPS shipping transactions only.'' Similarly, we request comment on how to best handle or anticipate changes to the way in which data may be represented in other rapidly evolving standards approaches. For instance, we are aware that V2 and V3 HL7 standards use an identical format for date of birth, but the more recent Fast Health Interoperable Resources (FHIR) standards framework uses a different format. Others have suggested that we need to adopt international standards for address, for military purposes or for patients who live outside of the U.S., but have health care delivered within the U.S. More specifically, USPS expects numbers for ZIP code. Thus, we would be interested in stakeholder feedback regarding what standards could best support international addresses (for example, ISO 19160-4 \58\ which appears on a trajectory to reference/include to Universal Postal Union (UPU) S42).\59\ --------------------------------------------------------------------------- \57\ https://secure.shippingapis.com/registration/. \58\ https://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=64242. \59\ https://www.upu.int/uploads/tx_sbdownloader/sheetAddressingS42InternationalAddressingStandardsFactSheetEn.pdf. --------------------------------------------------------------------------- In addition, we seek comment on approaches to address other recommendations from the HITSC. For example, data quality is an important aspect of patient matching success. We seek comment on methods that leverage the certification program, ways to test and measure data quality, and approaches to sharing best practices for improving data quality. Finally, we seek comment on additional findings from the 2013 Patient Matching Initiative that include studying non-traditional attributes to understand the potential for matching improvement, developing open source algorithms for testing purposes or use by EHR technology developers, the development of a formalized structure for establishing best practices, advancing consumer engagement with and access to their demographic data [[Page 10901]] and attributes for correction or approval, and developing and/or disseminating options and training materials that improve data quality. Clinical Information Reconciliation and Incorporation MU Objective The EP, EH, or CAH who receives a patient from another setting of care or provider of care or believes an encounter is relevant should perform medication reconciliation. 2015 Edition EHR Certification Criterion Sec. 170.315(b)(2) (Clinical information reconciliation and incorporation) Gap Certification Status Ineligible We propose to adopt a 2015 Edition certification criterion that revises the 2014 Edition version. As discussed in more detail directly above in the 2015 Edition ToC certification criterion section Shifting ``Incorporation'' From ToC to Clinical Information Reconciliation ``reconciliation'' and ``incorporation'' capabilities were referenced in two separate 2014 Edition certification criteria. For the reasons discussed in the 2015 Edition ToC section above, we propose that the 2015 Edition ``clinical information reconciliation and incorporation'' certification criterion include the capabilities that are part of the 2014 Edition ToC certification criterion at Sec. 170.314(b)(1)(A) and (B). Again, we believe that this change will make the workflow designed to meet this certification criterion clearer. We also solicit comment on whether for our 2017 Edition rulemaking we should broaden the data that this certification criterion requires to be reconciled beyond medications, medication allergies, and problems and, if so, what other data we should consider referencing. Additionally, we solicit comment on whether EHR technology should be required to retain the outside/external data source's provenance as part of the incorporation process. Electronic Prescribing MU Objective Generate and transmit permissible prescriptions electronically (eRx). 2015 Edition EHR Certification Criterion Sec. 170.315(b)(3) (Electronic prescribing) Gap Certification Status Eligible We propose to adopt a 2015 Edition certification criterion that is the same as the 2014 Edition version. Incorporate Laboratory Tests and Values/Results MU Objective Incorporate clinical laboratory test results into Certified EHR Technology as structured data. 2015 Edition EHR Certification Criterion Sec. 170.315(b)(4) (Incorporate laboratory tests and values/ results) Gap Certification Status Ineligible We propose to adopt a 2015 Edition that includes the HL7 Version 2.5.1 Implementation Guide: Standards and Interoperability Framework Laboratory Results Interface, Release 1 (US Realm) (S&I Framework LRI) with Errata \60\ in the 2015 Edition ``transmission of electronic laboratory tests and values/results to ambulatory providers'' certification criterion. This IG is the same guide adopted for the equivalent 2014 Edition certification criteria, but with the errata. The errata address technical corrections and clarifications for interoperability with the HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Orders from EHR, DSTU Release 1, US Realm, 2013 \61\ and other laboratory domain IGs. --------------------------------------------------------------------------- \60\ https://www.hl7.org/implement/standards/product_brief.cfm?product_id=279. \61\ We have proposed to adopt this implementation guide for the 2015 Edition ``CPOE for laboratory orders'' certification criterion. --------------------------------------------------------------------------- As compared to the 2014 Edition certification criterion, we also propose more specific requirements for how EHR technology must be capable of electronically displaying the information included in a test report. This specificity would improve the consistency with how laboratory tests and values/results are displayed, which would also assist with laboratory compliance with CLIA as we discuss in more detail earlier in this section (III.A) of the preamble under the ``Computerized Provider Order Entry--Laboratory.'' This functionality would require EHR technology to be capable of displaying the following information included in laboratory test reports it receives: (1) The information for a test report as specified in 42 CFR 493.1291(a)(1) through (a)(3) and (c)(1) through (c)(7); the information related to reference values as specified in 42 CFR 493.1291(d); the information for alerts and delays as specified in 42 CFR 493.1291(g) and (h); and the information for corrected reports as specified in 42 CFR 493.1291(k)(2). We propose to adopt the updated S&I Framework LRI at Sec. 170.205(j)(2), which requires the modification of the regulatory text hierarchy in Sec. 170.205(j) to designate the standard referenced by the 2014 Edition version of this certification criterion at Sec. 170.205(j) to be at Sec. 170.205(j)(1). This regulatory structuring of the IGs would make the CFR easier for readers to follow. Transmission of Electronic Laboratory Tests and Values/Results to Ambulatory Providers MU Objective Provide structured electronic laboratory results to eligible professionals. 2015 Edition EHR Certification Criterion Sec. 170.315(b)(5) (Inpatient setting only--transmission of electronic laboratory tests and values/results to ambulatory providers) Gap Certification Status Ineligible We propose to adopt a 2015 Edition certification criterion that includes the HL7 Version 2.5.1 Implementation Guide: Standards and Interoperability Framework Laboratory Results Interface, Release 1 (US Realm) (S&I Framework LRI) with Errata \62\ in the 2015 Edition ``transmission of electronic laboratory tests and values/results to ambulatory providers'' certification criterion. This IG is the same guide adopted for the equivalent 2014 Edition certification criteria, but with the errata. The errata address technical corrections and clarifications for interoperability with the HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Orders from EHR, DSTU Release 1, US Realm, 2013 \63\ and other laboratory domain IGs. --------------------------------------------------------------------------- \62\ https://www.hl7.org/implement/standards/product_brief.cfm?product_id=279 \63\ We have proposed to adopt this implementation guide for the 2015 Edition ``CPOE for laboratory orders'' certification criterion. --------------------------------------------------------------------------- As compared to the 2014 Edition certification criterion, we also propose to include new functionality that would improve the consistency with how laboratory tests and values/results are sent, received, and displayed. This would also assist with laboratory compliance with CLIA as we discuss in more detail earlier in this section (III.A) of the preamble under the ``Computerized Provider Order Entry--Laboratory.'' This new functionality would require EHR technology to be capable of including in the laboratory test reports it creates for electronic transmission: (1) The information for a test report as specified in 42 CFR 493.1291(a)(1) through (a)(3) and (c)(1) through (c)(7); the information related to reference values as specified in 42 CFR 493.1291(d); the information for alerts and delays as specified in 42 CFR 493.1291(g) and (h); and the information for corrected reports as specified in 42 CFR 493.1291(k)(2). [[Page 10902]] We propose to adopt the updated S&I Framework LRI at Sec. 170.205(j)(2), which requires the modification of the regulatory text hierarchy in Sec. 170.205(j) to designate the standard referenced by the 2014 Edition version of this certification criterion at Sec. 170.205(j) to be at Sec. 170.205(j)(1). This regulatory structuring of the IGs would make the CFR easier for readers to follow. Data Portability MU Objective N/A 2015 Edition EHR Certification Criterion Sec. 170.315(b)(6) (Data portability) Gap Certification Status Ineligible We propose to adopt a 2015 Edition ``data portability'' certification criterion that revises the 2014 Edition version. Our first proposal, for consistency across other certification criteria revisions, is to also have this certification criterion reference the updated Consolidated CDA (Draft Standard for Trial Use, Release 2.0) standard we discuss in more detail in the ToC certification criterion portion of this preamble. Our second proposal (for reasons already provided as part our proposal for the ``implantable device list'' certification criterion) is that EHR technology must be capable of including the UDI(s) for a patient's implantable device(s) as data within a created Consolidated CDA formatted document. We also solicit public comment on the following: (1) Whether we should rename this certification criterion ``data migration.'' Given that the ``view, download, transmit to 3rd party'' certification criterion addresses data availability from a patient's perspective, this certification criterion has always been more focused on data availability from a health care provider's perspective. We believe that a more precise label for this certification criterion could prevent confusion as to its focus. (2) Whether we should consider adding more requirements for the 2017 Edition version of this certification criterion that we would propose in a future rulemaking and what those requirements should be. For example, should this criterion focus on an expanded time boundary to allow for more longitudinal data to be exported and should it reference more data? Can additional electronic notes be included in a data portability requirement with the addition of header metadata to support export/import functions? (3) Whether we should change this certification criterion as part of a 2017 Edition proposal to promote a broader range of use cases, including: (1) Local access/query (i.e., a provider's ability to access their own data through, for example, an API); (2) targeted access/ inter-organizational query (i.e., a provider's ability to query data from another provider or specific location, such as when one provider performs a ``targeted query'' to obtain a patient's information from another provider); and (3) distributed, multi-source access/query (i.e., a provider's ability to disseminate queries to multiple organizations). This change could result in multiple use case specific certification criteria if appropriate. Clinical Quality Measures Electronically Processing eMeasures None of our prior rulemakings have included a proposal to adopt standards and EHR technology capabilities focused on an EHR technology's ability to electronically process clinical quality measures (CQMs). Until now, we did not believe that there were mature enough standards with which the industry had experience. For our 2017 Edition rulemaking, we hope to propose for adoption a certification criterion focused on EHR technology's ability to electronically process CQMs. More specifically, we solicit comment on industry readiness to adopt the HL7 Health Quality Measures Format (HQMF) \64\ standard for representing a clinical quality measure as an electronic document. --------------------------------------------------------------------------- \64\ https://www.hl7.org/implement/standards/product_brief.cfm?product_id=97. --------------------------------------------------------------------------- Quality measures encoded in the HQMF format are referred to as ``eMeasures.'' The standard was first brought to HL7 in 2009 through an initiative led by the National Quality Forum under CMS contract.\65\ HQMF Release 1 (HQMF R1 or R1) defines data elements, structure, metadata, logic, and definitions of quality measures so that measure developers can encode their measures in this format for EHR queries. --------------------------------------------------------------------------- \65\ HL7 Version 3 Standard: Representation of the Health Quality Measures Format (eMeasures), Release 1 (HQMF R1). --------------------------------------------------------------------------- HQMF Release 2 (HQRF R2 or R2) \66\ was published in December 2013 and improves upon the HQMF R1. R2 improves readability using business names, includes logic sub-trees to avoid inline repetition, improves and expands expressivity, replaces poorly understood specific occurrences with set operators, and provides expression language support. Both R1 and R2 provide human-readable components and machine processable components. However, R2 is easier for EHR technology to electronically process compared to the prior version. HQMF R1 is supported in the Cypress \67\ testing tool, CMS Measure Authoring Tool (MAT),\68\ and through XSL Transforms to generate a human readable form of eMeasures. The MAT is a publicly available, web-based tool for measure developers to create eMeasures, and uses the Quality Data Model (QDM) \69\ to define concepts used in quality measures so EHR and other clinical electronic systems can consistently interpret and locate the data required. ONC and CMS intend to upgrade the Cypress testing tool and MAT to support new versions of the standards. --------------------------------------------------------------------------- \66\ HL7 Version 3 Standard: Representation of the Health Quality Measures Format (eMeasure), Release 2 (December 2013) (HQMF R2). \67\ https://projectcypress.org/. \68\ https://www.emeasuretool.cms.gov/. \69\ https://www.qualityforum.org/QualityDataModel.aspx. --------------------------------------------------------------------------- In addition to HQMF R2, the HL7 Version 3 Implementation Guide: Quality Data Model (QDM)-based Health Quality Measure Format (HQMF), Release 1 (US Realm) was published in December 2013 to provide more specific guidance to implementers that are using HQMF R2. The QDM-based IG describes constraints on the HQMF R2 header and body elements and provides a standard structure to construct a quality measure. This promotes more accurate and consistent representation of quality measures for better care. ONC and CMS are currently working with stakeholders to develop a unified set of standards that support both clinical quality measurement and clinical decision support. This includes a unified data model, a unified expression language, and unified meta-data standard. ONC and CMS are also working to modularize components of the existing standards (e.g., separate expression model, separate data model) so that any changes made in the future will affect only the relevant component of the standard, and will not require changes to the entire standard. Furthermore, modularization will allow the industry to swap out or replace components as needed as standards continue to evolve. These unified, modularized standards will likely require updates to already balloted versions of the quality measurement and CDS standards (e.g., HQMF, QRDA, HeD). Pending the availability of these unified standards for the 2017 Edition rulemaking, we anticipate proposing their adoption to more fully standardize CDS and CQM capabilities in EHR technology. We solicit comment on industry support for unified, modularized CDS and CQM standards for the 2017 Edition. We also solicit comment on [[Page 10903]] what we should require EHR technology to be able to demonstrate for certification (e.g., to require that EHR technology be able to electronically process any eCQM formatted in a unified, modularized CQM standard such as a new HQMF standard). To inform our future rulemaking, we also solicit comment on: Recommended testing and certification processes for the electronic processing of eCQMs; A way in which to classify measures so as to select a subset of measures that would be easier and simpler to be electronically processed by EHR technology in testing and certification; The ability/readiness of EHR technology to store and incorporate an eCQM in HQMF R2; The ability/readiness of EHR technology to map the HQMF R2 standard to data within the EHR technology (including medications, laboratory, allergies information). With the industry progress made to date with HQMF, we believe that this proposed rule provides an opportunity to introduce the HQMF standard for public comment. HQMF's broad adoption can help drive industry uptake of electronically processing eMeasures versus manually coding based on the human readable view of the eMeasures. Functions and Standards for CQM Certification To inform our 2017 Edition rulemaking, we solicit comment on what requirements for supplemental data and reporting should be included as part of CQM certification criteria. Quality reporting programs such as those required by states and CMS programs other than the EHR Incentive Programs may require additional supplemental data and capabilities beyond what ONC currently requires for certification. For example, the HIMSS EHR Association (EHRA) issued a letter to CMS in November 2013, citing variances between ONC's certification requirements and a supplemental implementation guide CMS issued ``Hospital Quality Reporting (HQR) Quality Reporting Document Architecture Category I Release 2 Supplementary Implementation Guide.'' \70\ According to EHRA, these variances include, but are not limited to: --------------------------------------------------------------------------- \70\ https://www.qualitynet.org/dcs/BlobServer?blobkey=id&blobnocache=true&blobwhere=1228890124454&blobheader=multipart%2Foctet-stream&blobheadername1=Content-Disposition&blobheadervalue1=attachment%3Bfilename%3DHQR_QRDAr2_DSTU_ImpGdV2_111513.pdf&blobcol=urldata&blobtable=MungoBlobs. --------------------------------------------------------------------------- ``The need to create QRDA-I reports on a per encounter basis rather than per patient, as had been required for certification; The EHR certification number must be assigned to each QRDA submission, an entirely new data element that would need to be added to databases and user interfaces in many cases; The new requirement to include the NPI/TIN for ``associated providers'' when the official Data Element Catalog referenced as a standard by ONC indicated that the NPI would only be required for EPs--again, a new data element with multiple implications for software development and provider usage.'' We also understand that quality reporting programs may require changes to existing standards (e.g., data element changes) that require industry (e.g., HL7) balloting and approval. These standards development timelines may not align with rulemaking cycles and, therefore, create discrepancies between what is required for certification versus what other programs may adopt. To better understand and address this issue in the future, we solicit comment on what specific capabilities, reporting requirements, standards, and data elements ONC should consider for CQM certification going forward. Clinical Quality Measures--Capture and Export MU Objective N/A 2015 Edition EHR Certification Criteria Sec. 170.315(c)(1) (Clinical quality measures--capture and export) 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 in consideration of our upcoming 2017 Edition rulemaking. In the 2014 Edition Final Rule, we required that for certification to 170.314(c)(1) EHR technology be able to export a CQM data file formatted in accordance with the QRDA Category I standard. We solicit public comment on the potential usefulness of broadening the export requirement to also include reference to a QRDA Category II formatted data file, which would address the bulk reporting of quality data that includes the patient level data as outlined in the QRDA Category I report. A QRDA Category II report is a multi-patient-level quality report. Each report contains quality data for a set of patients for one or more quality measures, where the data elements in the report are defined by the particular measure(s) being reported on. Whereas a QRDA Category I report contains only raw applicable patient data, a QRDA Category II report includes flags for each patient indicating whether the patient qualifies for a measure's numerator, denominator, exclusion, or other aggregate data element. These qualifications can be pooled and counted to create the QRDA Category III \71\ report \72\ or the QRDA Category II report can be used for bulk or batch reporting of quality data. --------------------------------------------------------------------------- \71\ ONC has previously adopted the QRDA Categories I and III standards. \72\ QRDA Category III is used to report aggregate quality results (e.g., total number of patients in the numerator, total number of patients in the denominator). --------------------------------------------------------------------------- Clinical Quality Measures--Import and Calculate MU Objective N/A 2015 Edition EHR Certification Criteria Sec. 170.315(c)(2) (Clinical quality measures--import and calculate) Gap Certification Status Eligible We propose to adopt a 2015 Edition certification criterion that is the same as the 2014 Edition version. Clinical Quality Measures--Electronic Submission MU Objective N/A 2015 Edition EHR Certification Criteria Sec. 170.315(c)(3) (Clinical quality measures--electronic submission) Gap Certification Status Eligible We propose to adopt a 2015 Edition certification criterion that is the same as the 2014 Edition version. Clinical Quality Measures--Patient Population Filtering MU Objective N/A 2015 Edition EHR Certification Criteria Sec. 170.315(c)(4) (Clinical quality measures--patient population filtering) Gap Certification Status Ineligible We propose to adopt a new 2015 Edition certification criterion to require filtering of CQMs by patient population characteristics. Some newer CMS reporting programs may require the capability to support additional reporting filters. For example, the CMS Comprehensive Primary Care (CPC) initiative provides financial incentives to primary care providers in primary care practices who coordinate better care for their patients. In the CPC initiative, CMS determines the bonus payment based on the performance of an [[Page 10904]] ``eligible practice site,'' not the individual provider. Similarly, the CMS Pioneer Accountable Care Organization (ACO) Model and Physician Quality Reporting System (PQRS) group practice reporting option (GPRO) provide payment based on ACO and group practice performance, respectively. Therefore, we propose to require that EHR technology be able to record structured data for the purposes of being able to filter CQM results to create different patient population groupings by one or a combination of the following patient characteristics: Practice site and address; Tax Identification Number (TIN), National Provider Identifier (NPI), and TIN/NPI combination; Diagnosis (e.g., by SNOMED CT code); Primary and secondary health insurance, including identification of Medicare and Medicaid dual eligibles; Demographics including age, sex, preferred language, education level, and socioeconomic status. To inform our proposal, we solicit comment on whether current CQM standards (e.g., QRDA Category I and Category III) can collect metadata for the characteristics listed above to filter and create a CQM report for a particular characteristic or combination of characteristics. We also solicit comment on vocabulary standards that could be used to record the characteristics proposed above. Authentication, Access Control, and Authorization MU Objective Protect electronic health information created or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities 2015 Edition EHR Certification Criterion Sec. 170.315(d)(1) (Authentication, access control, and authorization) 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 issue of two-factor authentication to support two use cases: e-prescribing of controlled substances and remote provider access to EHR technology. In both the 2011 and 2014 Edition final rules, ONC's authentication-oriented certification criteria do not require that two-factor authentication be demonstrated as a capability in order to meet our certification criteria. E-Prescribing Controlled Substances In March 2010, the Drug Enforcement Agency (DEA) published an interim final rule entitled ``Electronic Prescriptions for Controlled Substances'' \73\ (75 FR 16236). The rule removed the Federal prohibition against the electronic prescribing of controlled substances and requires a two-factor authentication protocol. Specifically, DEA permits authentication protocols that meet NIST LOA 3.\74\ --------------------------------------------------------------------------- \73\ https://www.deadiversion.usdoj.gov/ecomm/e_rx/faq/faq.htm. \74\ The National Institute of Standards and Technology (NIST) Special Publication 800-63-2 includes recommendations and guidelines for electronic authentication as well as defines four levels of authentication. Level 1 is the lowest assurance and Level 4 is the highest. Assurance Level 3 (LOA Level 3) provides multifactor remote network authentication. https://csrc.nist.gov/publications/drafts/800-63-2/sp800_63_2_draft.pdf. --------------------------------------------------------------------------- More recently, the MU Stage 2 final rule (77 FR 53989-90) provided EPs participating in Stage 2 with an alternative denominator for the e- prescribing measure. This alternative allows EPs who are able to electronically prescribe controlled substances and want to count these prescriptions in the measure to do so. Remote Provider Access to EHR Technology In September 2012, the HITPC made recommendations regarding authentication standards that should be in place by the onset of MU Stage 3.\75\ The HITPC recommended that ONC should move toward requiring multi-factor authentication (meeting LOA 3) by provider users who remotely access protected health information. In its recommendations, the HITPC described remote access to include the following scenarios: ``access from outside of an organization's/ entity's private network, access from an IP address not recognized as part of the organization/entity or that is outside of the organization/ entity's compliance environment, and access across a network any part of which is or could be unsecure (such as across the open Internet or using an unsecure wireless connection).'' --------------------------------------------------------------------------- \75\ https://www.healthit.gov/FACAS/sites/faca/files/transmittal_092512_pstt_recommendations_provider_authentication.pdf. --------------------------------------------------------------------------- Given the DEA's rule and the HITPC recommendations, we seek comment on whether we should consider two-factor authentication requirements for our 2017 Edition rulemaking. Specifically, we seek comment on: (1) Whether we should adopt a general two-factor authentication capability requirement for certification. This requirement could complement e-prescribing of controlled substances requirements and more definitively support security requirements for remote access to EHR technology as well as any other EHR technology uses that may require two factor authentication. Note, given that DEA has its own 3rd-party assessors and available certification process for technology to demonstrate compliance with its rules, we have no intention nor do we believe that it would be prudent to duplicate DEA regulatory requirements in ours. In fact, two ONC-ACBs are also approved by DEA to perform its approved certification process.\76\ --------------------------------------------------------------------------- \76\ https://www.deadiversion.usdoj.gov/ecomm/e_rx/thirdparty.htm. --------------------------------------------------------------------------- (2) Whether the HITPC's recommendations are appropriate and actionable and, if not, what level of assurance should be the minimum required for provider-users seeking remote access to EHR technology. Auditable Events and Tamper-Resistance MU Objective Protect electronic health information created or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities 2015 Edition EHR Certification Criterion Sec. 170.315(d)(2) (Auditable events and tamper-resistance) Gap Certification Status Ineligible We propose to adopt a 2015 Edition ``auditable events and tamper- resistance'' certification criterion that revises the 2014 Edition version. The 2014 Edition ``auditable events and tamper-resistance'' certification criterion requires (at 45 CFR 170.314(d)(2)(ii)) that EHR technology must be set by default to perform the capabilities specified in (d)(2)(i)(A) of the criterion, and where applicable, (d)(2)(i)(B) and/or (C). The certification criterion, however, does not prohibit an EHR technology's audit log from being disabled by a user. Rather, the certification criterion requires access controls to be in place to restrict the ability to disable the audit log to a limited set of identified users and to record the user ID date/time when such a command is executed (45 CFR 170.314(d)(2)(i)(B)) to show who last ``touched'' the audit log before it was disabled. In a 2013 report entitled ``Not All Recommended Safeguards Have Been Implemented in Hospital EHR Technology (OEI-01-11-00570),'' \77\ the HHS Office of the Inspector General (OIG) recommended that we should propose a revision to this certification [[Page 10905]] criterion to ``require that EHR technology keeps the audit log operational whenever the EHR technology is available for updates or viewing.'' Further the OIG stated that we should ``ensure that providers cannot or do not disable audit logs whenever the EHR technology is available for updates or viewing.'' As one basis for this recommendation, OIG found that ``ninety-six percent of hospitals reported that their audit logs remain operational at all times'' despite reporting barriers related to resources, user guides, and training. --------------------------------------------------------------------------- \77\ https://oig.hhs.gov/oei/reports/oei-01-11-00570.pdf. --------------------------------------------------------------------------- In our response to OIG's report, we indicated our concurrence with its recommendation. Accordingly, we propose to adopt a 2015 Edition ``auditable events and tamper-resistance'' certification criterion that is similar to its 2014 Edition version, but that requires EHR technology to prevent all users from being able to disable the audit log through the EHR technology. The phrase ``through the EHR technology'' is meant to limit the scope of this capability to what is in the EHR technology's control and to be consistent with the same scope limitation expressed in the 2014 Edition version of this criterion that we placed on ``audit log protection'' at 170.314(d)(2)(iv) (77 FR 54235). In the past, we had heard from stakeholders that there were reasons (e.g., performance concerns) to allow for audit logs to be disabled. Given that the proposed 2015 Edition certification criterion would prohibit that type of action from being performed in order for the EHR technology to be certified, we seek public comment on the impact and potential unintended consequences of such a change and specific examples where disabling an EHR technology's audit log is warranted. Audit Report(s) MU Objective Protect electronic health information created or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities 2015 Edition EHR Certification Criterion Sec. 170.315(d)(3) (Audit report(s)) 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 whether the ASTM E2147 standard will continue to remain sufficient for EHR technology certification for the 2017 Edition. The standards adopted at 45 CFR 170.210(e) and referenced by the 2014 Edition ``auditable events and tamper-resistance'' and ``audit report(s)'' certification criteria require that EHR technology must be able to record audit log information as specified in sections 7.2 through 7.4, 7.6 and 7.7 of the standard adopted at 45 CFR 170.210(h). The standard adopted at 45 CFR 170.210(h) is ASTM E2147. Section 7.6 of ASTM E2147 specifies that audit log content needs to include the ``type of action'' and references six ``actions:'' additions, deletions, change, queries, print, and copy. Section 7.7 requires that the audit log record when patient data is accessed. So while not explicitly referenced in section 7.6, the action of ``access'' or viewing of a patient's information is also required to be recorded for certification. Since the 2014 Edition Final Rule was published, we have received stakeholder feedback and questions regarding the actions specified at section 7.6 and their relationship to testing and certification in specific situations. Generally, these situations all pertained to stakeholders seeking confirmation that they should not have to support the auditing of capabilities that the EHR technology was not designed to perform. Specifically, stakeholders asked if EHR technology could still be certified if it were designed without one of the actions specified by the standard. For instance if the EHR technology did not include a ``copy'' function, did the EHR technology developer still need to design the audit log capability to record the ``copy'' action. It was not our intention to require EHR technology developers to add in audit log functionality solely for certification purposes. We have interpreted this certification criterion requirement to mean that if the EHR technology does not include a capability for which an ``action'' is listed that testing and certification can proceed for the audit log process without EHR technology showing that it can record actions related to a non-existent capability. Any exception such as this for 2014 Edition testing is to be documented in the test report issued for the EHR technology, which is made publicly accessible on the Certified HIT Products List (CHPL) with the EHR technology. Stakeholder feedback on this 2014 Edition certification criterion has brought up three issues on which we solicit public comment: (1) The ``query'' action in section 7.6 of the ASTM E2147 standard is not a defined term in the standard's definition section (See section 3). As a result, we seek comment on whether this ambiguity has caused additional burden or challenges for EHR technology developers and how EHR technology developers have interpreted the term when designing their EHR technology. We also solicit comment on industry knowledge related to any plans to revise ASTM E2147 to address this ambiguity. (2) Whether we should establish a minimum/baseline set of actions that EHR technology must always be capable of being audited. For instance, we could see the potential for ``copy,'' ``print,'' and ``query'' capabilities to not be included in certain EHR technologies. Thus, we could set a baseline that within section 7.6's actions, EHR technology must always support ``additions, deletions, and changes.'' (3) Are there other actions that we should consider specifying in an updated standard for the 2017 Edition that the current standard does not sufficiently address, such as the act of ``transmission''? We do not favor this approach because implementing it in regulation would cause us to add to the existing standard. Thus, we seek feedback on whether the standard is sufficiently up-to-date and appropriately specifies all of the actions necessary for EHR audit logs to capture. (4) Finally, we seek comment on whether there are any alternative standards to ASTM E2147 that we should consider in light of the aforementioned concerns and ambiguities. Amendments; Automatic Log-Off; Emergency Access; End-User Device Encryption; Integrity MU Objective Protect electronic health information created or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities 2015 Edition EHR Certification Criteria Sec. 170.315(d)(4) (Amendments) Sec. 170.315(d)(5) (Automatic Log-Off) Sec. 170.315(d)(6) (Emergency access) Sec. 170.315(d)(7) (End-User Device Encryption) Sec. 170.315(d)(8) (Integrity) Gap Certification Status Eligible (all five referenced) We propose to adopt 2015 Edition EHR certification criteria that are the same as the 2014 Edition versions for all five of these certification criteria. Accounting of Disclosures MU Objective Protect electronic health information created or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities 2015 Edition EHR Certification Criterion [[Page 10906]] Sec. 170.315(d)(9) (Accounting of Disclosures) Gap Certification Status Eligible We propose to adopt 2015 Edition certification criterion that is the same text as the 2014 Edition version. However, given our proposal to discontinue the Complete EHR concept and the associated regulatory definition (discussed later in this preamble), we also propose to remove the ``optional'' designation from this certification criterion as part of the 2015 Edition because such a designation would no longer be necessary. Further, we propose to continue to exclude it from the Base EHR definition in order to maintain policy consistency with the 2014 Edition and for the reasons discussed in our prior rulemakings regarding why we made it ``optional'' and excluded it from the Complete EHR definition. View, Download, and Transmit to Third Party MU Objective EPs Provide patients, and their authorized representatives, the ability to view online, download, and transmit their health information within 4 business days of the information being available to the EP EHs and CAHs Provide patients, and their authorized representative, the ability to view online, download, and transmit information about a hospital admission 2015 Edition EHR Certification Criterion Sec. 170.315(e)(1) (View, download, and transmit to third party) Gap Certification Status Ineligible We propose to adopt a 2015 Edition criterion that revises the 2014 Edition version. The 2014 Edition View, Download and Transmit to Third Party (VDT) certification criterion requires EHR technology to provide patients (and their authorized representatives) with a secure online means to view, download, and transmit their health information to a 3rd party of their choice. It also requires EHR technology to keep an activity history log of the date and time a view, download, or transmission occurred and by whom. For the 2015 Edition version of this criterion, we propose several changes. Clarified Introductory Text We propose to make clarifying changes to the introductory text at 170.315(e)(1) to make it clear that this EHR technology capability is patient facing and for patients to use. Accordingly, we propose to revise the introductory text to lead with ``Patients (and their authorized representatives) must be able to use EHR technology to. . . .'' We also propose to use this same phrase at the beginning of each specific capability for VDT to reinforce this point. For the same reasons discussed in the proposed 2015 Edition ToC certification criterion, we propose to reference the updated version of the Consolidated CDA (Draft Standard for Trial Use, Release 2.0), which we propose for adoption in this certification criterion. Removing Ambiguity from ``Download'' We propose to revise the language for ``download'' to leave no room for any alternative interpretation. Specifically, we propose revising that language to stress that a patient must be able to download an ambulatory or inpatient summary in only the human readable format if they just want that, in only the Consolidated CDA format if they just want that, or in both formats if they want both. Although the 2014 Edition Final Rule's preamble for the 2014 Edition of this criterion expressed that a patient needed to be able to download either as their choice (meaning that EHR technology needed to support both methods), the ``or'' in the regulation text and our avoidance of using ``and/or'' (which can be equally confusing) led stakeholders to misinterpret the requirement's meaning when not read with the preamble. Decoupling Transport and Content For the same above-noted reasons we provide in the proposed 2015 Edition ToC certification criterion, we propose to ``decouple'' the transport and content capabilities in the 2015 Edition version of VDT. Similar to the ToC revisions, this certification criterion will now focus on content requirements and EHR technology's ability to demonstrate conformance with the IG for Direct Edge Protocols and enable a successful transmission. Certification for transmit is now a separate stand-alone requirement that can support ToC as well as VDT. The proposed requirements at Sec. 170.315(e)(1)(i)(C): (1) clearly express the need to support a patient's ability to choose the destination to whom they want to send their health information; and (2) would require that EHR technology enable a patient to accomplish a transmission (of their own health information) that conforms to the IG for Direct Edge Protocols and is used by a service that has implemented the primary Direct Project specification. By ``accomplish,'' we clarify that our expectation and our anticipated approach through testing would be that the transmitted Consolidated CDA arrives at its destination. This change would permit EHR technology developers seeking testing and certification to this proposed criterion to demonstrate compliance with the transmission requirement without having to be a HISP. They would, however, need to show that they can connect to one by conforming to the IG for Direct Edge Protocols and that the HISP successfully transmitted the ambulatory summary or inpatient summary to the patient's specified destination using the Direct Project specification. Demonstrating this outcome could be expedited if the EHR technology developer uses a service that is certified to enable health information to be electronically transmitted in accordance with the primary Direct Project specification (under our new proposal for this to be a separate certification criterion). We clarify that the phrase ``[e]nter a 3rd party destination of their choice'' in the certification criterion does not require EHR technology to support every possible method a patient could conceivably choose. Rather, EHR technology must be able to support at least the entry of any ``Direct address,'' which is the minimum required by this certification criterion. We also note that from our perspective it is unacceptable for this transmission capability to in any way limit a patient's ability to send their health information to any existing and working ``Direct address.'' We seek comment on whether we should require another transmission method as part of this certification criterion in addition to the one just discussed. Updated Consolidated CDA Version We propose, for consistency across other certification criteria revisions, to also have this certification criterion reference the updated Consolidated CDA standard (Draft Standard for Trial Use, Release 2.0) we discuss in more detail in the ToC certification criterion portion of this preamble. Similarly, we propose (for reasons already provided as part our proposal for the ``implantable device list'' certification criterion) that EHR technology must be capable of including the UDI(s) for a patient's implantable device(s) as data within a created Consolidated CDA formatted document. View As discussed in our proposal for the 2015 Edition ``implantable device list'' [[Page 10907]] certification criterion, we propose to add ``implantable device information'' as data that EHR technology would need to be capable of making available to a patient under the ``view'' capability. Activity History Log We propose to include two new data points in the 2015 Edition VDT criterion related to the activity history log. We propose that the addressee to whom an ambulatory summary or inpatient summary was transmitted and whether that transmission was successful (or failed) be recorded. Although the 2014 Edition VDT criterion requires that the action of ``transmit'' be recorded, we did not specify that the intended destination be recorded. We believe this transactional history is important for patients to be able to access, especially if they actively transmit their health information to a 3rd party or another health care provider. WCAG 2.0 Level AA Consistent with our belief that all patients should have an equal opportunity to access their electronic health information without barriers or diminished functionality or quality, we proposed in the 2014 Edition NPRM (77 FR 13840) that the viewing capability for VDT must meet Level AA conformance with the most recent set of the Web Content Accessibility Guidelines (WCAG). The most recent set of guidelines (WCAG 2.0) were published in 2008 \78\ and are organized under 4 central principles with testable ``success criteria:'' Perceivable, Operable, Understandable, and Robust. Each guideline offers 3 levels of conformance: A, AA, and AAA. WCAG 2.0 Level A (Level A) conformance corresponds to the most basic requirements for displaying Web content. WCAG 2.0 Level AA (Level AA) conformance provides for a stronger level of accessibility by requiring conformance with Level A success criteria as well as Level AA specific success criteria. WCAG 2.0 Level AAA (Level AAA) conformance comprises the highest level of accessibility within the WCAG guidelines and includes all Level A and Level AA success criteria as well as success criteria unique to Level AAA. --------------------------------------------------------------------------- \78\ https://www.w3.org/TR/WCAG20/. --------------------------------------------------------------------------- In the 2014 Edition Final Rule (77 FR 54179) we considered public comment and ultimately adopted Level A for accessibility, but indicated our interest in raising this bar over time. As a result, we propose for the 2015 Edition VDT criterion that EHR technology be compliant with Level AA. We propose to adopt this standard at Sec. 170.204(a)(2). Note, to implement this proposal, we would have to modify the regulatory text hierarchy in Sec. 170.204 to designate the accessibility standard referenced by the 2014 Edition VDT certification criterion at Sec. 170.204(a) to be at Sec. 170.204(a)(1). Level AA provides a stronger level of accessibility and addresses areas of importance to the disabled community that are not included in Level A. For example, success criteria unique to Level AA include specifications of minimum contrast ratios for text and images of text, and a requirement that text can be resized without assistive technology up to 200 percent without loss of content or functionality. We recognize that Level AA is a step up from Level A and request public comment on whether there are particular key elements of Level AA that we could adopt as hybrid between Level A and AA in an effort to prioritize key focus areas for accessibility improvements. We also understand that there are not separate guidelines for ``mobile accessibility'' and that mobile is considered by the W3C Web Accessibility Initiative to be covered by the WCAG 2.0 guidelines.\79\ Further, we would note that in September 2013, the W3C published a working group note consisting of ``Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT).'' \80\ We request public comment (especially from EHR technology developers that have sought or considered certification to the 2014 Edition VDT certification criterion with a ``non-web'' application) on what, if any, challenges exist or have been encountered when applying the WCAG 2.0 standards. --------------------------------------------------------------------------- \79\ https://www.w3.org/WAI/mobile/. \80\ https://www.w3.org/TR/wcag2ict/. --------------------------------------------------------------------------- 2017 Edition Issues for the VDT Certification Criterion under Consideration Images and Non-Text Data In the 2014 Edition NPRM we proposed to require EHR technology to be capable of enabling images formatted according to the Digital Imaging and Communications in Medicine (DICOM) standard to be downloaded and transmitted to a third party (77 FR 13840). We stated our belief that this specific capability has the potential to empower patients to play a greater role in their own care coordination and could help assist in reducing the amount of redundant and duplicative imaging-oriented tests performed. In response to public comment, however, we did not adopt this proposal. In considering improvements that could be made to the VDT certification criterion for the 2017 Edition, we request public comment on whether we should again propose to require that images be part of this criterion. More specifically, we seek comment on: (1) Whether images for patients need to be of diagnostic quality; (2) whether they should be viewable and downloadable, but not required to be transmitted; and (3) whether cloud-based technology could allow for a link to the image to be made accessible. We also seek comment on other non-text data that we could require EHR technology to be able to make available to patients such as ECG waveforms. ``OpenNotes'' We also solicit public comment on whether a 2017 Edition VDT certification criterion should enable ``OpenNotes'' \81\ functionality for EPs, EHs, and CAHs, to give patients the ability to gain access to their visit notes. The OpenNotes initiative was led by Beth Israel Deaconess Medical Center through a grant from the Robert Wood Johnson Foundation whereby ``researchers undertook a year-long trial of OpenNotes in which 105 doctors shared their notes with more than 19,000 patients in Boston, rural Pennsylvania, and Seattle.'' \82\ Additionally, in April 2013, the Department of Veterans Affairs announced that it had enabled OpenNotes through its My HealtheVet Blue Button.\83\ --------------------------------------------------------------------------- \81\ https://www.myopennotes.org/what-is-opennotes-2/. \82\ https://www.rwjf.org/en/grants/grantees/OpenNotes.html. \83\ https://www.rwjf.org/en/blogs/pioneering-ideas/2013/04/why_the_va_embraces.html. --------------------------------------------------------------------------- Clinical Summary MU Objective Provide clinical summaries for patients for each office visit 2015 Edition EHR Certification Criterion Sec. 170.315(e)(2) (Ambulatory setting only--clinical summary) Gap Certification Status Ineligible We propose to adopt a 2015 Edition ``clinical summary'' certification criterion that revises the 2014 Edition version. Specifically, we propose to reflect the clarifications we provided in FAQ 33,\84\ require the use of CVX codes for immunizations, and reference the updated Consolidated CDA version (Draft Standard for Trial Use, Release 2.0) in this criterion for consistency across our 2015 Edition and for the [[Page 10908]] other reasons stated already in the proposed 2015 Edition ToC certification criterion. We also propose (for reasons already provided as part our proposal for the ``implantable device list'' certification criterion) that EHR technology must be capable of including the UDI(s) for a patient's implantable device(s) as data within a created Consolidated CDA formatted document. --------------------------------------------------------------------------- \84\ https://www.healthit.gov/policy-researchers-implementers/33-question-12-12-033. --------------------------------------------------------------------------- The regulation text of the 2015 Edition ``clinical summary'' certification criterion clarifies that for medications administered during the visit, diagnostic tests pending after the visit and future scheduled tests, EHR technology must demonstrate the capability to represent the data using the specified vocabulary standard, where appropriate. FAQ 33 encourages the use of CVX codes for immunizations since the code set was not actually specified in the 2014 Edition ``clinical summary'' certification criterion. To correct this oversight, the 2015 Edition ``clinical summary'' certification criterion specifically includes the required use of CVX codes for immunizations. For diagnostic tests pending and future scheduled tests, we propose to require the use of LOINC[supreg]. We request comment, however, on whether LOINC[supreg] can be used to represent all possible diagnostic tests pending and future scheduled tests. We also reiterate the situational dependency (office visit dependent) of certain data that the EHR technology must be able to provide, and limit, in the clinical summary to meet the proposed 2015 Edition certification criterion as well as the 2014 Edition ``clinical summary'' certification criterion. Although the regulation text for medications, diagnostic tests pending, and future scheduled tests may seem redundant with the Common MU Data Set, this data along with immunizations is specified separately because EHR technology must have the capability to limit this data in a clinical summary it creates to only those medications and immunizations administered during the visit and/or the diagnostic tests pending and future scheduled tests after the visit. In terms of customization of the clinical summary, this permits the user to limit this data in the clinical summary if so desired by the user. While providing historical data for medications, immunizations, and diagnostic tests in the clinical summary may be of benefit in certain instances, EHR technology is not required to have these capabilities to meet the certification criterion. This certification criterion, like the 2014 Edition ``clinical summary'' certification criterion, is meant to support the associated MU objective and measure that seeks to provide a patient with a record of the visit and specific lab tests or specific follow-up actions and treatment related to the visit. Secure Messaging MU Objective Use secure electronic messaging to communicate with patients on relevant health information 2015 Edition EHR Certification Criterion Sec. 170.315(e)(3) (Ambulatory setting only--secure messaging) Gap Certification Status Eligible We propose to adopt a 2015 Edition certification criterion that is the same as the 2014 Edition version. Immunization Information MU Objective Capability to submit electronic data to immunization registries or immunization information systems except where prohibited, and in accordance with applicable law and practice 2015 Edition EHR Certification Criterion Sec. 170.315(f)(1) (Immunization information) Gap Certification Status Eligible We propose to adopt a 2015 Edition certification criterion that is the same as the 2014 Edition version. Transmission to Immunization Registries MU Objective Capability to submit electronic data to immunization registries or immunization information systems except where prohibited, and in accordance with applicable law and practice 2015 Edition EHR Certification Criterion Sec. 170.315(f)(2) (Transmission to immunization registries) Gap Certification Status Ineligible We propose to adopt a 2015 Edition certification criterion that revises the 2014 Edition version. The 2014 Edition EHR certification criterion for transmission to immunization registries at Sec. 170.314(f)(2) references the following IG for immunization messaging: HL7 Version 2.5.1: Implementation Guide for Immunization Messaging, Release 1.4. Since the publication of the 2014 Edition Final Rule, CDC has issued an updated IG (HL7 Version 2.5.1: Implementation Guide for Immunization Messaging, Release 1.5) that promotes greater interoperability between immunization registries and EHR technologies. Release 1.5 focuses on known issues from the previous release and revises certain HL7 message elements to reduce differences between states and jurisdictions for recording specific data elements. Specifically, Release 1.5 \85\: --------------------------------------------------------------------------- \85\ This IG will be available for review during the public comment period at https://www.cdc.gov/EHRmeaningfuluse/guides.html. --------------------------------------------------------------------------- Clarifies and tightens conformance statements; corrects ACK (acknowledgment) messages to support improved messaging back to the EHR about the success/failure of a message; includes query and response changes such as V2.7.1 MSH user constraints, minimum requirements for a response message, and corrected profiles for response to errors and no match situations. We believe these improvements are important to the IG and will continue to support our ultimate goal for this certification criterion--bidirectional immunization data exchange. Given the improvements included in the updated IG, we propose to adopt it at Sec. 170.205(e)(4) and include it in the 2015 Edition ``transmission to immunization registries'' certification criterion at Sec. 170.315(f)(2). We have received stakeholder comments that the immunization registry community is moving toward, but has not yet developed fully mature standards for bidirectional data exchange that include immunization forecasting/CDS. We seek public comment on the maturity of bidirectional immunization data exchange activities and whether we should propose to include bidirectional immunization data exchange as part of the 2015 Edition and/or 2017 Edition. National Drug Codes for Vaccine Coding Our 2014 Edition requires the use of the CVX codes \86\ to record vaccines administered.\87\ CDC developed and maintains the list of CVX codes. The National Drug Code (NDC) vocabulary serves as a universal product identifier for drugs, and FDA publishes the list of NDC numbers as part of the NDC Directory.\88\ In our 2011 Edition final rule, commenters noted that they were not aware of a mapping from NDC to CVX codes (75 FR 44614), and we did not believe that NDC codes were appropriate for representing immunizations at the time. However, since then CDC has begun a process to map National Drug Codes (NDC) to CVX [[Page 10909]] codes.\89\ Stakeholders have expressed support for moving to NDC codes for vaccines because NDC codes: --------------------------------------------------------------------------- \86\ https://www2a.cdc.gov/vaccines/iis/iisstandards/vaccines.asp?rpt=cvx. \87\ Sec. 170.314(b)(2), Sec. 170.314 (b)(7), and Sec. 170.314(e)(2). \88\ https://www.fda.gov/drugs/informationondrugs/ucm142438.htm. \89\ https://www2a.cdc.gov/vaccines/iis/iisstandards/vaccines.asp?rpt=ndc. --------------------------------------------------------------------------- Are used for pharmaceutical inventory management within immunization registries, and therefore built into the immunization workflow; Are built into 2D barcodes which have been successfully piloted for vaccines (see comment solicitation for 2D barcoding for more information); Can improve safety with better specificity of vaccine formulation. In addition, FDA has worked with HL7 to improve assignment of NDC codes to vaccines to reduce the reuse of NDC codes, an issue which has presented itself in the past. NDC codes are structured in three parts: labeler, product, and packaging subcodes. Thus, historical vaccinations cannot be recorded using NDC codes because the exact formulation (e.g., product portion) is usually unknown. For example, a patient may report that he or she received the influenza vaccine one year ago, but does not know which influenza vaccine he or she received. We are aware of two possible solutions to record historical vaccinations if we were to move to replace CVX with NDC codes: Option 1: Continue to use CVX codes for historical vaccinations only; Option 2: Use the NDC syntax and create a new value set for the product portion of the code for vaccines of unspecified formula (e.g., influenza vaccine of unspecified formula) for historical vaccinations (resulting in an ``NDC-like'' code). Given these issues, we solicit comment for the 2017 Edition on whether we should move to using NDC codes for vaccines to replace CVX and the preferred option for recording historical immunizations. We also solicit comment on other vocabularies that could be used to replace CVX. For example, we currently require RxNorm for medications and medication allergies in the 2014 Edition. We are aware that RxNorm codes include NDC codes as attributes, and it is possible to go from an NDC to an RxNorm standard normalized name.\90\ Last, in our 2011 Edition final rule, we noted that CPT codes were not a better alternative to CVX because CPT codes are used for billing purposes and there is a public mapping of CPT to CVX codes \91\ (75 FR 44614). --------------------------------------------------------------------------- \90\ See ``Where does RxNorm get its data?'' at https://www.nlm.nih.gov/research/umls/rxnorm/overview.html. \91\ https://www2a.cdc.gov/vaccines/iis/iisstandards/vaccines.asp?rpt=cpt. --------------------------------------------------------------------------- Transmission to Public Health Agencies--Syndromic Surveillance MU Objective Capability to submit electronic syndromic surveillance data to public health agencies except where prohibited, and in accordance with applicable law and practice Revised 2014 Edition EHR Certification Criterion Sec. 170.314(f)(3) (Transmission to public health agencies-- syndromic surveillance) 2015 Edition EHR Certification Criterion Sec. 170.315(f)(3) (Transmission to public health agencies-- syndromic surveillance) Gap Certification Status Ineligible if certified prior to the effective date of the 2015 Edition Final Rule Eligible if certified after the effective date of the 2015 Edition Final Rule We propose to revise the 2014 Edition syndromic surveillance certification criterion and adopt an identical 2015 Edition version. Electronic syndromic surveillance data is valuable for early detection of outbreaks, monitoring disease and condition trends, and providing reassurance that an outbreak has not occurred. Syndromic surveillance can also inform community efforts to track and control chronic conditions. For both MU Stages 1 and 2, EPs may choose the ``electronic syndromic surveillance data'' objective under the menu set. In the MU Stage 2 final rule, CMS stated that very few public health agencies were accepting syndromic surveillance data from ambulatory, non-hospital providers, and there was no corresponding IG available at the time of the final rule's publication (77 FR 54025). They also noted that the CDC was working with the syndromic surveillance community to develop a new IG for ambulatory reporting of syndromic surveillance data, which was expected to be published in spring 2013. Only a few public health agencies are currently accepting syndromic surveillance data from the ambulatory setting using HL7 2.5.1. Due to lack of demand, the CDC no longer plans to develop an HL7 2.5.1 IG for ambulatory reporting of syndromic surveillance data. Without such an IG most public health agencies will not have enough specific guidance to build systems to receive syndromic surveillance data from the ambulatory setting formatted to HL7 2.5.1. The MU Stage 2 final rule states that an EP, EH, or CAH may claim an exclusion if the public health agency does not have the capacity to accept reporting (77 FR 54021). Thus, many EPs may qualify for an exclusion for this objective and associated measure and, as a result, would need to choose another objective from the menu set on which to report. Given the lack of an ambulatory IG for HL7 2.5.1, we propose to revise the 2014 Edition certification criterion. The proposed revisions to the 2014 Edition certification criterion would allow EHR technology designed for the ambulatory setting to be certified to alternative standards that support other modes of electronic syndromic surveillance data submission. In this regard, we are aware that syndromic surveillance data is currently being sent to public health agencies through new query-based models, including the QueryHealth initiative.\92\ Query-based models take patient level data, de-identify it, and aggregate it for population health use. We understand that these query-based models use HL7 CDA and QRDA III standards, and do not necessarily use the HL7 2.5.1 standard. CDA and QRDA III standards were adopted and referenced by 2014 Edition certification criteria and, as a result, have become more widely implemented. --------------------------------------------------------------------------- \92\ https://wiki.siframework.org/Query+Health. --------------------------------------------------------------------------- In light of the potential that many EPs may qualify for an exclusion for the MU objective and associated measure with which this certification criterion correlates, we seek to make available additional electronic syndromic surveillance submission capabilities in order to better support their opportunity to receive credit for the syndromic surveillance MU objective. Therefore, we propose to revise the 2014 Edition syndromic surveillance certification criterion at Sec. 170.314(f)(3) to include the HL7 CDA and QRDA III standards as alternative standards to HL7 2.5.1 for EHR technology certification designed for the ambulatory setting. We propose to revise the 2014 Edition syndromic surveillance certification criterion by replacing the referenced IG for the HL7 2.5.1 standard (for the inpatient setting) with an updated version that incorporates an addendum clarifying conformance guidance. Specifically, we propose to move to the updated implementation specification PHIN Messaging Guide for Syndromic Surveillance: Emergency Department, Urgent Care, and Inpatient Settings, Release 1.9 (April 2013) \93\ and adopt it at Sec. 170.205(d)(4). We believe that HL7 2.5.1 is the only appropriate standard for inpatient setting certification as an IG exists and many hospitals and public [[Page 10910]] health agencies are using the standard to exchange syndromic surveillance data. The alternative HL7 CDA and QRDA III standards we propose to include in the revised 2014 Edition syndromic surveillance certification criterion for the ambulatory setting are standards we have already adopted as part of the 2014 Edition. With respect to the HL7 CDA standard, we also propose to adopt it at Sec. 170.205(d)(5), which is under the specific syndromic surveillance hierarchy in our regulation text. The proposed adoption of this standard here is meant to clearly indicate the transmission to which this standard is to be applied. --------------------------------------------------------------------------- \93\ https://www.cdc.gov/phin/library/guides/PHIN%20MSG%20Guide%20for%20SS%20Final_508readyRelease1_9%2004%2027%202013.pdf. --------------------------------------------------------------------------- We propose to adopt a 2015 Edition syndromic surveillance certification criterion at Sec. 170.315(f)(3) that includes these same standards and is identical to the proposed revised 2014 Edition syndromic surveillance certification criterion. We solicit comment on whether public health agencies are using the QRDA Category I standard to receive query-based syndromic surveillance data, and whether ONC should consider adopting the QRDA Category I standard for the ambulatory setting. The gap certification status indicated in the table for this certification criterion is split because we have proposed to modify the 2014 Edition syndromic surveillance certification criterion. If EHR technology is certified prior to the effective date of a final rule for this 2015 Edition proposed rule, then it will be certified to the current ``unrevised'' version of the 2014 Edition syndromic surveillance certification criterion. EHR technology certified to the ``unrevised'' version of the 2014 Edition syndromic surveillance certification criterion would be ineligible for gap certification to the 2015 Edition syndromic surveillance certification criterion because of the proposed changes to the 2015 Edition syndromic surveillance certification criterion. However, if EHR technology is certified after the effective date of a final rule for this 2015 Edition proposed rule, the EHR technology could be certified to the proposed revised 2014 Edition syndromic surveillance certification criterion. This would then make the EHR technology eligible for gap certification to the 2015 Edition syndromic surveillance certification criterion because the proposed 2015 Edition syndromic surveillance certification criterion would be ``unchanged'' when compared to the proposed revised 2014 Edition syndromic surveillance certification criterion. Transmission of Reportable Laboratory Tests and Values/Results MU Objective Capability to submit electronic reportable laboratory results to public health agencies, except where prohibited, and in accordance with applicable law and practice 2015 Edition EHR Certification Criterion Sec. 170.315(f)(4) (Inpatient setting only--Transmission of reportable laboratory tests and values/results) Gap Certification Status Ineligible We propose to adopt a 2015 Edition certification criterion that revises the 2014 Edition version. We also propose to make a technical amendment to the regulation text for the 2014 Edition criterion in order to have it continue to point to the appropriate standard and implementation specifications (HL7 2.5.1 and HL7 Version 2.5.1: Implementation Guide: Electronic Laboratory Reporting to Public Health, Release 1 with Errata and Clarifications and ELR 2.5.1 Clarification Document for EHR Technology Certification) after we restructure the regulatory text hierarchy at Sec. 170.205(g) to our accommodate our 2015 Edition proposal. Since the publication of the 2014 Edition Final Rule, CDC has issued an updated implementation guide (HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, DSTU, Release 2 (US Realm), 2013) that address technical corrections and clarifications for interoperability with laboratory orders and other laboratory domain implementation guides. Specifically, Release 2: \94\ --------------------------------------------------------------------------- \94\ This IG will be available for review during the public comment period at https://www.cdc.gov/EHRmeaningfuluse/guides.html. --------------------------------------------------------------------------- Corrects errata; Applies conformance statements and condition predicates from the Clarifications and ELR 2.5.1 Clarification Document for EHR Technology Certification; Provides technical corrections; Provides additional guidance and clarifications; Aligns with the current S&I Framework v2 messaging guide in the laboratory space (Release 1 was aligned with the LRI predecessor issued by Healthcare Information Technology Standards Panel). We believe these improvements are important to the IG and will continue to support interoperability. Given the improvements included in the updated IG, we propose to adopt it at Sec. 170.205(g)(2) and include it in the 2015 Edition ``transmission of reportable laboratory tests and values/results'' certification criterion at Sec. 170.315(f)(4). As noted above, to properly codify this proposal in regulation, we would have to modify the regulatory text hierarchy in Sec. 170.205(g) to designate the standard and implementation specifications referenced by the 2014 Edition ``transmission of reportable laboratory tests and values/results'' certification criterion at Sec. 170.205(g)(1) instead of its current designation at Sec. 170.205(g). Cancer Case Information MU Objective Capability to identify and report cancer cases to a State cancer registry, except where prohibited, and in accordance with applicable law and practice 2015 Edition EHR Certification Criteria Sec. 170.315(f)(5) (Ambulatory setting only--cancer case information) Gap Certification Status Eligible We propose to adopt a 2015 Edition EHR certification criterion for cancer case information that is the same as the 2014 Edition version. However, given our proposal to discontinue the Complete EHR concept and associated regulatory definition (discussed later in this preamble), we also propose to remove the ``optional'' designation from this certification criterion as part of the 2015 Edition since such designation would no longer be necessary. Transmission to Cancer Registries MU Objective Capability to identify and report cancer cases to a State cancer registry, except where prohibited, and in accordance with applicable law and practice 2015 Edition EHR Certification Criteria Sec. 170.315(f)(6) (Ambulatory setting only--transmission to cancer registries) Gap Certification Status Ineligible We propose to adopt a 2015 Edition certification criterion for transmission to cancer registries that revises the 2014 Edition version. Given our proposal to discontinue the Complete EHR concept and associated regulatory definition (discussed later in this preamble), we also propose to remove the ``optional'' designation from this certification criterion as part of the 2015 Edition since such designation would no longer be necessary. We propose to make a technical amendment to the regulation text for the [[Page 10911]] 2014 Edition certification criterion so that it continues to point to the appropriate standard \95\ in the regulatory text hierarchy at Sec. 170.205(i), while accommodating our 2015 Edition proposal. Specifically, we propose to modify the 2014 Edition certification criterion to reference Sec. 170.205(i)(1) to establish the regulatory text hierarchy necessary to accommodate the standard and IG referenced by the proposed 2015 Edition certification criterion. --------------------------------------------------------------------------- \95\ Standard. HL7 Clinical Document Architecture (CDA), Release 2.0, Normative Edition (incorporated by reference in Sec. 170.299). Implementation specifications. Implementation Guide for Ambulatory Healthcare Provider Reporting to Central Cancer Registries, HL7 Clinical Document Architecture (CDA), Release 1.0 (incorporated by reference in Sec. 170.299). --------------------------------------------------------------------------- The 2014 Edition criterion for transmission to cancer registries at Sec. 170.314(f)(6) references the following IG for cancer reporting: Implementation Guide for Ambulatory Healthcare Provider Reporting to Central Cancer Registries, HL7 Clinical Document Architecture (CDA), Release 1.0. Since the publication of the 2014 Edition Final Rule, CDC has updated the IG (Implementation Guide for Ambulatory Healthcare Provider Reporting to Central Cancer Registries, HL7 Clinical Document Architecture (CDA), Release 1.1, March 2014) to address technical corrections and clarifications for interoperability with EHRs and cancer registries. Specifically, this updated version of the IG: \96\ --------------------------------------------------------------------------- \96\ This IG will be available for review during the public comment period at https://www.cdc.gov/EHRmeaningfuluse/guides.html. --------------------------------------------------------------------------- Provides clarification about conformance statements taking precedence over table constraints; Adds new vocabulary link (ICD 10 CM reportability list); Fixes some within-document references; Fixes some LOINC Codes; Fixes some Code System and Value Set Object Identifiers (OIDs); Fixes some conformance verbs; Modifies some conformance statements and sample XML for clarifications in Medications Entry; Fixes some attributes in Payer Section; Fixes some Xpaths and element names in constraints table; Adds and fixes some codes in Appendix A Code System Table; Fixes some conformance verbs and data element names in Appendix B ``Ambulatory Healthcare Provider Cancer Event Report--Data Elements''; Fixes value in value set; and Adds data elements for transmission of Grade and pathological TNM Stage. These improvements are important to the IG and will continue to support interoperability. Given the improvements that will be included in the updated IG, we propose to adopt it (Implementation Guide for Ambulatory Healthcare Provider Reporting to Central Cancer Registries, HL7 Clinical Document Architecture (CDA), Release 1.1) at Sec. 170.205(i)(2) for the 2015 Edition certification criterion for transmission to cancer registries at Sec. 170.315(f)(6). Automated Numerator Recording MU Objective N/A 2015 Edition EHR Certification Criterion Sec. 170.315(g)(1) (Automated numerator recording) Gap Certification Status Eligibility is Fact-Specific We propose to adopt a 2015 Edition certification criterion that is the same as the 2014 Edition version. Automated Measure Calculation MU Objective N/A 2015 Edition EHR Certification Criterion Sec. 170.315(g)(2) (Automated measure calculation) Gap Certification Status Eligibility is Fact-Specific We propose to adopt a 2015 Edition ``automated measure calculation'' certification criterion that is the same as the 2014 Edition certification criterion. We propose to apply the guidance provided for the 2014 Edition ``automated measure calculation'' certification criterion in the 2014 Edition Final Rule in that EHR technology must be able to support all CMS-acceptable approaches for measuring a numerator and denominator in order for to meet the proposed 2015 Edition ``automated measure calculation'' certification criterion.\97\ We also propose that the interpretation of the 2014 Edition ``automated measure calculation'' certification criterion in FAQ 32 \98\ would apply to the proposed 2015 Edition ``automated measure calculation'' certification criterion. --------------------------------------------------------------------------- \97\ 77 FR 54244-54245. \98\ https://www.healthit.gov/policy-researchers-implementers/32-question-11-12-032. --------------------------------------------------------------------------- Safety-Enhanced Design; and Quality Management System MU Objective N/A 2015 Edition EHR Certification Criteria Sec. 170.315(g)(3) (Safety-Enhanced Design) Sec. 170.315(g)(4) (Quality Management System) Gap Certification Status Eligibility is Fact-Specific--Safety-Enhanced Design Eligible--Quality Management System We propose to adopt 2015 Edition EHR certification criteria that are the same as the 2014 Edition versions, but solicit public comment regarding whether we should modify these criteria in light of feedback that we received during the HITPC ``Implementation and Usability'' hearing on July 23, 2013.\99\ Specifically, we request comment regarding: --------------------------------------------------------------------------- \99\ https://www.healthit.gov/archive?dir=FACA%20Hearings/2013-07-23%20Standards%3A%20Implementation%2C%20Meaningful%20Use%2C%20and%20Certification%20%26%20Adoption%20WGs%2C%20%20Implementation%20%26%20Usability%20Hearing. --------------------------------------------------------------------------- Whether the scope of ``Safety-Enhanced Design'' should be expanded to include additional certification criteria; Whether formative usability tests should be explicitly required, or used as substitutes for summative testing; Whether there are explicit usability tests that should be required in addition to summative testing; and Whether there should be a minimum number of test subjects explicitly required for usability testing. We note that we have updated the cross referencing in the 2015 Edition version of the ``safety-enhanced design'' certification criterion to track the updated certification criteria paragraph numbering. Non-Percentage-Based Measures Report MU Objective N/A 2015 Edition EHR Certification Criterion Sec. 170.315(g)(5) (Non-percentage-based measures report) Gap Certification Status Ineligible We propose to adopt a new certification criterion in the 2015 Edition entitled ``non-percentage-based measures report.'' Specifically, we propose to adopt a new 2015 Edition EHR certification criterion at Sec. 170.315(g)(5) that would apply to EHR technology presented for certification that includes certain ``non-percentage- based capabilities'' (i.e., capabilities that support MU objectives for which the corresponding MU measure is not percentage-based). In the 2014 Edition NPRM (77 FR 13842), we proposed a certification criterion entitled ``non-percentage-based measure use report.'' This certification criterion was meant to complement the other certification [[Page 10912]] criteria we proposed to support the calculation of percentage-based MU measures. In the 2014 Edition Final Rule (77 FR 54186), we acknowledged commenters' concerns regarding the complexities raised by our proposed ``non-percentage-based measure use report'' certification criterion and that additional specificity would be needed to make the certification criterion more effective. Although we declined to adopt the proposed certification criterion in the final rule, we affirmed our belief in its spirit and direction--that EPs, EHs, and CAHs would benefit from EHR technology that could electronically report non-percentage-based MU objectives and measures. In November 2012, the HITPC issued a Request for Comment (RFC) regarding potential meaningful use Stage 3 recommendations.\100\ The RFC specifically solicited feedback on ways in which EHR technology could help providers document the use of EHR technology capabilities associated with MU measures that are not percentage-based. The comments submitted in response to the RFC as well as the 2014 Edition NPRM echoed the need for EHR technology to be able to assist providers document their use of EHR technology to achieve non-percentage-based objectives and measures. The comments also confirmed and have sharpened our understanding of the complexities associated with this type of certification criterion. Further, we considered these comments in light of the recommendation from the HHS OIG that, ``where possible,'' ONC require that certified EHR technology be capable of producing reports for all MU measures, including non-percentage-based measures.\101\ OIG explained that such reports could help EPs, EHs, and CAHs prove compliance in the event of an audit and simplify CMS' oversight of the EHR Incentive Programs by allowing CMS to conclusively verify that an EP, EH, or CAH had relevant EHR technology capabilities in use during their reporting period. OIG also acknowledged that producing reports may not be possible for some measures. --------------------------------------------------------------------------- \100\ The Request for Comments is available at https://www.healthit.gov/sites/default/files/hitpc_stage3_rfc_final.pdf. \101\ OEI-05-11-00250 (Nov. 2012), available at https://oig.hhs.gov/oei/reports/oei-05-11-00250.pdf. --------------------------------------------------------------------------- The new criterion we propose to adopt is more specific than the one we proposed in the 2014 Edition NPRM and also clarifies key aspects of the 2014 Edition proposal that caused confusion. Specifically, this proposed criterion recognizes that certain aspects of ``use'' associated with non-percentage-based measures will occur in different ways based on the particular EHR technology capability involved. In that regard, the proposed criterion provides EHR technology developers with substantial flexibility to create innovative approaches to document evidence of use and because non-percentage-based MU measures vary, we do not presume that there is one particular way to meet this certification criterion. The proposed certification criterion would require that an EHR technology presented for certification be capable of electronically generating a report that shows a user had used (or interacted with) the EHR technology capability associated with a non-percentage-based MU measure during an EHR reporting period. This means that, at a minimum, the EHR technology would need to be capable of determining an EHR reporting period (date range) and be able to record some evidence of use (e.g., transaction, user action, intervention/reminder) during the reporting period. We request public comment on whether we should make the regulatory text for this certification criterion more specific or if we should maintain the word ``evidence'' and use the final rule's preamble to provide more examples of what evidence would be acceptable (if we determine to adopt this criterion). If we were to make the regulatory text more specific, we propose these two options, but also solicit comment on other potential language that would make satisfying this criterion clearer. Option 1: Require the EHR technology to record evidence of use each time a particular capability was used during the reporting period. Option 2: Require the EHR technology to record evidence of use at the beginning, during, and end of the reporting period. In some cases we understand that it will not be possible for EHR technology to record whether a non-percentage-based capability was used ``to demonstrate MU'' because this determination depends on the context in which the use of the capability occurred or on other subjective factors that cannot be determined through EHR technology use. To address this point, the proposed criterion focuses on the ability of EHR technology to record pertinent information about the use of non- percentage-based capabilities (e.g., transaction, user action, intervention/reminder) that would be helpful to ascertain whether the corresponding MU measure was met during a reporting period. Moreover, as indicated in Table 2 and explained below, the proposed criterion would apply to only those non-percentage-based measures for which this pertinent information would be available to the EHR technology based on the nature of the capabilities and the ways in which a user could be expected to interact with them. To note, the use of the term ``unchanged'' in the ``MU Stage 2'' column of the table denotes that the objective and/or measure has not changed from MU Stage 1. Table 2--2015 Edition Certification Criteria That Support One or More Non-Percentage-Based Measures ------------------------------------------------------------------------ Certification Applicable criterion MU Stage 1* MU Stage 2* ------------------------------------------------------------------------ Y.............. Sec. Objective. Drug- Objective. 170.315(a)(4), drug, drug- Clinical Drug-drug, drug- allergy decision allergy interaction support. interaction checks. Measure. Enable checks. Measure. Enable and implement the drug-drug and functionality drug-allergy for the entire interaction EHR reporting checks and period. implement five CDS interventions for at least four CQMs for the entire reporting period. Y.............. Sec. Objective. 170.315(a)(10), Clinical Clinical decision support. decision support. Measure. Implement one clinical decision support rule. Y.............. Sec. Objective. Objective. 170.315(a)(16), Patient lists. Unchanged. Patient list Measure Generate Measure. creation. at least 1 Unchanged. report listing patients with a specific condition. [[Page 10913]] Y.............. Sec. Objective. Objective. 170.315(f)(2), Transmission to Unchanged. Transmission to immunization Measure. immunization registries. Successful registries. Measure. Perform ongoing a test and submission from follow-up CEHRT for entire submission if reporting the test was period. successful. Y.............. Sec. Objective. Objective. 170.315(f)(3), Transmission to Unchanged. Transmission to public health Measure. public health agencies Successful agencies (syndromic ongoing (surveillance). surveillance submission for data). entire reporting Measure. Perform period. a test and follow-up submission if the test was successful. Y.............. Sec. Objective. Objective. 170.315(f)(4), Transmission to Unchanged. Transmission of public health Measure. reportable agencies Successful laboratory tests (reportable lab ongoing and values/ data). submission for results. Measure. Perform entire reporting a test and period. follow-up submission if the test was successful. Sec. N/A.............. Objective. 170.315(f)(6), Capability to Transmission to identify and cancer report cancer registries. cases to a State cancer registry. Measure. Successful ongoing submission for entire reporting period. N.............. Sec. Objective. Objective. 170.315(b)(1), Transitions of Transitions of Transitions of care. care. care. Measure. Provides Measures. (1) a summary of Provide a care record for summary of care more than 50% of record for more transitions of than 50% of care and transitions of referrals. care and referrals. (2) Provide a summary of care record electronically for more than 10% of transitions of care and referrals. (3)(A) Conducts one or more successful electronic exchanges of a summary of care record with a recipient using technology to receive the summary of care record that was designed by a different EHR developer than the sender's; or (B) Conducts one or more successful tests with the CMS designated test EHR during the EHR reporting period. N.............. Sec. Objective. Objective. 170.315(a)(12), Implement drug- Generate and Drug-formulary formulary checks. transmit checks. Measure. Enable permissible functionality prescriptions and have access electronically to one internal (eRx). or external Measure. More formulary for than 50% of entire reporting prescriptions period. (EP) or more than 10% of hospital discharge medication orders for permissible prescriptions (EH/CAH) are queried for a drug-formulary and transmitted electronically using CEHRT. N.............. Sec. Objective. 170.315(d)(1)-(9 Protect ), Privacy and electronic Security. health information through implementation of appropriate technical capabilities. Measure. Conduct Objective. or review a Unchanged. security risk Measure. analysis in Unchanged. accordance with the requirements under 45 CFR 164.308(a)(1) and implement security updates as necessary and correct identified security deficiencies as part of the EP's, EH's, or CAH's risk management process ------------------------------------------------------------------------ * The requirements for each meaningful use objective and measure are set forth in 42 CFR Sec. 495.6. For convenience, we have summarized and/ or condensed the descriptions for each objective and measure listed in the table above. We propose not to include within the scope of this certification criterion the EHR technology capability specified in Sec. 170.315(a)(12), which supports the MU Stage 1 objective ``Implement drug-formulary checks'' and the associated non-percentage-based measure. This objective was merged with the new MU Stage 2 objectives ``Generate and transmit permissible prescriptions electronically (eRx)'' for EPs and ``Generate and transmit permissible discharge prescriptions electronically (eRx)'' for EHs and CAHs, each of which is associated with a new percentage-based measure. As a result, EHR technology certified to Sec. 170.315(a)(12) must also be certified to the ``automated numerator recording'' or ``automated measure recording'' certification criterion and will provide adequate evidence of use with respect to MU Stage 1 measure related to drug-formulary checks. We also propose to treat the proposed ToC capability specified at Sec. 170.315(b)(1) as inapplicable for purposes of this proposed certification criterion. The corresponding MU Stage 1 measure for this capability is percentage-based. The corresponding MU Stage 2 objective has three measures, two of which are percentage-based. The third measure is non-percentage-based, but involves one or more discrete transactions in which the EHR user will either receive some form of confirmation (from the CMS-designated test EHR) or the transaction is documented by the EP, EH, or CAH. Finally, as we previously stated in the 2014 Edition Final Rule, the privacy and [[Page 10914]] security certification criteria proposed for adoption in Sec. 170.315(d), which are associated with the MU objective (and measure) entitled ``protect electronic health information created or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities,'' would not be included within the scope of this certification criterion because we do not believe that EHR technology would be able to capture that a security risk analysis was performed by an EP, EH, or CAH except through a manual entry by the EP, EH, or CAH affirming the completion of the risk analysis. Consistent with the way in which we have previously implemented certification policy that more generally applies to EHR technology, an ONC-ACB would also need to have new certification responsibilities if we were to adopt this proposed criterion in a final rule. As a result, we are also proposing to revise 45 CFR 170.550. This revision would ensure that EHR Modules presented for certification to certification criteria that support MU objectives with a non-percentage-based measure are certified to this certification criterion proposed at Sec. 170.315(g)(5). Transmission Certification Criteria As discussed in the proposed 2015 Edition ToC certification criterion earlier in this preamble, we have determined that it would best support industry interoperability approaches and provider choices for electronic exchange services if we permitted ``data content'' capabilities to be tested and certified separately from ``data transmission'' capabilities. As a result, we propose below three 2015 Edition transmission certification criteria that reflect the decoupling of content and transport from both the ToC certification criterion and VDT certification criterion. These three proposed criteria mirror the transmission standards listed in the 2014 Edition ToC certification criterion with the first at 170.315(h)(1) mirroring the same transmission standard list in the 2014 Edition VDT certification criterion. We have not proposed to require the ability to receive Consolidated CDAs transmitted in accordance with the IG for Direct Edge Protocols in these certification criteria because we believe it to be unnecessary to require as a condition of certification. We assume that: 1) it will be in the best/market interests of any EHR technology developer who gets a product separately certified to any of these certification criteria to ensure that the product is able to receive data from EHR technology certified to electronically transmit in accordance with the IG for Direct Edge Protocols (otherwise its product's viability and competitiveness on the market would be limited); and 2) it would be redundant in cases where a single EHR technology is certified to, for example, both the proposed 2015 Edition ToC certification criterion at Sec. 170.315(b)(1) and the Transmit-- Applicability Statement for Secure Health Transport at Sec. 170.315(h)(1). However, we solicit comment on whether there are other factors we have not considered in coming to these conclusions. Transmit--Applicability Statement for Secure Health Transport MU Objective N/A 2015 Edition EHR Certification Criterion Sec. 170.315(h)(1) (Transmit--Applicability Statement for Secure Health Transport) Gap Certification Status Ineligible We propose to adopt a new 2015 Edition certification criterion for electronic transmission at 45 CFR 170.315(h)(1) that would enable EHR technology to be tested and certified solely to perform transmissions in accordance with the Applicability Statement for Secure Health Transport (the primary Direct Project specification) adopted at Sec. 170.202(a). We expect that this capability would be tested similarly to how it is today except that only this capability would be tested. Transmit--Applicability Statement for Secure Health Transport and XDR/XDM for Direct Messaging MU Objective N/A 2015 Edition EHR Certification Criterion Sec. 170.315(h)(2) (Transmit--Applicability Statement for Secure Health Transport and XDR/XDM for Direct Messaging) Gap Certification Status Ineligible We propose to adopt a new 2015 Edition certification criterion for electronic transmission at 45 CFR 170.315(h)(2) that would enable EHR technology to be tested and certified solely to perform transmissions in accordance with the Applicability Statement for Secure Health Transport (the primary Direct Project specification) adopted at Sec. 170.202(a) and its companion specification XDR and XDM for Direct Messaging Specification adopted at Sec. 170.202(b). We expect that this capability would be tested similarly to how it is today except that only this capability would be tested. Transmit--SOAP Transport and Security Specification and XDR/ XDM for Direct Messaging MU Objective N/A 2015 Edition EHR Certification Criterion Sec. 170.315(h)(3) (Transmit--SOAP Transport and Security Specification and XDR/XDM for Direct Messaging) Gap Certification Status Ineligible We propose to adopt a new 2015 Edition certification criterion for electronic transmission at 45 CFR 170.315(h)(3) that would enable EHR technology to be tested and certified solely to perform transmissions in accordance with the Transport and Security Specification (also referred to as the SOAP-Based Secure Transport RTM adopted at Sec. 170.202(c) and its companion specification XDR and XDM for Direct Messaging Specification adopted at Sec. 170.202(b). We expect that this capability would be tested similarly to how it is today except that only this capability would be tested. Transmit--Applicability Statement for Secure Health Transport and Delivery Notification in Direct MU Objective N/A 2015 Edition EHR Certification Criterion Sec. 170.315(h)(4) (Transmit--Applicability Statement for Secure Health Transport and Delivery Notification in Direct) Gap Certification Status Ineligible We propose to adopt a new 2015 Edition certification criterion for electronic transmission at 45 CFR 170.315(h)(4) that would enable EHR technology to be tested and certified solely to perform transmissions in accordance with the Applicability Statement for Secure Health Transport (the primary Direct Project specification) adopted at Sec. 170.202(a) and its companion specification Implementation Guide for Delivery Notification in Direct, Version 1.0, June 29, 2012 (Delivery Notification IG).\102\ The primary Direct Project specification requires that Security/Trust Agents (STAs) must issue a Message Disposition Notification (MDN, RFC3798) with a disposition of processed upon successful receipt, decryption, and trust validation of a Direct message. By sending this MDN, the receiving STA is taking [[Page 10915]] custodianship of the message and is indicating that it will deliver the message to its destination. While the primary Direct Project specification indicates that additional MDNs may be sent to indicate further processing progress of the message, they are not required. The primary Direct Project specification, however, does not provide guidance in regards to the actions that should be taken by the sending STA in the event an MDN processed message is not received or if the receiving STA cannot deliver the message to its destination after sending the initial MDN processed message. Due to the lack of specifications and guidance in the primary Direct Project specification regarding deviations from normal message flow, STAs implementing only requirements denoted as ``must'' in Section 3 of the primary Direct Project specification may not be able to provide a high level of assurance that a message has arrived at its destination. The Delivery Notification IG provides implementation guidance enabling STAs to provide a high level of assurance that a message has arrived at its destination and outlines the various exception flows that result in compromised message delivery and the mitigation actions that should be taken by STAs to provide success and failure notifications to the sending system. --------------------------------------------------------------------------- \102\ https://wiki.directproject.org/file/view/Implementation+Guide+for+Delivery+Notification+in+Direct+v1.0.pdf. --------------------------------------------------------------------------- From a CLIA regulations perspective, the Delivery Notification IG can provide the necessary level of assurance that sent laboratory results are received by a provider. Additionally, we note that the Delivery Notification IG could be generally useful for any transmission that requires a high level of assurance. Finally, given that testing and certification to this certification criterion would assess conformance to specific, distinct capabilities, we propose that certification to Sec. 170.315(h)(4) would not satisfy Sec. 170.315(h)(1) or (h)(2), which would need to be separately demonstrated to pass testing and certification. B. 2014 Edition to 2015 Edition Equivalency Table The following table identifies the proposed 2015 Edition EHR certification criteria that are equivalent to the 2014 Edition certification criteria for the purposes of meeting the CEHRT definition. Table 3--2015 Edition to 2014 Edition Equivalency ---------------------------------------------------------------------------------------------------------------- 2015 Edition 2014 Edition ---------------------------------------------------------------------------------------------------------------- Title of regulation Title of regulation Regulation section paragraph Regulation section paragraph ---------------------------------------------------------------------------------------------------------------- Sec. 170.315(a)(4).......... Drug-drug, drug-allergy Sec. 170.314(a)(2)......... Drug-drug, drug-allergy interaction checks. interaction checks. Sec. 170.315(a)(5).......... Demographics............ Sec. 170.314(a)(3)......... Demographics. Sec. 170.315(a)(6).......... Vital signs, BMI, & Sec. 170.314(a)(4)......... Vital signs, BMI, & growth charts. growth charts. Sec. 170.315(a)(7).......... Problem list............ Sec. 170.314(a)(5)......... Problem list. Sec. 170.315(a)(8).......... Medication list......... Sec. 170.314(a)(6)......... Medication list. Sec. 170.315(a)(9).......... Medication allergy list. Sec. 170.314(a)(7)......... Medication allergy list. Sec. 170.315(a)(10)......... Clinical decision Sec. 170.314(a)(8)......... Clinical decision support. support. Sec. 170.315(a)(11)......... Electronic notes........ Sec. 170.314(a)(9)......... Electronic notes. Sec. 170.315(a)(12)......... Drug-formulary checks... Sec. 170.314(a)(10)........ Drug-formulary checks. Sec. 170.315(a)(13)......... Smoking status.......... Sec. 170.314(a)(11)........ Smoking status. Sec. 170.315(a)(14)......... Image results........... Sec. 170.314(a)(12)........ Image results. Sec. 170.315(a)(15)......... Family health history... Sec. 170.314(a)(13)........ Family health history. Sec. 170.315(a)(16)......... Patient list creation... Sec. 170.314(a)(14)........ Patient list creation. Sec. 170.315(a)(17)......... Patient-specific Sec. 170.314(a)(15)........ Patient-specific education resources. education resources. Sec. 170.315(a)(18)......... Electronic medication Sec. 170.314(a)(16)........ Electronic medication administration record. administration record. Sec. 170.315(a)(19)......... Advance directives...... Sec. 170.314(a)(17)........ Advance directives. Sec. 170.315(b)(2).......... Clinical information Sec. 170.314(b)(4)......... Clinical information reconciliation and reconciliation. incorporation. Sec. 170.315(b)(3).......... Electronic prescribing.. Sec. 170.314(b)(3)......... Electronic prescribing. Sec. 170.315(b)(4).......... Incorporate lab tests & Sec. 170.314(b)(5)......... Incorporate lab tests & values/results. values/results. Sec. 170.315(b)(5).......... Transmission of Sec. 170.314(b)(6)......... Transmission of electronic lab tests & electronic lab tests & values/results to values/results to ambulatory providers. ambulatory providers. Sec. 170.315(b)(6).......... Data portability........ Sec. 170.314(b)(7)......... Data portability. Sec. 170.315(c)(1)-(3)...... Clinical quality Sec. 170.314(c)(1)-(3)..... Clinical quality measures. measures. Sec. 170.315(d)(1).......... Authentication, access Sec. 170.314(d)(1)......... Authentication, access control, & control, & authorization. authorization. Sec. 170.315(d)(2).......... Auditable events and Sec. 170.314(d)(2)......... Auditable events and tamper resistance. tamper resistance. Sec. 170.315(d)(3).......... Audit report(s)......... Sec. 170.314(d)(3)......... Audit report(s). Sec. 170.315(d)(4).......... Amendments.............. Sec. 170.314(d)(4)......... Amendments. Sec. 170.315(d)(5).......... Automatic log-off....... Sec. 170.314(d)(5)......... Automatic log-off. Sec. 170.315(d)(6).......... Emergency access........ Sec. 170.314(d)(6)......... Emergency access. Sec. 170.315(d)(7).......... End-user device Sec. 170.314(d)(7)......... End-user device encryption. encryption. Sec. 170.315(d)(8).......... Integrity............... Sec. 170.314(d)(8)......... Integrity. Sec. 170.315(d)(9).......... Accounting of Sec. 170.314(d)(9)......... Accounting of disclosures. disclosures. Sec. 170.315(e)(1).......... View, download, & Sec. 170.314(e)(1)......... View, download, & transmit to 3rd party. transmit to 3rd party. Sec. 170.315(e)(2).......... Clinical summary........ Sec. 170.314(e)(2)......... Clinical summary. Sec. 170.315(e)(3).......... Secure messaging........ Sec. 170.314(e)(3)......... Secure messaging. Sec. 170.315(f)(1) & (f)(2). Immunization information/ Sec. 170.314(f)(1) & (f)(2) Immunization Transmission to information/ immunization registries. Transmission to immunization registries. Sec. 170.315(f)(3).......... Transmission to public Sec. 170.314(f)(3)......... Transmission to public health agencies-- health agencies-- syndromic surveillance. syndromic surveillance. Sec. 170.315(f)(4).......... Transmission of Sec. 170.314(f)(4)......... Transmission of reportable lab tests & reportable lab tests & values/results. values/results. Sec. 170.315(f)(5).......... Cancer case information. Sec. 170.314(f)(5)......... Cancer case information. Sec. 170.315(f)(6).......... Transmission to cancer Sec. 170.314(f)(6)......... Transmission to cancer registries. registries. Sec. 170.315(g)(1).......... Automated numerator Sec. 170.314(g)(1)......... Automated numerator recording. recording. [[Page 10916]] Sec. 170.315(g)(2).......... Automated measure Sec. 170.314(g)(2)......... Automated measure calculation. calculation. Sec. 170.315(g)(3).......... Safety-enhanced design.. Sec. 170.314(g)(3)......... Safety-enhanced design. Sec. 170.315(g)(4).......... Quality management Sec. 170.314(g)(4)......... Quality management system. system. ---------------------------------------------------------------------------------------------------------------- C. Gap Certification Eligibility Table for 2015 Edition EHR Certification Criteria We define ``gap certification'' at 45 CFR 170.502 as ``the certification of a previously certified Complete EHR or EHR Module(s) to: (1) [a]ll applicable new and/or revised certification criteria adopted by the Secretary at subpart C of [part 170] based on the test results of a NVLAP-accredited testing laboratory; and (2) [a]ll other applicable certification criteria adopted by the Secretary at subpart C of [part 170] based on the test results used to previously certify the Complete EHR or EHR Module(s)'' (for further explanation, see 76 FR 1307-1308). Our gap certification policy focuses on the differences between certification criteria that are adopted through rulemaking at different points in time. This allows EHR technology to be certified to only the differences between certification criteria editions rather than requiring EHR technology to be fully retested and recertified to certification criteria that remain unchanged from one edition to the next and for which previously acquired test results are sufficient. Under our gap certification policy, ``unchanged'' criteria (see 77 FR 54248 for further explanation) are eligible for gap certification, and each ONC-ACB has discretion over whether it will provide the option of gap certification. For the purposes of gap certification, Table 4 below provides a crosswalk of ``unchanged'' 2015 Edition EHR certification criteria to the corresponding 2014 Edition certification criteria. We note that with respect to the 2015 Edition certification criteria proposed for adoption at Sec. 170.315(g)(1) through (g)(3) that gap certification eligibility for these criteria is fact-specific and will depend on any modifications made to the specific certification criteria to which these ``paragraph (g)'' certification criteria apply. Table 4--Gap Certification Eligibility for 2015 Edition EHR Certification Criteria ---------------------------------------------------------------------------------------------------------------- 2015 Edition 2014 Edition ---------------------------------------------------------------------------------------------------------------- Title of regulation Title of regulation Regulation section paragraph Regulation section paragraph ---------------------------------------------------------------------------------------------------------------- Sec. 170.315(a)(1).......... Computerized physician Sec. 170.314(a)(1)......... Computerized Provider order entry-- Order Entry. medications. Sec. 170.315(a)(3).......... Computerized physician order entry--radiology/ imaging.. Sec. 170.315(a)(4).......... Drug-drug, drug-allergy Sec. 170.314(a)(2)......... Drug-drug, drug-allergy interaction checks.. interaction checks. Sec. 170.315(a)(6).......... Vital signs, BMI, & Sec. 170.314(a)(4)......... Vital signs, BMI, & growth charts. growth charts. Sec. 170.315(a)(7).......... Problem list............ Sec. 170.314(a)(5)......... Problem list. Sec. 170.315(a)(8).......... Medication list......... Sec. 170.314(a)(6)......... Medication list. Sec. 170.315(a)(9).......... Medication allergy list. Sec. 170.314(a)(7)......... Medication allergy list. Sec. 170.315(a)(12)......... Drug-formulary checks... Sec. 170.314(a)(10)........ Drug-formulary checks. Sec. 170.315(a)(13)......... Smoking status.......... Sec. 170.314(a)(11)........ Smoking status. Sec. 170.315(a)(14)......... Image results........... Sec. 170.314(a)(12)........ Image results. Sec. 170.315(a)(16)......... Patient list creation... Sec. 170.314(a)(14)........ Patient list creation. Sec. 170.315(a)(18)......... Electronic medication Sec. 170.314(a)(16)........ Electronic medication administration record. administration record. Sec. 170.315(a)(19)......... Advance directives...... Sec. 170.314(a)(17)........ Advance directives. Sec. 170.315(b)(3).......... Electronic prescribing.. Sec. 170.314(b)(3)......... Electronic prescribing. Sec. 170.315(c)(1)-(3)...... Clinical quality Sec. 170.314(c)(1)-(3)..... Clinical quality measures. measures. Sec. 170.315(d)(1).......... Authentication, access Sec. 170.314(d)(1)......... Authentication, access control, & control, & authorization. authorization. Sec. 170.315(d)(3).......... Audit report(s)......... Sec. 170.314(d)(3)......... Audit report(s). Sec. 170.315(d)(4).......... Amendments.............. Sec. 170.314(d)(4)......... Amendments. Sec. 170.315(d)(5).......... Automatic log-off....... Sec. 170.314(d)(5)......... Automatic log-off. Sec. 170.315(d)(6).......... Emergency access........ Sec. 170.314(d)(6)......... Emergency access. Sec. 170.315(d)(7).......... End-user device Sec. 170.314(d)(7)......... End-user device encryption. encryption. Sec. 170.315(d)(8).......... Integrity............... Sec. 170.314(d)(8)......... Integrity. Sec. 170.315(d)(9).......... Accounting of Sec. 170.314(d)(9)......... Accounting of disclosures. disclosures. Sec. 170.315(e)(3).......... Secure messaging........ Sec. 170.314(e)(3)......... Secure messaging. Sec. 170.315(f)(1).......... Immunization information Sec. 170.314(f)(1)......... Immunization information. Sec. 170.315(f)(3)#......... Transmission to public Sec. 170.314(f)(3)#........ Transmission to public health agencies-- health agencies-- syndromic surveillance. syndromic surveillance Sec. 170.315(f)(5).......... Cancer case information. Sec. 170.314(f)(5)......... Cancer case information. Sec. 170.315(g)(4).......... Quality management Sec. 170.314(g)(4)......... Quality management system. system. ---------------------------------------------------------------------------------------------------------------- # If certified to the revised 2014 Edition version of this criterion after the effective date of the 2015 Edition Final Rule. For further information on this distinction, please see the gap certification discussion under the ``Transmission to Public Health Agencies--Syndromic Surveillance'' in section III.A of this preamble. [[Page 10917]] D. HIT Definitions 1. CEHRT and Base EHR Definitions We propose revisions to the CEHRT and Base EHR definitions at Sec. 170.102 for the purpose of including the proposed 2015 Edition EHR certification criteria in those definitions. We propose to revise the CEHRT definition for FY/CY 2014 and subsequent years to include reference to the 2015 Edition EHR certification criteria. Under our proposal, EPs, EHs, and CAHs would have the flexibility to use EHR technology that has been certified to either the 2014 Edition or the 2015 Edition, or a combination of both editions, to meet the CEHRT definition for FY/CY 2014 and subsequent years. We believe this proposal would enhance the already flexible CEHRT definition available to EPs, EHs, and CAHs by enabling them to use EHR technology certified to the 2015 Edition to meet the CEHRT definition and would permit an incremental transition from the adoption and implementation of EHR technology certified from one edition of EHR certification criteria to another. We propose to include in the Base EHR definition the 2015 Edition EHR certification criteria that correspond to the 2014 Edition EHR certification criteria already specified in the Base EHR definition (i.e., CPOE, demographics, problem list, medication list, medication allergy list, CDS, CQMs, transitions of care, data portability, and privacy and security). Our proposed changes to the Base EHR definition would permit EPs, EHs, and CAHs to meet the Base EHR definition with EHR technology certified to either the 2014 Edition or the 2015 Edition, or a combination of both. With the 2014 Edition, EHR technology developers have the ability to market their EHR technology as meeting the Base EHR definition when appropriate. We would continue this policy upon the adoption of the 2015 Edition EHR certification criteria. 2. Complete EHR We propose to discontinue use of the Complete EHR definition as a regulatory concept beginning with the 2015 Edition EHR certification criteria. Currently, there are definitions for ``Complete EHR, 2011 Edition'' and ``Complete EHR, 2014 Edition'' under Sec. 170.102. However, under our proposal, we would not add a new definition for ``Complete EHR, 2015 Edition.'' As a result, ONC-ACBs would not be able to issue Complete EHR certifications to EHR technology certified to the 2015 Edition EHR certification criteria. Despite adopting a revised, more flexible, CEHRT definition in the 2014 Edition Final Rule that permits EPs, EHs, and CAHs to use (if available) EHR Modules certified to the minimum number of certification criteria necessary to support their achievement of the specific MU Stage they needed to meet, we maintained the Complete EHR concept and Complete EHR certification to the 2014 Edition. We assumed some EPs, EHs, and CAHs might prefer the relative simplicity a Complete EHR certification offered from a regulatory compliance perspective compared to the flexibility and responsibility offered by an EHR Module(s) approach to the new CEHRT definition. While we thought the continued availability of Complete EHR certifications would be helpful for some EPs, EHs, and CAHs, we did not believe that for the 2014 Edition the use of Complete EHRs would be the primary way the CEHRT definition would be met because the revised, more flexible, CEHRT definition adopted in the 2014 Edition Final Rule permitted EPs, EHs and CAHs to have less than a certified Complete EHR to meet the CEHRT definition. We believe this proposed rule serves as an ideal time to propose discontinuing the Complete EHR concept beginning with the 2015 Edition and before we propose the 2017 Edition. The following explains our rationale for discontinuing the Complete EHR concept beginning with the 2015 Edition: (1) The Complete EHR definition initially was intended to support the original CEHRT definition established in the 2011 Edition Final Rule under Sec. 170.102. As a general summary, the original CEHRT definition required an EP, EH, and CAH to have EHR technology that met ALL of the certification criteria adopted for an applicable setting (ambulatory or inpatient). The ``Complete EHR'' term and definition was meant to convey that all applicable certification criteria had been met and the statutory requirements of the Qualified EHR definition had been fulfilled. As noted above, the current CEHRT definition and Complete EHR definition no longer share the same symmetry. In fact, the 2014 Edition Complete EHR definition now exceeds the CEHRT definition's requirements as to the number of certification criteria to which an EHR technology would need to be certified to meet the CEHRT definition. (2) Since publication of the 2014 Edition Final Rule, we have received stakeholder feedback through email questions and during educational presentations and other outreach that demonstrates confusion about the interplay between the CEHRT definition, the Base EHR definition (adopted as part of the 2014 Edition Final Rule), and the Complete EHR definition. Stakeholders have correctly concluded that a certified 2014 Edition Complete EHR could be used to meet the CEHRT definition, but some believe incorrectly that their only regulatory option to meet the CEHRT definition is to adopt a certified Complete EHR. Even though, under the CEHRT definition for FY/CY 2014 and subsequent years in Sec. 170.102, they only need EHR technology (EHR Modules) certified to the 2014 Edition EHR certification criteria that meets the Base EHR definition (a finite set of capabilities) and includes all other capabilities that are necessary to meet the objectives and measures and successfully report CQMs for the MU Stage they are attempting to achieve. (3) A Complete EHR is not necessarily ``complete'' or sufficient when it comes to an EP's, EH's, or CAH's attempt to achieve MU. For example, based on the ``Complete EHR, 2014 Edition'' definition, it may not be certified to particular CQMs on which an EP intends to report and it may not have been certified to capabilities included in optional certification criteria that an EP needs for MU, such as the 2014 Edition cancer reporting certification criteria (Sec. 170.314(f)(5) and (6)). Thus, if we were to continue this policy approach, we believe this discrepancy would only grow and cause greater confusion over time. (4) Stakeholder feedback to us since the 2014 Edition Final Rule (via conference and webinar question and answer sessions, public meetings, emails) and the data currently available on the CHPL indicates that some EHR technology developers have continued to seek only a 2014 Edition Complete EHR certification and, thus, only plan to offer a certified Complete EHR as a solution to customers. While we recognize EHR technology developers may choose to pursue various approaches for designing and marketing their products, we are in a position to modify our policy so that it does not encourage EHR technology developers to offer only a single certified solution. In general, we believe the decision to seek certification only for a Complete EHR serves to defeat the flexibility provided by the ``new'' CEHRT definition. Consequently, by discontinuing the availability of the Complete EHR certification, the EHR technology market could be driven by EHR technology developers competing based more on the capabilities included [[Page 10918]] in their EHR technology than on the type of certification issued (Complete EHR or EHR Module). (5) The discrepancy between what any single EP, EH, or CAH needs to achieve MU and the Complete EHR definition will likely only grow more disparate when we adopt certification criteria in a 2017 Edition rulemaking to support MU Stage 3. At that time, there may be EPs, EHs, and CAHs attempting to achieve each of the three stages of MU, but a Complete EHR in line with the current definition would likely include capabilities that support core and menu objectives and measures for all MU stages. (6) Discontinuing the use of the Complete EHR concept would be consistent with the instruction of Executive Order (EO) 13563 to identify and consider approaches that make the agency's regulatory program more effective or less burdensome in achieving the regulatory objectives. To illustrate, we would not need to designate EHR certification criteria as mandatory or optional in our regulation text as these categories were specifically developed to accommodate the Complete EHR definition (i.e., cases where EHR technology would otherwise have to be certified to a criterion solely because it is required in order to satisfy the Complete EHR certification). We welcome comments on our proposal to discontinue use of the Complete EHR concept beginning with the 2015 Edition. We emphasize that this proposal would have no impact on current 2014 Edition Complete EHR certifications or in using a 2014 Edition Complete EHR to meet the current CEHRT definition. Further, this proposal would not require EHR Module certification to only a specific set of certification criteria nor would it change what an EHR developer could present for EHR Module certification (e.g., EHR technology developed to meet all the certification criteria adopted for the ambulatory or inpatient setting could be presented for certification as an EHR Module). As an alternative to the proposal, if we were to keep the Complete EHR concept and definition for the 2015 Edition, we propose and seek comment on the following two approaches: Continue the same policy of adopting an edition-specific Complete EHR (e.g., 2015 Edition Complete EHR). In addition to the significant drawbacks discussed above that come with keeping the Complete EHR definition, this approach would also be inefficient because it would continue the need for regular regulatory changes, including adopting new edition-specific Complete EHR definitions and making changes to the Base EHR definition to accommodate various editions of Complete EHRs. Define a Complete EHR as ``EHR technology that has been developed to meet, at a minimum, all mandatory certification criteria of an edition of EHR certification criteria adopted by the Secretary for either an ambulatory setting or inpatient setting and meets the Base EHR definition.'' ONC-ACBs would be responsible for issuing Complete EHR certifications that specify the edition the Complete EHR was certified to. For example, EHR technology certified as a Complete EHR to the 2015 Edition would then be issued a certification that specifies that it is a 2015 Edition Complete EHR. This would also be evident through listing on the CHPL. This approach remains consistent with the policies we set forth in the 2014 Edition Final Rule that specify that a certification cannot be issued for a Complete EHR based on a combination of editions of EHR certification criteria and that certification must specify what edition an EHR technology is compliant with. 3. Common MU Data Set We propose to change to the ``Common MU Data Set'' definition in Sec. 170.102 to accommodate our proposed change to the preferred language standard as discussed earlier in this preamble under the 2015 Edition ``demographics'' certification criterion (Sec. 170.315(a)(5)). This proposal would not change the preferred language standard identified in the ``Common MU Data Set'' definition for certification to the 2014 Edition EHR certification criteria (i.e., ISO 639-2 constrained by ISO 639-1). Our proposed change to the ``Common MU Data Set'' definition will only affect certification to the 2015 Edition EHR certification criteria that reference the ``Common MU Data Set.'' Stated another way, for certification to these certification criteria under the 2015 Edition, EHR technology would need to meet the preferred language standard we eventually adopt in a subsequent final rule. 4. Cross Referenced FDA Definitions As discussed in our proposal for the 2015 Edition ``implantable device list'' certification criterion, we propose to adopt in Sec. 170.102 new definitions for ``Implantable Device,'' ``Unique Device Identifier,'' ``Device Identifier,'' and ``Production Identifier.'' We propose to adopt the same definitions already provided to these phrases at 21 CFR 801.3. Again, we believe adopting these definitions in our rule will prevent any interpretation ambiguity and ensure that each phrase's specific meaning reflects the same meaning given to them in the Unique Device Identification System Final Rule at in 21 CFR 801.3. Capitalization was purposefully applied to each word in these defined phrases in order to signal to readers that they have specific meanings. IV. Provisions of the Proposed Rule Affecting the ONC HIT Certification Program A. Applicability We propose to revise the ``applicability'' section (Sec. 170.501) for the ONC HIT Certification Program to clearly indicate that references to the term Complete EHR and Complete EHR certification do not apply to certification in accordance with the 2015 Edition EHR certification criteria and any subsequent edition of certification criteria adopted by the Secretary under subpart C. This proposal is consistent with our proposal to discontinue the use of the term ``Complete EHR'' and Complete EHR certification beginning with the 2015 Edition EHR certification criteria as discussed under the section entitled ``Complete EHR'' of this preamble. B. Non-MU EHR Technology Certification Certification to the 2014 Edition and proposed 2015 Edition ``automated numerator recording'' certification criteria (Sec. Sec. 170.314(g)(1) and 170.315(g)(1)) and the ``automated measure calculation'' certification criteria (Sec. Sec. 170.314(g)(2) and 170.315(g)(2)) are important to ensure that EPs, EHs, and CAHs have efficient and accurate means for recording, calculating and reporting data for MU attestation. Therefore, we have taken steps to ensure EHR technology has these necessary capabilities by including certification requirements in Sec. 170.550(f)(1) for EHR Modules that are certified to the 2014 Edition and proposing similar requirements in Sec. 170.550(g) for EHR Modules that would be certified to the 2015 Edition, including requirements for certification to proposed Sec. 170.315(g)(5) (``non-percentage-based measure report''). While these regulatory requirements are intended to provide assurance that EHR Modules can support EPs', EHs', and CAHs' MU attestation needs, they preclude the efficient certification of EHR technology designed for purposes other than achieving MU. For example, EHR technology is often designed for other types of health care settings where individual or [[Page 10919]] institutional health care providers are not typically eligible to qualify for MU incentive payments under Medicare or Medicaid, such as behavioral health or long-term post-acute care settings. EHR technology is also designed, for example, primarily to support HIE and without regard for whether the health care provider using the technology seeks to achieve MU. In these examples, a developer could choose to present the EHR technology for certification as an EHR Module under the ONC HIT Certification Program for various reasons, such as if certification were to be required by another HHS program, or simply for the assurances that certification provides. However, if those EHR technologies were to be certified as 2014 Edition EHR Modules under the ONC HIT Certification Program in accordance with the existing regulations, they would be subject to the requirements of Sec. 170.550(f)(1). In other words, EHR technology developers would be required to design their EHR technology to include specific capabilities related to MU measure recording, calculation, and reporting, even though the EHR technology would not be intended for MU. We want to avoid such situations and instead make our regulatory structure more flexible and extensible such that it can more easily accommodate health IT certification for other purposes beyond MU. Additionally, we seek to ensure that under the ONC HIT Certification Program there is a clear distinction between EHR technology certified to support MU attestation requirements and EHR technology that is not. This distinction is important so that purchasers can more easily compare and select EHR technology that meets their needs. We propose to address these issues, starting with EHR technology that is certified to the 2015 Edition, by: Establishing an ``MU EHR Module'' definition and a ``non- MU EHR Module'' definition under the main ``EHR Module'' definition at Sec. 170.102. An ``MU EHR Module'' would be defined as any service, component, or combination thereof that is designed for purposes of the EHR Incentive Programs and can meet the requirements of at least one certification criterion adopted by the Secretary. A ``non-MU EHR Module'' would be defined as any service, component, or combination thereof that is designed for any purpose other than the EHR Incentive Programs and can meet the requirements of at least one certification criterion adopted by the Secretary. Revising Sec. 170.550 to require the certification of only MU EHR Modules, as applicable, to the proposed 2015 Edition ``automated numerator recording'' certification criterion (Sec. 170.315(g)(1)), the ``automated measure calculation'' certification criterion (Sec. 170.315(g)(2)), and the ``non-percentage-based measure use report'' certification criterion (Sec. 170.315(g)(5)). This proposal would ensure that EHR technology designed for MU purposes and certified to certification criteria that include capabilities that support percentage-based and/or non-percentage-based MU measures are capable of electronically performing the associated recording and calculation of measure activities for MU purposes. Requiring both MU EHR Modules and Non-MU EHR Modules to be certified, as applicable, to Sec. 170.315(g)(3) (Safety-enhanced design) and/or (g)(4) (Quality system management). These proposed requirements can be found in Sec. 170.550(g)(2) and (3), respectively, and maintain the policy approach established with certification to the 2014 Edition (see Sec. 170.550(f)(2) and (3)) that ensures all EHR Modules are certified to these specific safety and quality certification criteria, as appropriate. Revising Sec. 170.523(k)(1)(iii) to make clear that beginning with certifications issued to the 2015 Edition, the requirement in that section would only apply to MU EHR Modules. For EHR technology certified to the 2014 Edition, Sec. 170.523(k)(1)(iii) continues to apply to Complete EHRs and all EHR Modules. We further note that we are not proposing to revise Sec. 170.523(k)(1)(i) to require a EHR Module developer to state whether its 2015 Edition EHR Module is ``MU'' or ``non-MU'' on its Web site nor in any marketing materials, communications statements, and other assertions related to the EHR Module's certification. An EHR Module developer must still list the certification criteria that the EHR Module was certified to per Sec. 170.523(k)(1)(ii). We also anticipate some form of distinct listing of MU and non-MU EHR Modules on the CHPL, as we expect ONC-ACBs will report whether the EHR Modules they certify to the 2015 Edition are MU EHR Modules or Non-MU EHR Modules. This is due to the fact that ONC-ACBs would have different certification responsibilities for MU EHR Modules and non-MU EHR Modules per proposed Sec. 170.550(g). We believe these steps will be sufficient in providing market clarity. We are not proposing to apply the certification concept of MU EHR Module and non-MU EHR Module to the 2014 Edition because of the inconsistency and potential confusion it would create regarding EHR Modules that have already been certified and, more importantly, because it would be infeasible to implement for the purposes of establishing a distinction on the CHPL in a timely manner to avoid such potential confusion. This decision is also in keeping with how we have handled prior changes to the certification of EHR technology. With the new requirements that we adopted for reporting test results hyperlinks and requiring price transparency related to MU, we only applied those requirements to EHR technology certified to the 2014 Edition and not the 2011 Edition.\103\ --------------------------------------------------------------------------- \103\ https://www.healthit.gov/policy-researchers-implementers/26-question-10-12-026. --------------------------------------------------------------------------- We wish to make clear that our proposed approach continues to leave EHR Module developers with discretion on how to develop and present their EHR technology for certification. We expect that an EHR Module developer would determine whether they want their EHR Module certified as a MU or non-MU EHR Module and then seek the appropriate testing and certification of their EHR Module from an accredited testing laboratory and an ONC-ACB, respectively. Our proposed approach would also not prevent MU EHR Modules from being sold or used for non-MU proposes since in theory a MU EHR Module could be used for non-MU purposes, although it would have certain MU-related capabilities (for example, automated numerator recording and automated measure calculation) that may be extraneous for some types of users or settings. This proposal is based on our belief that EHR technology developers who design EHR technology for non-MU purposes and settings (e.g., broad electronic health information exchange or behavioral health settings staffed mainly by MU ineligibles) find the automated numerator and automated measure calculation certification criteria requirements as unnecessary burdens and resource investments (i.e., to have to program MU-specific rules into their software just to get certified). Similarly, we believe that because of the specific ways in which MU measures are structured non-MU health care providers would find little benefit in getting EHR utilization reports showing MU performance. Accordingly, we request public comment, particularly from EHR technology developers that design technology for non-MU purposes and settings and providers who use EHR technology for non-MU purposes or in non-MU settings, on whether: [[Page 10920]] Our regulatory burden assumption is correct related to EHR technology developers having to meet the automated numerator and automated measure calculation certification criteria to obtain certification; The automated numerator and automated measure calculation certification criteria requirements pose more of burden for small EHR technology developers that design EHR technology for non-MU purposes and settings (e.g., inhibit their ability to compete with large EHR technology developers that have more resources to develop and get certified to the automated numerator and automated measure calculation certification criteria even if their customers will not use the capabilities); and Health care providers using EHR technology for non-MU purposes and settings would benefit from or be hindered by paying for and/or using EHR technology certified to the automated numerator and automated measure calculation certification criteria. We also request comment on how best to implement our proposed approach if we were to adopt it in a subsequent final rule. In this regard, we request feedback on the following questions: Would the process for testing and certification be clear under our approach as described? Should EHR technology developers simply inform ONC-ACBs as to the type of EHR Module certification they seek (i.e., MU or non-MU)? How should we distinguish non-MU EHR Modules on the CHPL? Should we have separate listings of MU and non-MU EHR Modules? Are there other options? How should we indicate and list the availability of MU EHR Modules for use beyond MU purposes? C. ONC Regulations FAQ 28 In ONC regulations FAQ 28,\104\ we provide guidance on the application of Sec. 170.314(g)(1) and (g)(2) to the certification of Complete EHRs and EHR Modules. --------------------------------------------------------------------------- \104\ https://www.healthit.gov/policy-researchers-implementers/28-question-11-12-028. --------------------------------------------------------------------------- 1. MU EHR Modules We propose to apply the guidance expressed in FAQ 28 to the certification of MU EHR Modules to the 2015 Edition ``automated numerator recording'' certification criterion (Sec. 170.315(g)(1)) and the ``automated measure calculation'' certification criterion (Sec. 170.315(g)(2)). As we state in FAQ 28 and in the 2014 Edition Final Rule (77 FR 54186), ONC-ACBs can certify an EHR Module to either the 2014 Edition ``automated numerator recording'' certification criterion or the 2014 Edition ``automated measure calculation'' certification criterion. To provide regulatory clarity, we propose to revise Sec. 170.550(f)(1) to specify this flexibility for the certification of EHR Modules to the 2014 Edition and propose the same flexibility in Sec. 170.550(g)(1) for MU EHR Modules certified to the 2015 Edition. Last, we also clarify that an EHR Module (or MU EHR Module, with regard to the 2015 Edition) could be certified to only the ``automated measure calculation'' certification criterion (Sec. Sec. 170.314(g)(2) or proposed 170.315(g)(2)) in situations where the EHR Module does not include a capability that supports a percentage-based MU objective and measure, but can meet the requirements of the ``automated measure calculation'' certification criterion (Sec. Sec. 170.314(g)(2) or proposed 170.315(g)(2)). An example of this would be an ``analytics'' EHR Module where data is fed from other EHR technology and the EHR Module can record the requisite numerators, denominators and create the necessary percentage report as specified in the ``automated measure calculation'' certification criterion. In these situations, Sec. 170.550(f)(1) or (g)(1) would not be implicated or need to be applied. 2. Complete EHRs We propose to revise Sec. 170.314(g)(1) to be an optional certification criterion as a means of providing regulatory clarity for the certification of Complete EHRs to the 2014 Edition. This proposed revision implements our guidance provided in FAQ 28. In FAQ 28 we stated that EHR technology issued a 2014 Edition Complete EHR certification must be certified to Sec. 170.314(g)(2) because it is a mandatory certification criterion consistent with the 2014 Edition Complete EHR definition requiring certification to all mandatory certification criteria for a particular setting (ambulatory or inpatient), but not Sec. 170.314(g)(1) (even though it is currently designated as a mandatory certification criterion) because a 2014 Edition Complete EHR would have demonstrated capabilities beyond those included in Sec. 170.314(g)(1) by being certified to (g)(2). Effectuating this proposal (to make Sec. 170.314(g)(1) optional) would provide greater regulatory clarity for ONC-ACBs as they determine whether EHR technology meets the 2014 Edition Complete EHR definition. As noted previously in this preamble, we propose to discontinue the use of the Complete EHR concept beginning with the 2015 Edition. If we were to retain the Complete EHR concept for the 2015 Edition, we propose to take the same approach for Complete EHRs as specified in FAQ 28 and in our proposed regulatory changes to Sec. 170.314(g)(1). That is, Complete EHRs would need to be certified to the mandatory ``automated measure calculation'' certification criterion, but not the 2015 Edition ``automated numerator recording'' certification criterion as that would become an optional certification criterion. D. Patient List Creation Certification Criteria The 2014 Edition and proposed 2015 Edition ``patient list creation'' certification criteria (Sec. 170.314(a)(14) and Sec. 170.315(a)(16), respectively) include capabilities that support two MU objectives, one with a percentage-based measure and one without (i.e., ``use clinically relevant information to identify patients who should receive reminders for preventive/follow-up care and send these patients the reminders, per patient preference'' (``patient reminders'') and ``generate lists of patients by specific conditions to use for quality improvement, reduction of disparities, research, or outreach,'' respectively). In situations where EHR technology is presented for certification to a ``patient list creation'' certification criterion (2014 or 2015 Edition) and does not include a capability to support ``patient reminders,'' we clarify it would not need to be certified to the ``automated numerator recording'' certification criterion (Sec. Sec. 170.314(g)(1) for the 2014 Edition and 170.315(g)(1) for the 2015 Edition) nor the ``automated measure calculation'' certification criterion (Sec. Sec. 170.314(g)(2) for the 2014 Edition and 170.315(g)(2) for the 2015 Edition) for ``patient reminders'' percentage-based measure capabilities. E. ISO/IEC 17065 Section 170.503(b)(1) requires applicants for ONC-Approved Accreditor (ONC-AA) status to provide a detailed description of their experience evaluating the conformance of certification bodies to ISO/ IEC Guide 65:1996 (Guide 65). Section 170.503(e)(2) requires the ONC-AA to verify that the certification bodies it accredits and ONC-ACBs conform to, at a minimum, ISO/IEC Guide 65:1996. The International Organization for Standardization (ISO) has recently [[Page 10921]] issued ISO/IEC 17065: 2012 \105\ (ISO 17065), which cancels and replaces Guide 65. The major changes that have been made as compared with Guide 65 are as follows: --------------------------------------------------------------------------- \105\ https://www.iso.org/iso/catalogue_detail.htm?csnumber=46568. ISO slide presentation on 17065: https://www.iso.org/iso/ppt_presentation_17065.ppt. --------------------------------------------------------------------------- Restructuring this International Standard based on the common structure adopted by ISO/CASCO; Modifications based on ISO/PAS 17001, ISO/PAS 17002, ISO/ PAS 17003, ISO/PAS 17004 and ISO/PAS 17005; Introduction of the ISO/IEC 17000 functional approach in the process requirements of Clause 7; Information on the application of this International Standard for processes and services in Annex B; Revision of the terms and definitions in Clause 3; Improvement of the impartiality requirements (mechanism); Consolidation of the management system requirements in Clause 8; Inclusion of principles for product certification bodies and their activities in Annex A; Improvement by taking into account IAF GD 5; and Inclusion of a reference to certification schemes, for which further information is provided in ISO/IEC 17067. The current ONC-AA, American National Standards Institute (ANSI) has already notified the certification bodies it accredits that it will transition accreditation only to ISO 17065 and that all certification bodies it accredits should be accredited to ISO 17065 no later than September 15, 2015. Accordingly, because ISO has replaced Guide 65 with ISO/IEC 17065, we propose to revise Sec. 170.503(b)(1) and (e)(2) to replace the references to Guide 65 with ISO 17065. For Sec. 170.503(b)(1), the change would be effective as of the effective date of the 2015 Edition final rule that would follow this proposed rule. We anticipate that date would occur after we select an accreditation body as the ONC-AA for the next three-year term as ANSI's current term will expire in June 2014. As such, when we next need to assess applicants for ONC-AA status in early 2017, we would expect that any applicant will by then have experience evaluating the conformance of certification bodies to ISO 17065. For Sec. 170.503(e)(2), we propose to require compliance with ISO 17065 beginning in FY 2016 (in other words, as of October 1, 2015). This compliance date should provide sufficient time for certification bodies that are interested in serving as ONC-ACBs, as well as existing ONC-ACBs, to be accredited to ISO 17065 by the ONC-AA. We welcome comments on these proposals. We also propose to revise our references to ISO/IEC standards 17011, 17065 and Guide 65 in Sec. 170.503 by removing or not including the date reference for each standard. The published date information for each standard will continue to be listed in Sec. 170.599. This approach aligns with guidance from the Office of the Federal Register. F. ONC Certification Mark ONC has developed and administers the ``ONC Certified HIT'' certification and design mark (the ``Mark'').\106\ The Mark, as used by an authorized user, certifies that a particular HIT product (Complete EHR, EHR Module, or other types of HIT for which the Secretary of HHS adopts applicable certification criteria, see 45 CFR 170.510) has been tested in accordance with test procedures approved by the National Coordinator; has been certified in accordance with the certification criteria adopted by the Secretary at 45 CFR 170, Subpart C; and has met all other required conditions of the ONC HIT Certification Program at 45 CFR 170, Subpart E. --------------------------------------------------------------------------- \106\ https://www.healthit.gov/policy-researchers-implementers/onc-hit-certification-program. --------------------------------------------------------------------------- We propose to require ONC-ACBs to use the Mark in connection with HIT they certify under the ONC HIT Certification Program. The required use of a singular identifying mark would provide consistency in the recognition of HIT certified under the ONC HIT Certification Program and mitigate any potential market confusion for purchasers of HIT products certified under the ONC HIT Certification Program. The required use of the Mark by all ONC-ACBs for products they certify under the ONC HIT Certification Program would offer more clarity and assurance to purchasers as compared to the use of separate and distinct marks by each ONC-ACB to indicate a product has been certified under the ONC HIT Certification Program. The required use of the Mark would also make clear that an HIT product was certified under the ONC HIT Certification Program versus another certification program for HIT (e.g., in cases where a certification body is both an ONC-ACB and administers other certification programs outside of the ONC HIT Certification Program). We propose to revise Sec. 170.523 (``Principles of Proper Conduct'') to require ONC-ACBs to display the Mark on all certifications issued under the ONC HIT Certification Program in a manner that complies with the Criteria and Terms of Use for the ONC Certified HIT Certification and Design Mark (``Terms of Use'').\107\ In addition, we propose to revise Sec. 170.523 to require ONC-ACBs to ensure that use of the Mark by HIT developers whose products are certified under the ONC HIT Certification Program is compliant with the Terms of Use. In the event that the Terms of Use are revised or updated, compliance with the most recent version would be required. --------------------------------------------------------------------------- \107\ https://www.healthit.gov/sites/default/files/hit_certificationterms_of_use_final.pdf. --------------------------------------------------------------------------- G. ``Certification Packages'' for EHR Modules As we look toward the potential expansion of our certification program to support the various types of health care providers who are not eligible for EHR incentive payments under Medicare or Medicaid, we recognize that we can continue to improve the ease with which our regulatory concepts (for both MU and non-MU purposes) can be communicated to the general public and to EHR Module purchasers. In that regard, we believe it would be helpful to establish the concept of predefined ``certification packages'' that would reflect groupings of certification criteria. We intend for this concept to make it easier for stakeholders to communicate and understand the functionality an EHR Module includes and the certification criteria to which it is certified. As explained below, we propose to: (1) Identify subsets of certification criteria as ``certification packages,'' beginning with the 2015 Edition; and (2) Require ONC-ACBs to ensure that EHR Module developers make accurate representations concerning certification packages on their Web sites and in marketing materials, communications statements, or other assertions related to an EHR Module's certification. We propose and seek public comment on the following two certification packages: ``care coordination'' and ``patient engagement.'' We also seek comment on the specific certification criteria we have proposed to assign to those packages. As noted above, we propose that package designations would only be applicable to certifications issued to EHR Modules (MU and non-MU) certified to the 2015 Edition EHR certification criteria. We propose to define ``certification package'' in Sec. 170.502 as an identified set of certification criteria adopted by the Secretary in subpart C of part 170 [[Page 10922]] that represent a specific grouping of capabilities. We also propose definitions in Sec. 170.502 for ``2015 Edition Care Coordination Package'' and ``2015 Edition Patient Engagement Package'' that each identify the set of specific certification criteria to which an EHR Module needs to be certified, at a minimum, in order for its EHR Module developer to represent that the EHR Module meets the requirements of a particular package. Care Coordination Package: This package would require an EHR Module to be certified to, at a minimum, the proposed 2015 Edition EHR certification criteria at Sec. 170.315(b)(1) (Transitions of care); and Sec. 170.315(b)(2) (Clinical information reconciliation and incorporation). With respect to this package, we solicit comment on: (1) Whether we should also include Sec. 170.315(h)(1) (Transmit--Applicability Statement for Secure Health Transport) in order to require that an EHR Module labeled with this package is also certified to the transmission certification criterion focused on the primary Direct Project specification; (2) whether it should be a more general requirement to be certified to any one of the Sec. 170.315(h) transmission certification criteria (which could risk some organizations adopting an EHR Module labeled with ``care coordination package'' being unable to exchange with each other because their separate EHR Modules came with different transmission capabilities); (3) whether we should require that the EHR Module be certified to both Sec. 170.315(h)(1) and Sec. 170.315(h)(3) (i.e., ``Direct'' and SOAP); and (4) whether including any of the transmission criteria in Sec. 170.315(h) as part of the package would recreate the same ``binding'' effect that we proposed to decouple earlier in this preamble (see the discussion of the ``Transitions of Care'' certification criterion in section III.A). Patient Engagement Package: This package would require an EHR Module to be certified to, at a minimum, the proposed 2015 Edition EHR certification criteria at Sec. 170.315(e)(1) (View, download and transmit to a 3rd party); and Sec. 170.315(e)(3) (Secure messaging). With respect to this package, we solicit comment on whether we should include Sec. 170.315(a)(16) (Patient list creation), Sec. 170.315(a)(17) (Patient-specific education resources), or both. While these capabilities are more functional than exchange-oriented, they could complement and enhance the two certification criteria we have proposed to be part of the Patient Engagement Package. We clarify that if an EHR Module were certified to the certification criteria included in a certification package definition, then the EHR Module developer would be able to indicate this fact without the need for any additional determination to be made by the ONC-ACB. In other words, ONC-ACBs would not have to perform any additional analysis or make any additional determination before an EHR Module developer could indicate that its certified EHR Module meets a certification package definition. However, to ensure that certification packages are represented accurately to potential purchasers and users of EHR Modules, we propose to modify Sec. 170.523(k)(1) to require ONC-ACBs to ensure that an EHR Module developer accurately represents the certification packages its EHR Module meets if and when the EHR Module developer uses the certification package designation(s) on its Web site and in marketing materials, communications statements, or other assertions related to the EHR Module's certification. Although ONC-ACBs are already required to ensure that the certifications issued to EHR Modules (which would indicate the criteria to which the EHR Module is certified) are accurately represented by EHR Module developers, this proposed provision would expressly impose the requirement with regard to certification packages. We also clarify that the certification criteria included in a certification package would be a minimum threshold, meaning that an EHR Module could be certified to other certification criteria adopted by the Secretary in subpart C of part 170 in addition to the certification criteria included in the certification package at issue. Thus, in the event that an EHR Module presented for certification satisfies the certification criteria included in each of the proposed certification packages and is also certified to other certification criteria, it could be so indicated by the EHR Module developer to its customers. For example, it could be certified as a non-MU EHR Module with care coordination and patient engagement packages. Again, we believe this certification package approach could simplify communication between EHR Module developers and purchasers as well as make EHR Modules that meet a certification package definition easier to identify on the CHPL. We intend to indicate on the CHPL the certification packages an EHR Module satisfies based on whether the certification criteria to which the EHR Module is certified satisfy one or more certification package definitions. We believe this simplification may be especially valuable to health care providers that are ineligible to receive incentive payments under the EHR Incentive Programs because the EHR Module developers that serve them may only seek EHR Module certification to certification criteria included in a package. V. Other Topics for Consideration for the 2017 Edition Certification Criteria Rulemaking In this section, we specifically request comment on issues we are considering addressing in the rulemaking in which we would propose to adopt the 2017 Edition certification criteria. A. Additional Patient Data Collection We are considering whether we should require the collection and use of certain patient generated data in the 2017 Edition. We believe there are valid reasons and evidence, as discussed below, for certification to ensure that EHR technology is capable of recording data beyond those currently required for MU. However, we believe it best to present these data and rationale for public consideration and comment before including them in any proposed 2017 Edition certification criteria. For the data discussed below, we anticipate that they would be proposed in a 2017 Edition rulemaking as part of a new or existing certification criterion that would require EHR technology to: Enable a user to electronically record, change, and access the [data]; and Record a patient's response as ``declined to provide.'' The functionality under consideration to record the data discussed below has no bearing on whether a patient chooses to provide this information or whether a health care provider chooses to record the information or would be required to do so through the EHR Incentive Programs or other programs. Further, while the certification criterion or criteria that we are considering for these data would not require to EHR technology to have the capability to electronically transmit the information, we welcome comments on whether we should also consider that capability as well. In considering the appropriateness of the data elements and standards below, please comment on whether these data elements should be include in: A 2017 Edition ``demographics'' certification criterion (i.e., in a criterion with the functionality to enable a user to electronically record, change, and access patient data on preferred [[Page 10923]] language, sex, race, ethnicity, and date of birth); New standalone certification criteria for each data element; and/or New certification criteria together (e.g., disability, sexual orientation and gender identity in one certification criterion with veterans status and occupation status in a separate certification criterion). Disability Information and Accommodation Requests In discussions with the HHS Office for Civil Rights and HHS Administration for Community Living/Center for Disability and Aging Policy, we have considered the potential benefits to patients and health care providers alike if EHR technology could enable a user to electronically record, change, and access information about a patient's disability status and any accommodate requests. For example, a patient may have limited sight or mobility and may need patient aids to interact with the provider or with the provider's EHR technology (e.g., a patient portal or secure messaging). We believe that health care providers could be better prepared to engage and treat patients with disabilities when they seek care if they were aware of the patient's disability status and any accommodate requests. Accordingly, we seek comment on whether certification should require that EHR technology be capable of enabling a user to electronically record, change, and access disability information and/or accommodation requests. The following are a potential list of questions that could be asked related to disability information and accommodation requests. The questions (except for the Limited English Proficiency one) were adapted from questions that were approved by the Data Council and promulgated by the HHS Secretary under Section 4302 of the Affordable Care Act.\108\ The questions align with the Census Bureau's American Community Survey \109\ and are designed to characterize functional disability. The questions reflect how disability is conceptualized consistent with the International Classification of Functioning, Disability, and Health and serve as the minimum standard for collecting population survey data on disability status. As we mentioned in the 2014 Edition Final Rule, unlike clinical cognitive or functional status assessments, this information can be used by health care providers to better accommodate and respond to individual patient needs.\110\ --------------------------------------------------------------------------- \108\ https://minorityhealth.hhs.gov/templates/content.aspx?ID=9232#1. \109\ https://www.census.gov/people/disability/methodology/acs.html. \110\ 77 FR 54256. --------------------------------------------------------------------------- 1. Are you deaf or do you have difficulty hearing? If so, what special assistance may you need? 2. Are you blind or do you have difficulty seeing, even when wearing glasses? If so, what assistance may you need? 3. Because of a physical, mental, or emotional condition, do you have serious difficulty concentrating, remembering, or making decisions? (patients 5 years old or older).\111\ If so, what assistance may you need? --------------------------------------------------------------------------- \111\ The specified age designations mean that the questions that include these designations only apply to patients older that the specified age. The underlying assumption is that patients younger than the specified age would inherently have the difficulties inquired about. This is consistent with the American Community Survey methodology. --------------------------------------------------------------------------- 4. Do you have difficulty walking or climbing stairs? (patients 5 years old or older) If so, what assistance may you need? 5. Do you have difficulty dressing or bathing? (patients 5 years old or older). If so, what assistance may you need? \112\ --------------------------------------------------------------------------- \112\ For the purposes of this question, dressing and bathing are considered functionally similar (strength, range of motion, transferring and supporting abilities) as the question seeks to generally determine the patient's functional ability and not attribute a ``yes'' to either ability or to be used for research purposes. This question will allow individuals recovering from long illnesses, paralysis, or post-surgery limitations to choose ``yes,'' and then identify issues they may need assistance with. --------------------------------------------------------------------------- 6. Because of a physical, mental, or emotional condition, do you have difficulty doing errands alone such as visiting a doctor's office or shopping? (patients 15 years old or older). If so, what assistance may you need? 7. Do you have difficulty communicating, reading, or do you have limited proficiency in English? If so, what assistance may you need? We request comment on whether: These questions are the right questions to ask (with yes/ no responses and a field for additional explanation); These questions and answers can be accurately and efficiently recorded in an EHR; There are alternative questions that could be asked related to disability status and additional assistance requests; There are other ways for capturing patients' needs in EHR technology and patients' needs related to interacting with EHR technology; and There are any available standards that could be used to capture in an EHR the listed questions (and answers) or any disability information and accommodation requests in a structured way. For example, would the following standards be appropriate for the associated information or suffice to code the listed questions and answers: [cir] ICF (International Classification of Functioning, Disability and Health) for categories of function; [cir] LOINC[supreg] for assessment instruments; and [cir] SNOMED CT[supreg] for appropriate responses. As we noted in the introduction to this section, while the certification criterion that we are considering for capturing disability status and accommodation requests would not require EHR technology to have the capability to electronically exchange the information, we welcome comments on the appropriateness of such functionality and whether the seven specified questions above or other recorded disability status and accommodation request information could be efficiently exchanged in structured data, if appropriate. We note that the 2014 Edition ``transition of care'' certification criteria and the proposed 2015 Edition ``transition of care'' certification criterion already include requirements for EHR technology to be capable of using the Consolidated CDA for exchanging patient data on cognitive and functional status. Sexual Orientation and Gender Identity In response to the 2014 Edition NPRM, we received comments requesting the inclusion of sexual orientation and gender identity as data EHR technology should be able to record as part of the ``demographics'' certification criterion. For the 2014 Edition EHR certification criterion, we declined to include these data elements as the data elements included in the certification criterion were limited to only those necessary to support the associated MU objective and measure. Since the 2014 Edition Final Rule was published, the IOM issued ``Collecting Sexual Orientation and Gender Identity Data in Electronic Health Records: Workshop Summary.'' \113\ This summary illustrates the clinical relevance for collecting information on both sexual orientation and gender identity. Specifically, the collection of this information can help to address health disparities for Lesbian, Gay, Bisexual and Transgender (LGBT) patients, including access to care and the quality [[Page 10924]] of care. Conversely, concerns have been raised about the need to balance privacy and security with data flow needs. For example, there are some additional protections required for data collected in federally funded substance abuse treatment programs regarding who has access to such data, but there are not similar additional protections for sexual orientation and gender identity data. Therefore, we seek comment on whether certification should require that EHR technology be capable of enabling a user to electronically record, change, and access data on a patient's sexual orientation and gender identity. To facilitate the standard capturing of this data, we request comment on whether the following code sets could be used to capture this information in a structured format: --------------------------------------------------------------------------- \113\ https://www.iom.edu/Reports/2012/Collecting-Sexual-Orientation-and-Gender-Identity-Data-in-Electronic-Health-Records.aspx. --------------------------------------------------------------------------- SNOMED CT[supreg] for sexual orientation.\114\ --------------------------------------------------------------------------- \114\ Codes of: Asexual; bisexual; gay; heterosexual; lesbian; questioning (a person who is questioning his or her sexual orientation); decline to answer; and not applicable (ages 0-17). --------------------------------------------------------------------------- SNOMED CT[supreg] for gender identity.\115\ --------------------------------------------------------------------------- \115\ Codes of: Gender variant; man; intersex; questioning (a person who is questioning his or her sexual orientation); transgender; woman; decline to answer; and not applicable (ages 0- 17). These codes were recommended for creation by HL7, but not have yet been updated within SNOMED CT[supreg]. --------------------------------------------------------------------------- U.S. Military Service In recent years, U.S. Military service members have been returning from service in Iraq and Afghanistan and other various combat duty stations. A portion of these service members are returning with traumatic brain injuries, major limb injuries, and diagnoses of post- traumatic stress disorder as reported by the Department of Defense and Department of Veterans Affairs. Overall, the Veterans Health Administration (Department of Veterans Affairs) provides medical care to over 8.76 million veterans each year.\116\ Because the Department of Veterans Affairs has eligibility requirements to be considered eligible for veterans' benefits and that process takes into consideration a variety of factors, we do not seek comment on EHR technology's ability to record ``veteran status.'' However, we do seek comment on whether EHR technology should be capable of recording whether a patient has served in the U.S. Military. We believe recording U.S. Military service information can have many benefits. It can help in identifying epidemiological risks for patients such as those noted above. It can assist in ensuring that a patient receives all the health care benefits he or she is entitled to by alerting medical professionals to the patient's U.S. Military service history, which can facilitate the coordination of benefits. This information can also increase the ability to assemble a longitudinal record of care for a U.S. service member, such as by requesting or merging of a patient's electronic health record stored by the Department of Defense, Veteran's Health Administration, and/or another health care provider. Accordingly, we seek comment on whether certification should require that EHR technology be capable of enabling a user to electronically record, change, and access U.S. Military service information. We also seek comment on whether the ``U.S. Military service'' data element should be expanded to encompass all uniformed service members, including commissioned officers of the U.S. Public Health Service and the National Oceanographic and Atmospheric Administration as they too are eligible for veterans benefits and related services. --------------------------------------------------------------------------- \116\ https://www.va.gov/health/. --------------------------------------------------------------------------- In terms of electronically capturing U.S. Military service, we request comment on the following: Use of the following concepts for coding U.S. Military service in EHR technology: History of Employment in U.S. Military; No History of Employment in U.S. Military; and Currently Employed by U.S. Military. Whether it would be appropriate to capture the actual start date and date of separation from service. Whether EHR technology should be able to record the foreign locales in which the service member had recently served. Whether there are better concepts/values that could capture information related to U.S. Military status or uniformed service status, including through capturing occupational status and use of occupational code sets. As we noted in the introduction to this section, while the certification criterion that we are considering for capturing U.S. Military service would not require EHR technology to have the capability to electronically exchange the information, we welcome comments on the appropriateness of such functionality. We understand that the Consolidated CDA Social History Observation section could accommodate military or uniformed service status pending the assignment of specific codes (e.g., SNOMED CT), which would enable it to be exchanged as part of a summary care record. Therefore, we seek comment on the feasibility of capturing military or uniformed service status in the Consolidated CDA and whether the 2017 Edition should require EHR technology to be capable of exchanging this data (e.g., in the 2017 Edition ``transition of care'' certification criterion). Work Information--Industry/Occupation The Institute of Medicine has identified patients' work information as valuable data that could be recorded by EHR technology and used by both health care providers and public health agencies.\117\ Similarly, the 2012 HHS Environmental Justice Strategy and Implementation Plan echoed the potential benefits of having work information in EHR technology.\118\ The combination of current industry and occupation (I/ O) information provides opportunities for health care providers to improve patient health outcomes--both for health issues wholly or partially caused by work and for health conditions whose management is affected by work. For example, ``Usual'' (longest-held) I/O information can be key for health care improvement and population-based health investigations, and is already a required data element for cancer reporting.\119\ Health care providers can use also I/O information to assess symptoms in the context of work activities and environments, inform patients of risks, obtain information to assist in return-to- work determinations, and evaluate the health and informational needs of groups of patients. --------------------------------------------------------------------------- \117\ IOM (Institute of Medicine). 2011. ``Incorporating Occupational Information in Electronic Health Records: A Letter Report''. Available at: https://www.nap.edu/catalog.php?record_id=13207. \118\ U.S. Department of Health and Human Services. February, 2012. 2012 HHS Environmental Justice Strategy and Implementation Plan. Available at: https://www.hhs.gov/environmentaljustice/strategy.html. \119\ CDC (2) (Centers for Disease Control and Prevention). 2012. Implementation Guide for Ambulatory Healthcare Provider Reporting to Central Cancer Registries, HL7 Clinical Document Architecture (CDA) Release 1.0, August 2012. Available at: https://www.cdc.gov/phin/library/guides/Implementation_Guide_for_Ambulatory_Healthcare_Provider_Reporting_to_Central_Cancer_Registries_August_2012.pdf. --------------------------------------------------------------------------- The National Institute for Occupational Safety and Health (NIOSH) and other stakeholders are working to develop and support standards and tools for the collection, storage, and exchange of I/O information. It has developed a relational information model of work information (including I/O) for EHR technology and is in the process of translating it into the HL7 reference information model format. NIOSH is also working with HL7 to reflect functionality for work information in [[Page 10925]] EHR technology and is collaborating with other stakeholders to ensure that I/O information is incorporated into interoperability standards, such as standards to support case reporting to public health. A reusable CDA template of Occupational Data for Health (ODH) is part of the social history section within the published Healthy Weight (HW) trial implementation profile,\120\ which has been tested at the 2014 Integrating the Healthcare Enterprise Connectathon.\121\ In addition, prototype occupation-related CDS knowledge bases for primary care providers are in development. --------------------------------------------------------------------------- \120\ https://www.ihe.net/uploadedFiles/Documents/QRPH/IHE_QRPH_Suppl_HW.pdf. \121\ https://www.ihe.net/Connectathon/. --------------------------------------------------------------------------- Widely used code sets are available for converting narrative I/O text into structured data. The combination of Bureau of Census (BOC) I/ O codes \122\ and NIOSH-added codes (e.g., for unpaid workers)-- identified as the CDC--Census system in the Public Health Information Network Vocabulary Assignment and Distribution System (PHIN VADS) \123\--can be used to code patient I/O in EHR technology. The CDC-- Census code sets are already used to classify the I/O information provided by respondents in most major U.S. health surveys. Given all of the effort by NIOSH and other stakeholders to advance this important work, we request comments on whether we should propose as part of the 2017 Edition that EHR technology be capable of enabling a user to electronically record, change, and access the following data elements for certification: --------------------------------------------------------------------------- \122\ Census (1) (United States Census Bureau). 2012. Industry and Occupation. Available at: https://www.census.gov/people/io/methodology/indexes.html. \123\ PHIN Vocabulary Access and Distribution System. 2012. Available at: https://www.cdc.gov/phin/tools/PHINvads/. --------------------------------------------------------------------------- Narrative text for both current and usual industry and occupation (I/O), with industry and occupation for each position linked and retained in perpetuity and time stamped. CDC--Census codes for both current and usual I/O, with industry and occupation for each position linked and retained in perpetuity and time stamped. We solicit public comment on the experience EHR technology developers, EPs, EHs, and CAHs have had in capturing, coding, and using I/O data. Further, as cited under the U.S. Military service discussion above, I/O codes may be appropriate for coding U.S. Military service or uniformed service, as both data elements capture information on positions held/work performed and exposures. The Department of Veterans Affairs and HHS are currently assessing how best to appropriately and efficiently capture I/O information and military service information about patients in EHR technology. We welcome comments and suggestions on any potential options we should consider for our assessment. B. Medication Allergy Coding General allergy types can be coded using the RxNorm vocabulary that we have adopted in our rules. However, for coding medication allergies, RxNorm is not specific enough to distinguish allergies to particular ingredients in drugs nor is it specific enough for coding food-drug allergies. Allergic reaction symptoms and DDI reactions can be coded using the SNOMED CT vocabulary also adopted in our rules, but there is no specific reaction value set and using general problem value sets do not allow for identification of the allergy's cause. No formal reaction list has been defined in the C-CDA or through the work done by the Health Information Technology Standards Panel.\124\ In the HITPC's meaningful use Stage 3 Request for Comment, stakeholders commented that other vocabulary and value sets could be leveraged to address these gaps. These include: --------------------------------------------------------------------------- \124\ https://www.hitsp.org/. --------------------------------------------------------------------------- The FDA Unique Ingredient Identifier (UNII) system which can be used to identify unique ingredients in drugs, biologics, food, and devices; The VA National Drug File--Reference Terminology (NDF-RT) vocabulary which has been mapped to RxNorm and may be a good standard for describing allergies to classes of drugs such as penicillin. Additionally, CDC has developed a value set for Vaccine Reaction and Adverse Events \125\ that is available but not currently assigned to drug and general allergic reactions. --------------------------------------------------------------------------- \125\ https://phinvads.cdc.gov/vads/ViewValueSet.action?id=635A4FEA-8232-E211-8ECF-001A4BE7FA90. --------------------------------------------------------------------------- The HITPC has indicated \126\ that EHR systems should provide functionality to code medication allergies, including the related drug family for reactions. Currently, we require that CEHRT base CDS interventions on certain data (including medication allergies) but this list does not specifically include DDI reactions. Given these issues, we solicit comment on: --------------------------------------------------------------------------- \126\ https://www.healthit.gov/sites/default/files/hitpc_stage3_rfc_final.pdf. --------------------------------------------------------------------------- (1) The adoption of additional vocabularies to code medication allergies to drug ingredients, allergic reaction symptoms, and DDI reactions (e.g., UNII, NDF-RT); (2) Whether we should adopt the CDC Vaccine Reaction and Adverse Event value set; (3) The value of using specific reaction value sets versus general problem value sets; (4) Whether CDS interventions should be based on DDI reactions. C. Certification Policy for EHR Modules and Privacy and Security Certification Criteria In our past rulemakings we have discussed and instituted two different policy approaches for ensuring that EHR Modules meet privacy and security (P&S) certification criteria while minimizing the level of regulatory burden imposed on EHR technology developers. In the 2011 Edition, we required that EHR Modules must meet all P&S certification criteria unless the presenter could demonstrate that certain P&S capabilities were either technically infeasible or inapplicable. In the 2014 Edition, we eliminated the requirement for each EHR Module to be certified against the P&S criteria. Rather, the P&S criteria were made part of the ``Base EHR definition'' that all EPs, EHs, and CAHs must have EHR technology certified to meet, in order to ultimately have EHR technology that satisfied the CEHRT definition. While some commenters expressed concern with our 2014 Edition proposal to remove the P&S certification requirement for EHR Modules, we finalized the policy in favor of the outcome-oriented requirement we believed the Base EHR definition promoted, and in an effort to enable EHR technology developers to better choose which P&S criteria were most applicable to their products. As of December 31, 2013, approximately 70% of 2014 Edition EHR Modules have been certified to at least one P&S criterion (out of nine available P&S criteria) and about 51% have been certified to four or more. Despite prior stakeholder concerns, this data suggests that our 2014 Edition Final Rule policy has not resulted in a significant reduction in the number of EHR Modules certified to P&S criteria and that a majority of EHR technology developers appear to be pursuing certification to these criteria regardless of our more flexible, less burdensome policy for 2014 Edition certification. On March 23, 2013, the HITSC recommended that we should change our EHR Module certification policy for P&S. They recommended that each EHR Module presented for certification should be certified through one or more of the following three paths: [[Page 10926]] Demonstrate, through system documentation and certification testing, that the EHR Module includes functionality that meets at least the ``minimal set'' \127\ of privacy and security certification criterion. --------------------------------------------------------------------------- \127\ The minimal set includes Authentication, access control, and authorization, Auditable events and tamper resistance, Audit report(s), Amendments, Automatic log-off, Emergency access, End-user device encryption, and Integrity. The full recommendation can be found at: https://www.healthit.gov/sites/default/files/pswgtransmittalmemo_032613.pdf. --------------------------------------------------------------------------- Demonstrate, through system documentation sufficiently detailed to enable integration, that the EHR Module has implemented service interfaces that enable it to access external services necessary to conform to the ``minimal set'' of privacy and security certification criterion. Demonstrate through documentation that the privacy and security certification criterion (and the minimal set that the HITSC defined) is inapplicable or would be technically infeasible for the EHR Module to meet. In support of this path, the HITSC recommended that ONC develop guidance on the documentation required to justify inapplicability or infeasibility. As a result of the HITSC recommendations and stakeholder feedback, we seek comment on the following four options we believe could be applied to EHR Module certification for privacy and security: Option 1: Re-Adopt the 2011 Edition approach. Option 2: Maintain the 2014 Edition approach. Option 3: Adopt the HITSC recommendation. This approach reintroduces some of the challenges we sought to avoid with our current policy and introduces potentially new administrative burdens for EHR technology developers. Option 4: Adopt a limited applicability approach--under this approach, ONC would establish a limited set of P&S functionality that every EHR Module would be required to address in order to be certified. For example, we could require that all EHR Modules need to address the authentication, access control, and authorization certification criterion. This approach has the same downsides as options 1 and 3 but to a lesser extent given that its broad applicability could still result in EPs, EHs, and CAHs adopting EHR Modules that had been certified with duplicative capabilities. We seek feedback on all of these policy options. Further we especially solicit feedback: (1) from EHR technology developers and ONC-ACBs regarding the efficiency of the current certification policy; (2) from stakeholders that prefer ``option 3'' (the HITSC's recommendation) and why; and (3) from stakeholders that prefer ``option 4'' what the minimum P&S criteria could be. D. Provider Directories We have received feedback from many different stakeholder groups that a single standard for ``provider directories'' is needed. The impetus for this feedback appears to be MU Stage 2's added exchange requirements and a general industry need to find providers electronic service information. In June 2011, The HITPC recommended \128\ that we consider the adoption of provider directory capabilities in our certification program as well as work to address many of the issues they raised. To address the HITPC's recommendations, ONC launched a number of initiatives to define a single provider directory standard and to pilot its use. In August 2013, the HITPC recommended including a provider directory standard in MU Stage 3.\129\ --------------------------------------------------------------------------- \128\ https://www.healthit.gov/sites/default/files/pdf/HITPC_transmit_InfoExchWG_May2011-finalsigned.pdf. \129\ https://www.healthit.gov/FACAS/sites/faca/files/IE%20WG_Recommendation%20Transmittal_MU3v2.docx. --------------------------------------------------------------------------- After multiple discussions and guidance with subject matter experts in the field, we found that the main gap that stakeholders would like ONC to address through EHR certification is the ability to be able to query individual directory sources and directory sources federated by third parties such as HIOs, RHIOs, HISPs etc. This is also known as ``federated querying.'' However, we also discovered that there were only a few implementations of federated querying across the country and many were unique due to the lack of a single standard. Given this challenge, and its potential to inhibit exchange, ONC launched an open source project called ``Modular Specification Provider Directories (MSPD).'' \130\ --------------------------------------------------------------------------- \130\ https://modularspecs.siframework.org/Provider+Directories+Homepage. --------------------------------------------------------------------------- During this project stakeholders collaborated to identify requirements for the next version of ``Healthcare Provider Directory (HPD)'' in order to provide a unified vendor-neutral platform for implementation of provider directories that supports both federated and non-federated architectures. The project resulted in implementable, testable specifications, and high quality test cases that verify conformance to the ``test implementation'' which is created based on the MSPD IG. In addition, ONC awarded a grant to the EHR [bond] HIE Interoperability Workgroup \131\ to pilot provider directory standards with multiple states. --------------------------------------------------------------------------- \131\ https://www.interopwg.org/ --------------------------------------------------------------------------- It is our understanding that the current HPD standard created by Integrating the Healthcare Enterprise (IHE) \132\ only addresses transactions between the client and a single provider directory with a single data source. While the standard can be used for federation, it does not address the complexities introduced by federation; provide a well-defined and straightforward approach to error handling, support targeted queries to federated data sources, or define mechanisms by which to distinguish the source of results in a given response. ONC is currently working with IHE and other stakeholders to solve these issues with an updated HPD standard. --------------------------------------------------------------------------- \132\ https://wiki.ihe.net/index.php?title=Healthcare_Provider_Directory. --------------------------------------------------------------------------- In collaboration with IHE we believe that a new HPD standard will be ready in early 2014 that will support federated querying of provider directories. As a result, we believe that the updated HPD standard will be ready to propose for adoption as part of the 2017 Edition rulemaking and included in a certification criterion focused on capabilities to query provider directories. Accordingly, we seek public comment on the following potential capabilities we are considering for such a certification criterion: At a minimum, EHR technology would need to be able to query provider directories for the following information and electronically process the response returned in accordance with the MSPD IG requirements (which are expected to be adopted by IHE USA as an IHE USA profile): Query for an individual provider; Query for an organizational provider; Query for relationships between individual providers and organizational providers. E. Oral Liquid Medication Dosing Our strategic goal is to provide more granular descriptions of prescriptions to allow for CDS, identify patient safety issues (such as excessive acetaminophen in combination medications), and reduce dosing confusion. For example, the U.S. currently uses the English measurement system standard (e.g., teaspoons) rather than the metric standard (e.g., milliliters (mL)) for prescribing liquid oral medications. The medication dose is [[Page 10927]] determined in part by the patient's weight. The metric standard (mL) offers more precision in medication dose, which can decrease preventable adverse drug events. Dosing errors are the most common medication error in pediatrics.\133\ The American Academy of Pediatrics (AAP) supports the use of the metric standard (mL) for e- prescribing.\134\ AAP supports modification of both dosing guidelines and dose-screening parameters to support dosing for every indication that warrants modified dosing regimens.\135\ The Food and Drug Administration has provided a draft guidance that supports metric units for labeling prescription medications.\136\ And, the National Council for Prescription Drug Programs supports mL dosing in retail dispensing.\137\ --------------------------------------------------------------------------- \133\ Wong IC, Ghaleb MA, Franklin BD, Barber N. Incidence and nature of dosing errors in pediatric medications: A systematic review. Drug Saf. 2004;27(9):661-670. \134\ AAP Council on Clinical Information Technology Executive Committee, 2011-2012. Policy Statement--Electronic Prescribing in Pediatrics: Toward Safer and More Effective Medication Management. Pediatrics 2013; 131;824. \135\ Johnson KB, Lehmann CU, and the AAP Council on Clinical Information Technology. Technical Report--Electronic Prescribing in Pediatrics: Toward Safer and More Effective Medication Management. Pediatrics 2013;131;e1350. \136\ FDA Draft Guidance for Industry on Safety Considerations for Container Labels and Carton Labeling Design To Minimize Medication Errors. April 24, 2013. https://www.federalregister.gov/articles/2013/04/24/2013-09640/draft-guidance-for-industry-on-safety-considerations-for-container-labels-and-carton-labeling-design. \137\ https://www.ncpdp.org/Educational-Summit-Session.aspx?ID=6. --------------------------------------------------------------------------- We understand that e-prescribing functionality can present standard dosing formula to use the patient's weight to: Calculate a dose; convert the dose to a volume for liquids; and present the dose in a format that is least likely to be confusing to a prescriber, pharmacist, nurse, or patient. Sophisticated e-prescribing functionality has been said to use individual dose limits, compared to weight- or body surface area-based normal values. Given the clinical need and stakeholder support for reducing preventable adverse events resulting from dosing errors in e- prescribing, we solicit comment on whether we should adopt a certification criterion (or establish a requirement within a certification criterion) for EHR technology to use the metric standard for prescribing oral liquid medications or to solve the problem more generally using a structured Sig \138\ standard. Potential (non- mutually exclusive) options for certification include, but are not limited to: --------------------------------------------------------------------------- \138\ A prescription contains a number of different elements. In addition to the patient and prescriber information, it must state the name, dosage form and strength of the medication; the dose; the amount to be dispensed; the number of refills; and the directions for use, or Sig. ``Sig'' is an abbreviation for ``signatura,'' Latin for ``Mark thou''. The Sig contains the instructions explaining how the patient is to take the medication. https://www.ncpdp.org/pdf/Sig_standard_imp_guide_2006-06.pdf. --------------------------------------------------------------------------- Require EHR technology to use a structure Sig with explicit dosing units, frequency, and number of units; Require EHR technology to provide the metric standard as one option to record liquid medication doses; Require EHR technology to record liquid medication doses in the metric standard only; and Require EHR technology to be able to accurately convert a liquid dose to the metric standard. For this last option, we are also soliciting comment on minimum/maximum dosing checks for dose conversion. We also solicit comment on EHR readiness to implement the metric standard for prescribing oral liquid medications, the effect on existing vocabulary standards for units of measurement (e.g., UCUM), and implications on the structured Sig format for e-prescribing. F. Medication History Knowing a patient's medication history can assist providers in making decisions about a patient's health, reduce the amount of time spent on administrative tasks around medication prescribing and reconciliation, improve patient safety, and quality of care in all health care settings. We are aware of current technology that provides medication history information through e-prescribing and EHR systems from community pharmacies and patient medication claims history. Current medication history services provide information such as patient compliance with prescribed medications, therapeutic interventions, drug-drug and drug-allergy interactions, adverse drug reactions, duplicative therapy, the numbers of pharmacies and physicians, and frequency of prescription refills. In a few cases, medication history services are provided through state and regional health information exchanges. In the 2014 Edition, we adopted the NCPDP SCRIPT 10.6 standard for e-prescribing (170.314(b)(3)). SCRIPT 10.6 supports a medication history source feature that provides where the history was obtained and the identity of the source, as well as consolidates histories from different sources. We solicit comments on whether we should propose a 2017 Edition certification criterion focused on medication history capabilities. We encourage commenters to address the specific information/specific capabilities that should be provided, standards recommended to support this capability, and which existing certification criterion/criteria could include this capability (e.g., medication reconciliation, medication list, e-prescribing) if it were not a stand-alone certification criterion. G. Blue Button + We are interested in feedback on the adoption of separate certification criteria for Blue Button + (BB+) capabilities as part of our 2017 Edition rulemaking. Blue Button+ is the ability to get patient records in a human-readable and machine-readable format, and allows the patient send them where they choose. This enables a consumer to do everything from printing a physical copy to sharing it with a third party application. Since the publication of the 2014 Edition Final Rule both members of the public and the HITSC have expressed interest in promoting Blue Button +. Specifically, stakeholders have indicated an interest in using the BB+ Direct Specifications, currently in pilot phase of the S&I Framework's BB+ Representational State Transfer (REST) workgroup,\139\ and the BB+ RESTful API. The BB+ Direct Specifications add two functions beyond the MU Stage 2 requirements: the ability to use triggers to automate a ``Direct message'' to the patient after each encounter or when new clinical information is added to the record; and the ability to load certificate bundles, including the Blue Button certificate bundle. The BB+ REST specifications do not change content specifications, but include substantial changes to authentication and authorization using OAuth and OpenID, and Transport using FHIR instead of the Direct Protocol. Given stakeholder interest in the BB+ initiative's work and the significant benefits it could have for patients, we solicit comments on the following: --------------------------------------------------------------------------- \139\ More information on the S&I Framework's BB+ REST workgroup can be found at https://wiki.siframework.org/BlueButton+Plus+Pilots. --------------------------------------------------------------------------- (1) Is there a market need for BB+ certification? In other words, would health IT developers find value in a BB+ certification that would enable them to say they are ``BB+ compliant'' or ``BB+ ready''; (2) Which elements of BB+ Direct Specifications would be most important [[Page 10928]] to reference in a certification criterion and how would they be tested; and (3) What elements of BB+ REST Specifications would be most important to reference in a certification criterion and how would they be tested? Additionally, what use cases would be uniquely supported by BB + REST Specifications? H. 2D Barcoding Using barcode symbols on items with specific details, including specifications of the dispensed unit, has the potential to reduce medication and transcription errors.\140\ In 2004, the FDA issued the ``Bar Code Label Requirements for Human Drug Products and Biological Products Final Rule'' \141\ for the barcoding of pharmaceutical and biological products. The regulation required the National Drug Code (NDC) to be barcoded on certain pharmaceutical and biological items used in health care facilities using a linear barcode. --------------------------------------------------------------------------- \140\ https://www2.aap.org/immunization/pediatricians/pdf/barcoding_guidance_manufacturers_022212.pdf. \141\ https://www.fda.gov/ohrms/dockets/98fr/04-4249.htm. --------------------------------------------------------------------------- Implementation of two-dimensional (2D) barcodes on drug products and biologics such as vaccines can allow for rapid, accurate, and automatic capture of data by a handheld imaging device or scanner to populate fields in an EHR or specialty registry. 2D barcodes can contain more information than linear barcodes in a smaller space.\142\ We are aware that 2D barcodes using the GS1 DataMatrix Barcodes standard are being introduced for unique device identifiers and vaccines. --------------------------------------------------------------------------- \142\ https://www.cdc.gov/vaccines/programs/iis/2d-vaccine-barcodes/about.html. --------------------------------------------------------------------------- For example, 2D barcode technology has been pilot tested to show that barcoding on vaccines can capture vaccine data elements completely and accurately.\143\ The National Childhood Vaccine Injury Act \144\ (NCVIA) requires documentation of vaccine product identification and vaccine lot number. These data are usually handwritten or manually typed into an EHR/IIS and can be missing or incorrect. A workgroup from the American Academy of Pediatrics (AAP) approached the FDA in 2010 to request that the regulation requiring linear barcodes be amended to allow for the use of 2D barcodes on vaccines. --------------------------------------------------------------------------- \143\ https://www.cdc.gov/vaccines/programs/iis/2d-vaccine-barcodes/about.html. \144\ Public Law 99-660. --------------------------------------------------------------------------- Since 2011, the CDC has been exploring the potential for 2D barcoding to streamline immunization practices. Two vaccine manufacturers, ten CDC ``Section 317'' Immunization grantees, and approximately 220 immunizers among the ten grantees participated in a pilot implementation of 2D barcoded vaccines. Providers administered vaccines with 2D barcodes containing product identifier, lot number, and expiration date. The providers were given barcode scanners that read the 2D barcode and input the data directly into the EHR for each patient. The data were then sent to the IIS. Additionally, we are aware that a working group led by the AAP has developed a ``Guideline for Practitioners'' document to help practices use 2D barcoding with their EHR or IIS and guidance for manufacturers on implementing GS1 DataMatrix Barcodes standard on vaccines.\145\ --------------------------------------------------------------------------- \145\ AAP materials are available at https://www2.aap.org/immunization/pediatricians/barcoding.html. --------------------------------------------------------------------------- Given the progress made to-date demonstrating the feasibility of implementing 2D barcode technology in practice, we solicit comment on whether we should propose a 2017 Edition certification criterion requiring EHR systems to consume 2D barcodes and for what functions (e.g., vaccine administration, medication administration). We also solicit comment on any other data that EHR technology could be required to capture using 2D barcoding information. I. Duplicate Patient Records In September 2013, in response to the 2011 HITPC and HITSC recommendations and stakeholder feedback, ONC formally undertook an initiative to improve patient matching.\146\ Due to our experience with this initiative, we are considering a 2017 Edition certification criterion that would require EHR technology to be capable of generating and providing to end users reports that detail potential duplicate patient records as a potential means to improve patient matching data quality. We anticipate that this certification criterion could also include functionality for end users to correct duplicate records, which typically requires the merging of records and unmerging incorrectly merged records. --------------------------------------------------------------------------- \146\ https://www.healthit.gov/buzz-blog/health-innovation/onc-launches-patient-matching-initiative/. --------------------------------------------------------------------------- We believe a certification criterion including these capabilities, in addition to the patient matching capabilities proposed for inclusion in the 2015 Edition ``transitions of care'' certification criterion, would significantly improve a provider's ability to properly match patients to their health information. While many EHR systems today with built-in matching functionality and processes offer reports that identify potential duplicate records, not all EHR systems offer such a capability. Additionally, some EHR systems have the capability, but do not make the reports accessible to users. As for merging and unmerging, we understand these capabilities vary and are inconsistently applied in EHR technology today. While some EHR technology may enable users to merge and unmerge back to a specific point in time, others do not unmerge and instead delete the entire record and create two new ones. We seek comment on provider demand for/interest in these types of capabilities in addition to any capabilities that should be included or excluded from this potential certification criterion. J. Disaster Preparedness Over the past decade, the U.S. has been challenged by several natural and man-made disasters (e.g., terrorist attacks, Hurricanes Katrina and Sandy, Joplin tornado) which have placed considerable strain on local health care systems and put health system readiness for public health emergencies on the national agenda. One of the basic tenets of preparedness is, to the greatest extent possible, to incorporate into everyday operations those systems, processes, equipment, and strategies that might be employed during a disaster.\147\ Maintaining health IT infrastructure has tangible day to day benefits and during a disaster or other large scale event may reduce overall stress on the health care system which helps makes our health care systems more resilient. In fact, the National Health Security Strategy (NHSS) identifies ``the use of portable, standards- based, interoperable EHRs'' as an essential element of a ``prepared and responsive health system.'' \148\ --------------------------------------------------------------------------- \147\ Abir M, Mostashari F, Atwal P, et al. Electronic health records critical in the aftermath of disasters. Prehosp Disaster Med. 2012;6:620-622. \148\ U.S. Department of Health and Human Services. National health security strategy of the United States of America. Washington, DC: U.S. Department of Health and Human Services; December 2009: https://www.phe.gov/Preparedness/planning/authority/nhss/strategy/Documents/nhss-final.pdf Accessed August 9, 2013. --------------------------------------------------------------------------- For example, EHRs improved health care during a crisis on May 22, 2011 when a tornado struck Joplin, Missouri. As part of the devastation, St. John's Regional Medical Center was heavily damaged and had to be evacuated. All paper and film records were destroyed, but medical personnel had full access to their patients' electronic records. The EHR system significantly aided St. [[Page 10929]] John's in tracking patient medical histories and delivering care based on the full patient records even from their temporary facility.\149\ --------------------------------------------------------------------------- \149\ https://www.healthit.gov/buzz-blog/ehr-case-studies/electronic-health-records-prove-invaluable-crisis/. --------------------------------------------------------------------------- To more fully consider how EHR technology can be used to enhance emergency preparedness and assist in response when emergencies do occur, we seek comment (in collaboration with our colleagues in the Office of the Assistant Secretary for Preparedness and Response (ASPR)) on a number of different concepts that we believe could be expressed as certification criteria in the future. In November 2012, ONC convened the Southeast Regional HIT-HIE Collaboration (SERCH) project on Health Information Exchange in Disaster Preparedness and Response.) \150\ The consortium included representatives from Alabama, Arkansas, Florida, Georgia, Louisiana, and Texas. The consortium's goal was to develop a strategic plan for sharing health information data among the Southeast and Gulf states during and following a declared natural disaster. The consortium members carefully assessed the challenges of accessing medical records and coordinating health care information for patient populations displaced due to a disaster. The SERCH team recognized the importance of using existing EHR and HIE standards and concluded that ``current and future work [regarding electronic health information exchange during disasters] should leverage the standards being developed'' and that ``rather than focus on specifying a minimum data set, allow data set sources to contribute as much of the data within the proposed data set as they are able.'' --------------------------------------------------------------------------- \150\ https://www.healthit.gov/sites/default/files/pdf/SERCH-White-Paper.pdf. --------------------------------------------------------------------------- One of the key issues encountered during disasters (and day-to-day emergency care) is how to bypass the naming of patients who are temporarily unidentified. While this is rarely an issue in other care settings, disasters and emergencies create situations in which care must begin before the identity of the patient can be verified. It is our understanding that most EHR technologies used in emergency care settings have a name bypass function or facilities have developed protocols to be employed in these cases. Unfortunately, stakeholder feedback from the field has indicated that there is little consistency with respect to the patient naming approach used in EHR technology during emergencies/disasters or how rapidly a set of patient records can be generated in a mass casualty situation. This makes reconciliation across various platforms or throughout the episode of care challenging. As a result, information is lost, care is disconnected, patient safety is threatened, and tests and procedures are often duplicated. During facility evacuation it is often necessary to rapidly produce hard copies of patient records for groups of patients (for example all patients in the ``SICU'' or ``on floor 5 west''). This step is needed to ensure the continuity of care for patients en route and at the receiving facility, which may not have access to the patient's complete electronic record. It is our understanding that many EHR technologies today only permit clinical summaries for patients to be printed one at a time, which is too time consuming in situations where seconds count. The nature of emergency and disaster care is that transitions of care and referrals happen at far greater speed and frequency than in other primary or ambulatory settings. The unique needs of tracking a patient through the episode of care, which may involve numerous, unaffiliated care providers (for example, shelters and triage stations, emergency medical services, initial emergency department, air medical transfer, tertiary center emergency department, specialty care, etc.) presents unique challenges. To improve the continuity of care during these rapid transitions, stakeholders have suggested that it would be helpful if a standardize set of core information can be rapidly transferred electronically across different EHR technologies. Numerous third-party patient tracking methods and software packages have emerged as add-ons to EHR technologies to help, but very few are part of the EHR technology and often create parallel tracking systems. Disasters present a unique situation in which the demand for health resources (personnel, equipment, supplies, space, etc.) may temporarily exceed the supply. This situation requires a legal and ethical framework to fairly and equitably allocate these scarce resources to achieve the greatest possible population based outcomes. The IOM has published Crisis Standards of Care: A Systems Framework for Catastrophic Disaster Response,\151\ in which the standards of care are altered based on the availability of health care resources. As such, it seems as if it would be particularly helpful if EHR technology were able to denote care provided during contingency and crisis conditions. --------------------------------------------------------------------------- \151\ IOM. 2012. Crisis Standards of Care: A Systems Framework for Catastrophic Disaster Response. Washington, DC: The National Academies Press. --------------------------------------------------------------------------- Improved public health surveillance has long been a promise of ubiquitous EHR technology. While great strides have been made, little attention has been focused on the potential of electronic heath data to evaluate resilience, preparedness, strain on the health care system, or recovery. Given these issues, we solicit comments on: (1) Whether there could be a standardized naming convention for EHR technology to use for temporarily naming unidentified patients during disaster and emergency events? (2) Whether we should consider adopting a certification criterion that would be available for certification for EHR technology developers to show that their EHR technology can batch print face sheets or patient snapshots in bulk (by floor or unit, or by facility) to support movement/evacuation of large numbers of patients? (3) Whether there are particular capabilities or standards we should consider as part of EHR certification that would better assist providers track and identify patients and victims and share basic clinical information quickly across the full continuum of care during everyday emergencies, disasters, and public health emergencies? (4) Whether EHR technology should be able to denote care provided during disasters or public health emergencies and allow for designation of care provided under situations which demand contingency or crisis standards of care? (5) Whether there are any EHR capabilities and certification criteria that we should consider for certification that could improve/ expedite how EHR technology is used to report standardized and de- identified patient data to public health and emergency management authorities, in a manner that would allow such authorities the ability to measure, track and trend health system resiliency, stress, preparedness, and recovery? K. Certification of Other Types of HIT and for Specific Types of Health Care Settings Section 3001(c)(5) of the PHSA provides the National Coordinator with the authority to establish a voluntary certification program or programs for other types of HIT besides Complete EHRs and EHR Modules. As we noted in the Permanent Certification Program final rule (76 FR 1294), the initial focus of the ONC HIT Certification Program [[Page 10930]] should be on the certification of Complete EHRs and EHR Modules in support of the EHR Incentive Programs. In the 2014 Edition NPRM, we sought public comment on whether we should focus any certification efforts towards the HIT used by health care providers that are ineligible to receive incentive payments under the EHR Incentive Programs and received positive feedback that we discussed in the 2014 Edition Final Rule.\152\ On March 7, 2013, in conjunction with CMS, we published the ``Advancing Interoperability and Health Information Exchange'' Request for Information (RFI) in the Federal Register, which stated that ONC and CMS would continue to collaborate on the EHR Incentive Programs and ONC HIT Certification Program to ensure that the programs support delivery and payment reform.\153\ The RFI also noted that HHS intends to rely on all applicable and appropriate statutory authorities, regulations, policies, and programs to accelerate rapid adoption of health information exchange across the care continuum in support of delivery and payment reform. In response to comments received on the RFI, we issued a ``Principles and Strategy for Accelerating Health Information Exchange'' paper.\154\ As summarized in the paper, commenters made multiple recommendations for the use of certification and the expansion of the ONC HIT Certification Program.\155\ We stated in the paper: ``A critical part of enabling the secure flow of information across the system is advancing the adoption of HIT standards through voluntary certification of HIT and HIE products and services. CMS will consider various ways in which the voluntary certification of HIT and HIE products and services under the ONC HIT Certification Program could be aligned with Medicare and Medicaid payment policy, to the extent feasible and within the scope of applicable law.'' --------------------------------------------------------------------------- \152\ 77 FR 54275. \153\ 78 FR 14793. \154\ https://www.healthit.gov/sites/default/files/acceleratinghieprinciples_strategy.pdf. \155\ For a summary of these recommendations, see page 5 of the ``Principles and Strategy for Accelerating Health Information Exchange (HIE)'' paper. --------------------------------------------------------------------------- 1. Other Types of HIT This proposed rule takes a step towards the expansion of the ONC HIT Certification Program to accommodate other types of HIT. By proposing changes to the ONC HIT Certification Program to recognize the certification of MU and non-MU EHR Modules, EHR technology designed for other settings and purposes could be certified under the ONC HIT Certification Program to the 2015 Edition without having to meet certification criteria designed specifically for MU (see section IV.B for further discussion). This step, however, does not address the full range of HIT that might be certified to the certification criteria the Secretary may adopt in the future because all technologies would still be certified as ``EHR Modules'' even with our proposed changes. Visibility for stakeholders about the certifications issued and attribution for certifications that is more specific and distinct for other technologies that would not generally be considered ``EHR'' functionality, such as functionality provided by a health information exchange, HISP, or laboratory technology, would provide better marketing and purchasing clarity. With additional changes to the ONC HIT Certification Program, we could provide the proper visibility and attribution for these technologies by permitting them to be certified as ``HIT Modules.'' ``HIT Modules'' would be distinct from EHR Modules in that they would represent technologies that stakeholders recognize as distinct from EHR software and services. Certification for ``HIT Modules'' could also have long-term practicality as the ONC HIT Certification Program evolves. We welcome comments on this potential change to the ONC HIT Certification Program as we are considering moving in this direction as part of our 2017 Edition rulemaking. 2. Specific Types of Health Care Settings To begin the processes noted in the ``Principles and Strategy for Accelerating Health Information Exchange (HIE)'' paper, we asked the HIT Policy Committee to begin exploring the expansion of certification under the ONC HIT Certification Program, particularly focusing on EHR certification for the long-term and post-acute care (LTPAC) and behavioral health care settings. We expect the Certification/Adoption Workgroup of the HIT Policy Committee to present final recommendations to the HIT Policy Committee and the HIT Standards Committee in March 2014. We have also received feedback and suggestions from other components of HHS about EHR technology certification for setting- specific and specialty purposes. EHR technology certification could potentially be expanded given stakeholder demand for specific certification criteria targeted to support specific purposes. Below are some examples on which we seek comment as well as any other suggestion the public may have. Children's EHR Format The Children's EHR Format (``Format'') \156\ was authorized by the 2009 Children's Health Insurance Program Reauthorization Act (CHIPRA) \157\ and developed by the Agency for Healthcare Research and Quality (AHRQ) in close collaboration with CMS. The Format was developed to bridge the gap between the functionality present in most EHRs currently available and the functionality that would more optimally support the care of children. Specifically, the Format provides information to EHR system developers and others about critical functionality, data elements, and other requirements that need to be present in an EHR system to address health care needs specific to the care of children, especially those enrolled in Medicaid or the Children's Health Insurance Program (CHIP). Providers who care for children (e.g., pediatricians, family physicians, and specialists) have criticized the absence of these ``pediatric'' functions when they are not available in EHR technology. The availability of certification of EHR technology to the Format (or, more likely, key aspects of the Format) may stimulate EHR technology developers to recognize and incorporate pediatric functionality into EHR technology as well as further the goals of CHIPRA and the agencies responsible for implementing it. --------------------------------------------------------------------------- \156\ https://healthit.ahrq.gov/health-it-tools-and-resources/childrens-electronic-health-record-ehr-format. \157\ Public Law 111-3, section 401. --------------------------------------------------------------------------- Practice Transformation To fully support comprehensive primary and specialty care toward the aim of better care and better health outcomes at lower cost EHR technology may need to include more advanced and specific capabilities that are not uniformly or widely available today. For example, the ability of EHR technology to enable users to construct a customized risk stratification algorithm within EHR technology through selection of structured data elements (e.g., diagnosis, labs, medications, symptoms, risk factors, frequency of visits, hospitalization or ED visit). Alternatively, it could include the ability to modify or adapt standardized risk stratification algorithms that identify individual patients risk levels and clearly demarcate this risk level within a patient's record. Further, it has been suggested that EHR technology [[Page 10931]] should enable a user to modify risk stratification algorithms by adding more elements or applying a global risk assessment based on clinical judgment. In addition to risk stratification, EHR technology may need to be able to track patients for care management services based on risk status with the ability to create customizable real-time lists of patients in different tiers of risk. As a second example in this category, we could adopt certification criteria for EHR technology that focuses on advanced care coordination features to integrate a patient's care plan into visit screens and other screens such that the patient view displays an updated and modifiable care plan documentation field. Further, a certification criterion could focus on ability to enable users to track tests and referrals that are in process and automatically trigger a reminder to view the results or follow up if results are not entered or received into the EHR by an expected date. 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 We propose modifications to remove the 2011 Edition EHR Certification Criteria and related standards, terms, and requirements from the Code of Federal Regulations. Specifically, we propose to remove 45 CFR Sec. Sec. 170.302, 170.304, and 170.306. We also propose to remove the standards and implementation specifications found in 45 CFR Sec. Sec. 170.205, 170.207, 170.210, and 170.299 that are only referenced in the 2011 Edition EHR certification criteria. This means that if a standard is also referenced in the 2014 or 2015 Edition, it would remain in the regulation text. In regard to terms, we propose to retire the definitions found in 45 CFR Sec. 170.102 related to the 2011 Edition, including ``2011 Edition EHR certification criteria'' and ``Complete EHR, 2011 Edition.'' In regard to requirements, we propose to remove Sec. 170.550(e) and any other requirement in subpart E, Sec. Sec. 170.500 through 170.599 that is specific to the 2011 Edition and does not have general applicability to other editions of certification criteria. EHR technology certified to 2011 Edition is outmoded. It no longer meets the CEHRT definition and the 2011 Edition no longer represents an acceptable level of interoperability. Further, as referenced by the HHS Office of Inspector General and CMS in the recent rulemakings completed by those agencies around donations of EHR items and services, we expect to retire old/no longer applicable certification criteria editions.\158\ This approach will streamline our requirements and ensure there is no regulatory confusion involving administration of ONC's rules and these other agencies' rules. Thus, consistent with EO 13563 instruction to ``determine whether any [agency] regulations should be modified, streamlined, expanded, or repealed so as to make the agency's regulatory program more effective or less burdensome in achieving the regulatory objectives,'' we are proposing to remove the 2011 Edition and related standards, terms, and requirements from the Code of Federal Regulations. --------------------------------------------------------------------------- \158\ CMS final rule ``Medicare Program; Physicians' Referrals to Health Care Entities With Which They Have Financial Relationships: Exception for Certain Electronic Health Records Arrangements'' (78 FR 78751). --------------------------------------------------------------------------- B. Temporary Certification Program The temporary certification program sunset on October 4, 2012, and is no longer in existence (77 FR 54268). Accordingly, we propose to remove from the Code of Federal Regulations the associated regulations, consisting of subpart D (Sec. Sec. 170.400 through 170.499). VII. Response to Comments Because of the large number of public comments normally received in response to Federal Register documents, we are not able to acknowledge or respond to them individually. We will consider all comments we receive by the date and time specified in the DATES section of this preamble, and, when we proceed with a subsequent document, we will respond to the comments in the preamble of that document. As noted in section I.B.2, we do not plan to respond in that subsequent document to comments we receive concerning potential proposals for future rulemaking and the subject matter discussed in section V. ``Other Topics for Consideration for the 2017 Edition Certification Criteria Rulemaking.'' VIII. Collection of Information Requirements This proposed rule contains no new collections of information under the Paperwork Reduction Act nor does it propose to revise current collections of information approved by OMB. IX. Regulatory Impact Statement A. Statement of Need This proposed rule is being published to adopt a voluntary edition of certification criteria (2015 Edition). Certification criteria and associated standards and implementation specifications will be used to test and certify HIT in order to make it possible for EPs, EHs, and CAHs to adopt and implement HIT that can be used to meet the CEHRT definition. EPs, EHs, and CAHs who seek to qualify for incentive payments under the EHR Incentive Programs are required by statute to use CEHRT. The 2015 Edition provides an efficient and effective response to stakeholder feedback, incorporates ``bug fixes'' for errors, omissions and ambiguities found in our 2014 Edition EHR certification criteria, which will make our rules clearer and easier to implement, and includes newer standards and implementation specifications that reflect our commitment to promoting innovation and enhancing interoperability. B. Overall Impact We have examined the impact of this proposed rule as required by Executive Order 12866 on Regulatory Planning and Review (September 30, 1993), Executive Order 13563 on Improving Regulation and Regulatory Review (February 2, 2011), the Regulatory Flexibility Act (5 U.S.C. 601 et seq.), section 202 of the Unfunded Mandates Reform Act of 1995 (2 U.S.C. 1532), and Executive Order 13132 on Federalism (August 4, 1999). 1. Executive Orders 12866 and 13563--Regulatory Planning and Review Analysis Executive Orders 12866 and 13563 direct agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). A regulatory impact analysis (RIA) must be prepared for major rules with economically significant effects ($100 million or more in any 1 year). We have determined that this proposed rule is not an economically significant rule. Related costs to prepare EHR technology to be tested and certified are estimated to be less than $100 million per year. Nevertheless, because of the public interest in this proposed rule, we have prepared an RIA that to the best of our ability presents the costs and benefits of the proposed rule. a. Costs This rule proposes the adoption of standards, implementation specifications, and certification criteria [[Page 10932]] that would establish the capabilities that EHR technology would need to demonstrate to be certified to the 2015 Edition. Our analysis focuses on the direct effects of the provisions of this proposed rule--the costs incurred by EHR technology developers to develop and prepare EHR technology to be tested and certified in accordance with the certification criteria (and the standards and implementation specifications they include) adopted by the Secretary. That is, we focus on the technological development and preparation costs necessary for EHR technology already certified to the 2014 Edition EHR certification criteria to upgrade to the proposed 2015 Edition EHR certification criteria and for developing a new EHR Module to meet the 2015 Edition EHR certification criteria. The costs for testing and certification of EHR technologies to the 2015 Edition were captured in the regulatory impact analysis of the Permanent Certification Program final rule as we discuss in more detail below (IX.B.1.a.iii ``Testing and Certification Costs for the 2015 Edition''). The costs that EPs, EHs, and CAHs will incur in adopting and implementing EHR technology certified to the 2015 Edition are not within the scope of this final rule. i. Development and Preparation Costs for the 2015 Edition The development costs we estimate are categorized based on the type of certification criteria we have identified for the purposes of gap certification (i.e., new, revised, and unchanged). For the 2014 Edition Final Rule, we used the total number of unique Complete EHRs and EHR Modules that had been certified to the 2011 Edition EHR certification criteria as identified in the CHPL for our regulatory impact analysis. At this point in time, we do not believe the CHPL is fully populated with all of the EHR technologies that will be certified to 2014 Edition EHR certification criteria. Accordingly, we are using the total number of unique \159\ 2011 Edition Complete EHRs and EHR Modules that were used for MU Stage 1 attestation as reported at the end of FY 2013.\160\ We expect, however, that upon issuance of the 2015 Edition Final Rule that the CHPL would provide a more complete picture of the number of EHR technologies certified to the 2014 Edition for use in our regulatory impact analysis and that we would use those numbers instead of the 2011 Edition numbers we include here for our current estimates. --------------------------------------------------------------------------- \159\ We attempted to discern how many Complete EHRs and EHR Modules were used that would not constitute a newer version of the same EHR technology. \160\ For 2015 Edition EHR certification criteria that do not have equivalent 2011 Edition EHR certification criteria, we used the unique number for the equivalent 2014 Edition EHR certification criteria as identified and used for the 2014 Edition Final Rule regulatory impact analysis. --------------------------------------------------------------------------- Using the unique number of 2011 Edition EHR technologies used for MU Stage 1 attestation we have established a range of EHR technologies that we believe will be developed and prepared to meet each of the proposed 2015 Edition EHR certification criteria based on the following four considerations: Before a subsequent 2015 Edition final rule is issued, many, if not most, EPs, EHs, and CAHs will have EHR technology certified to the 2014 Edition that can be used to meet the CEHRT definition for FY/CY 2014 and FY/CY 2015 because they must use EHR technology that has been certified to the 2014 Edition to meet the CEHRT definition beginning with FY/CY 2014. Unlike the 2014 Edition, the 2015 Edition is a voluntary edition of EHR certification criteria to which EPs, EHs, and CAHs are not required to possess EHR technology certified in order to meet the CEHRT definition on a certain date. The CEHRT definition only requires EPs, EHs, and CAHs to possess the CEHRT they need to demonstrate MU for the stage they seek to accomplish, which could conceivably directly affect the number of EHR technologies developed to certain certification criteria that support MU menu objectives and measures. Some EHR technology will be developed and prepared to meet the 2015 Edition that is not intended to be used by providers solely for MU purposes. Some EHR technology developers may wait to see what the 2017 Edition includes in a 2017 Edition proposed rule, potentially certify EHR technology to the 2015 Edition, and then pursue gap certification to the final 2017 Edition. Based on these assumptions, we believe that between 20% and 40% of unique EHR technologies used for MU Stage 1 will be developed and prepared for certification to the 2015 Edition. This range takes into account potential new entrants to the market as well as those EHR technologies used for MU Stage 1 attestation that may no longer be brought forth for certification because of such factors as corporate re-organizations (e.g., mergers and acquisitions) as well as the loss of market share for some EHR technologies.\161\ This range also takes into account any potential non-MU-focused EHR technologies that will be developed and prepared to meet the 2015 Edition, but not designed for MU purposes. For unchanged certification criteria, we have only calculated development and preparation costs for 25-50 new EHR technologies. There would not be any costs associated with upgrading EHR technologies previously certified to the 2014 Edition and we do not expect any more than 25-50 new technologies to be certified to the unchanged 2015 Edition EHR certification criteria. --------------------------------------------------------------------------- \161\ This may be happening with EHR technologies being developed and prepared for certification to the 2014 Edition based on the number of certified EHR technologies listed on the CHPL as of October 2013. --------------------------------------------------------------------------- We are not aware of an available independent study (e.g., a study capturing the efforts and costs to develop and prepare Complete EHRs and EHR Modules to meet the requirements of the 2014 Edition EHR certification criteria) that we could rely upon as a basis for estimating the efforts and costs required to develop and prepare EHR technology to meet the 2015 Edition EHR certification criteria. Therefore, we have relied upon the approach we used for estimating the costs associated with developing and preparing EHR technology to meet the 2014 Edition EHR certification criteria in the 2014 Edition NPRM and 2014 Edition Final Rule (i.e., we have used our own research to estimate the effort required to develop and prepare EHR technology to meet the requirements of the 2015 Edition.).\162\ We have identified three levels of effort that we believe can be associated with the development and preparation of EHR technology to meet the requirements of the 2015 Edition. These levels of effort are the average range of hours we would expect to be necessary to develop EHR technology to meet the requirements of the 2015 Edition EHR certification criteria. This means that a few EHR technology developers' costs may be less than this range and a few may exceed the range. Level 1 is for certification criteria that we believe will require the least amount of effort to develop and prepare EHR technology for testing and certification to the criteria, with a range of 40-100 hours. Level 2 is for certification criteria that we believe will require a moderate amount of effort to develop and prepare EHR [[Page 10933]] technology for testing and certification to the criteria, with a range of 100-300 hours. Level 3 is for certification criteria that we believe will require the most amount of effort to develop and prepare EHR technology for testing and certification to the criteria, with a range of 300-400 hours. --------------------------------------------------------------------------- \162\ We have also estimated the costs for the proposed revisions to the 2014 Edition ``transmission to public health agencies--syndromic surveillance'' certification criterion (Sec. 170.314(f)(3)). --------------------------------------------------------------------------- We have based the effort levels on the hours necessary for a software developer to develop and prepare the EHR technology for testing and certification. The U.S. Department of Labor, Bureau of Labor Statistics estimates that the mean hourly wage for a software developer is $44.85.\163\ We have also calculated the costs of an employee's benefits by assuming that an employer expends thirty-six percent (36%) of an employee's hourly wage on benefits for the employee. We have concluded that a 36% expenditure on benefits is an appropriate estimate because it is the routine percentage used by HHS for contract cost estimates. We have rounded up the average software developer's wage with benefits to $61 per hour. --------------------------------------------------------------------------- \163\ https://www.bls.gov/oes/current/oes151132.htm. --------------------------------------------------------------------------- To calculate our low cost estimates for each certification criterion in the tables below, we have multiplied the low number of the estimated range of EHR technologies expected to be developed and prepared by the low number of estimated hours for a software developer to develop and prepare the EHR technologies for testing and certification. To calculate our high cost estimates for each certification criterion in the tables below, we have multiplied the high number of the estimated range of EHR technologies expected to be developed and prepared to the criterion by the high number of estimated hours for a software developer to develop and prepare the EHR technologies for testing and certification. For the following tables (Tables 5 through Table 11), dollar amounts are expressed in 2014 dollars. New Certification Criteria Table 5--2015 Edition New EHR Certification Criteria: Level 1 Effort ---------------------------------------------------------------------------------------------------------------- Estimated number of EHR Average Average technologies development development Regulation section Title of regulation to be and and paragraph developed with preparation preparation this costs--low costs--high capability ($M) ($M) ---------------------------------------------------------------------------------------------------------------- 170.315(h)(1)...................... Transmit--Applicability 171-342 .42 2.09 Statement for Secure Health Transport. 170.315(h)(2)...................... Transmit--Applicability 137-274 .33 1.67 Statement for Secure Health Transport & XDR/XDM for Direct Messaging. 170.315(h)(3)...................... Transmit--SOAP Transport 137-274 .33 1.67 and Security Specification & XDR/XDM for Direct Messaging. ---------------------------------------------------------------------------- Total.......................... ........................... .............. 1.08 5.43 ---------------------------------------------------------------------------------------------------------------- Table 6--2015 Edition New EHR Certification Criteria: Level 2 Effort ---------------------------------------------------------------------------------------------------------------- Estimated number of EHR Average Average technologies development development Regulation section Title of regulation to be and and paragraph developed with preparation preparation this costs--low costs--high capability ($M) ($M) ---------------------------------------------------------------------------------------------------------------- 170.315(a)(20)..................... Implantable device list.... 151-303 .93 5.54 170.315(h)(4)...................... Transmit--Applicability 32-65 .20 1.19 Statement for Secure Health Transport & Delivery Notification in Direct. ---------------------------------------------------------------------------- Total.......................... ........................... .............. 1.13 6.73 ---------------------------------------------------------------------------------------------------------------- Table 7--2015 Edition New EHR Certification Criteria: Level 3 Effort ---------------------------------------------------------------------------------------------------------------- Estimated number of EHR Average Average technologies development development Regulation section Title of regulation to be and and paragraph developed with preparation preparation this costs--low costs--high capability ($M) ($M) ---------------------------------------------------------------------------------------------------------------- 170.315(c)(4)...................... Clinical quality measures-- 152-303 2.78 7.39 patient population filtering. 170.314(g)(5)...................... Non-percentage-based 151-303 2.76 7.39 measures reporting. ---------------------------------------------------------------------------- Total.......................... ........................... .............. 5.54 14.78 ---------------------------------------------------------------------------------------------------------------- Revised Certification Criteria [[Page 10934]] Table 8--2015 Edition Revised EHR Certification Criteria: Level 1 Effort ---------------------------------------------------------------------------------------------------------------- Estimated number of EHR Average Average technologies development development Regulation section Title of regulation to be and and paragraph developed with preparation preparation this costs--low costs--high capability ($M) ($M) ---------------------------------------------------------------------------------------------------------------- 170.315(a)(5)...................... Demographics............... 202-403 .49 2.46 170.315(a)(11)..................... Electronic notes........... 93-187 .23 1.14 170.315(a)(17)..................... Patient-specific education 153-306 .37 1.87 resources. 170.315(b)(2)...................... Clinical information 158-317 .39 1.93 reconciliation and incorporation. 170.315(b)(4)...................... Incorporate laboratory 157-314 .38 1.92 tests and values/results. 170.315(b)(5)...................... Transmission of electronic 32-65 .08 .40 laboratory tests and values/results to ambulatory providers (inpatient). 170.315(b)(6)...................... Data portability........... 149-298 .36 1.82 170.315(d)(2)...................... Auditable events and tamper- 196-392 .48 2.39 resistance. 170.315(e)(2)...................... Clinical summary 132-264 .32 1.61 (ambulatory). 170.315(f)(2)...................... Transmission to 145-289 .35 1.76 immunization registries. 170.315(f)(4)...................... Transmission of reportable 26-51 .06 .31 laboratory tests and values/results (inpatient setting). 170.315(f)(6)...................... Transmission to cancer 26-51 .06 .31 registries. ---------------------------------------------------------------------------- Total.......................... ........................... .............. 3.57 17.92 ---------------------------------------------------------------------------------------------------------------- Table 9--2014 Edition Revised EHR Certification Criteria: Level 2 Effort ---------------------------------------------------------------------------------------------------------------- Estimated number of EHR Average Average technologies development development Regulation section Title of regulation to be and and paragraph developed with preparation preparation this costs--low costs--high capability ($M) ($M) ---------------------------------------------------------------------------------------------------------------- 170.314(f)(3)...................... Transmission to public 141-282 .86 5.16 health agencies--syndromic surveillance. ---------------------------------------------------------------------------- Total.......................... ........................... .............. .86 5.16 ---------------------------------------------------------------------------------------------------------------- Table 10--2015 Edition Revised EHR Certification Criteria: Level 2 Effort ---------------------------------------------------------------------------------------------------------------- Estimated number of EHR Average Average technologies development development Regulation section Title of regulation to be and and paragraph developed with preparation preparation this costs--low costs--high capability ($M) ($M) ---------------------------------------------------------------------------------------------------------------- 170.315(a)(2)...................... CPOE--laboratory........... 189-378 1.15 6.92 170.315(a)(10)..................... Clinical decision support.. 190-380 1.16 6.95 170.315(a)(15)..................... Family health history...... 93-187 .57 3.42 170.315(b)(1)...................... Transitions of care........ 171-342 1.04 6.26 170.315(e)(1)...................... View, download, and 126-252 .77 4.61 transmit to third party. 170.315(f)(3)...................... Transmission to public 141-282 .86 5.16 health agencies--syndromic surveillance. ---------------------------------------------------------------------------- Total.......................... ........................... .............. 5.55 33.32 ---------------------------------------------------------------------------------------------------------------- Unchanged Certification Criteria Table 11--2015 Edition Unchanged EHR Certification Criteria: Level 2 Effort ---------------------------------------------------------------------------------------------------------------- Estimated number of EHR Average Average technologies development development Regulation section Title of regulation to be and and paragraph developed with preparation preparation this costs--low costs--high capability ($M) ($M) ---------------------------------------------------------------------------------------------------------------- 170.315(a)(1)...................... CPOE--medications.......... 25-50 .06 .31 170.315(a)(3)...................... CPOE--radiology/imaging.... 25-50 .06 .31 170.315(a)(4)...................... Drug-drug, drug-allergy 25-50 .06 .31 interaction checks. 170.315(a)(6)...................... Vital signs, body mass 25-50 .06 .31 index, and growth charts. [[Page 10935]] 170.315(a)(7)...................... Problem list............... 25-50 .06 .31 170.315(a)(8)...................... Medication list............ 25-50 .06 .31 170.315(a)(9)...................... Medication allergy list.... 25-50 .06 .31 170.315(a)(12)..................... Drug formulary check....... 25-50 .06 .31 170.315(a)(13)..................... Smoking status............. 25-50 .06 .31 170.315(a)(14)..................... Image results.............. 25-50 .06 .31 170.315(a)(16)..................... Patient list creation...... 25-50 .06 .31 170.315(a)(18)..................... Electronic medication 25-50 .06 .31 administration record. 170.315(a)(19)..................... Advance directives......... 25-50 .06 .31 170.315(b)(3)...................... Electronic prescribing..... 25-50 .06 .31 170.315(c)(1)...................... Clinical quality measures-- 25-50 .06 .31 capture and export. 170.315(c)(2)...................... Clinical quality measures-- 25-50 .06 .31 import and calculate. 170.315(c)(3)...................... Clinical quality measures-- 25-50 .06 .31 electronic submission. 170.314(d)(1)...................... Authentication, access 25-50 .06 .31 control, and authorization. 170.315(d)(3)...................... Audit report............... 25-50 .06 .31 170.315(d)(4)...................... Amendments................. 25-50 .06 .31 170.315(d)(5)...................... Automatic log-off.......... 25-50 .06 .31 170.315(d)(6)...................... Emergency access........... 25-50 .06 .31 170.315(d)(7)...................... End-user device encryption. 25-50 .06 .31 170.315(d)(8)...................... Integrity.................. 25-50 .06 .31 170.315(d)(9)...................... Accounting of disclosures.. 25-50 .06 .31 170.315(e)(3)...................... Secure messaging........... 25-50 .06 .31 170.315(f)(1)...................... Immunization information... 25-50 .06 .31 170.315(f)(5)...................... Cancer case information.... 25-50 .06 .31 170.315(g)(1)...................... Automated numerator 25-50 .06 .31 recording. 170.315(g)(2)...................... Automated measure 25-50 .06 .31 calculation. 170.315(g)(3)...................... Safety-enhanced design..... 25-50 .06 .31 170.315(g)(4)...................... Quality systems management. 25-50 .06 .31 ---------------------------------------------------------------------------- Total.......................... ........................... .............. 1.92 9.92 ---------------------------------------------------------------------------------------------------------------- ii. Overall Development and Preparation Costs Over a Two-Year Period In total, we estimate the overall costs to develop and prepare EHR technology for certification over a two-year period to be $19.65 million to $93.26 million, with a cost mid-point of approximately $56.46 million. Evenly distributed over calendar years 2014 and 2015, the cost range would be $9.82 million to $46.63 per year with an annual cost mid-point of approximately $28.23. We project these costs to be evenly distributed over calendar years 2014 and 2015 for the following reasons: We expect a subsequent 2015 Edition final rule to be published in the summer of 2014. We expect a 2017 Edition proposed rule to be published in the fall 2014 and a 2017 Edition final rule to be published approximately by summer 2015. We assume a number of developers will develop and prepare EHR technology for testing and certification in the last half of 2014 so that the EHR technology can be implemented and used to meet the current CEHRT definition. We expect development and preparation in 2015 to continue at a similar pace until a 2017 Edition final rule is published and testing and certification to the 2017 Edition certification criteria can begin. We expect that EHR technology developers will shift development and preparation of their EHR technology to meeting the 2017 Edition because it is expected to become the basis for meeting the CEHRT definition in future years. While we could foresee EHR technology developers possibly shifting to development and preparation of their EHR technology to meet the 2017 Edition as soon as the 2017 Edition proposed rule is issued (fall 2014), we could also foresee HIT developers continuing development and preparation of their HIT to meet the 2015 Edition and then pursuing gap certification to the 2017 Edition. Table 12 below represents the costs attributable to this proposed rule distributed as follows: 50% for 2014 and 50% for 2015. The dollar amounts expressed in Table 12 are expressed in 2014 dollars. Table 12--Distributed Total Preparation Costs for EHR Technology Developers [(Two-year period)--totals rounded] ---------------------------------------------------------------------------------------------------------------- Total high Total average Year Ratio Total low cost cost estimate cost estimate (percent) estimate ($M) ($M) ($M) ---------------------------------------------------------------------------------------------------------------- 2014............................................ 50 9.82 46.63 28.23 2015............................................ 50 9.82 46.63 28.23 --------------------------------------------------------------- [[Page 10936]] 2-Year Totals............................... .............. 19.65 93.26 56.46 ---------------------------------------------------------------------------------------------------------------- iii. Testing and Certification Costs for the 2015 Edition In the regulatory impact analysis of the Permanent Certification Program final rule, we estimated the costs for testing and certification of EHR technologies that would be used for providers to attempt to achieve MU Stages 1-3.\164\ These costs were based on a two- year rulemaking cycle for the CEHRT definition and each MU Stage. We believe the costs we attributed to testing and certification of EHR technologies in support of MU Stage 2 in the Permanent Certification Program final rule would encompass the actual testing and certification of EHR technologies to both the 2014 and 2015 Editions. This assessment is based on the number of EHR technologies currently certified to the 2014 Edition and our projections in this proposed rule for the number of EHR technologies that would likely be tested and certified to the 2015 Edition EHR certification criteria. Further, we note that the estimated costs in the Permanent Certification Program final rule included costs for surveillance of EHR technologies and also estimated the costs for testing and certification above what we understand are the cost ranges charged by ONC-ACBs today. We welcome comments on our determination and our cost estimates. --------------------------------------------------------------------------- \164\ 76 FR 1318. --------------------------------------------------------------------------- b. Benefits We believe that there will be several significant benefits that may arise from this proposed rule for 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 ``content'' and ``transport'' capabilities in 2015 Edition transitions of care certification criterion (compared to how the 2014 Edition version is structured) is aimed at significantly improving the market availability of electronic health information exchange services. And 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 with our certification criteria and certification program. This advanced visibility can better assist EHR technology developers plan for the future. 2. Regulatory Flexibility Act (RFA) The RFA requires agencies to analyze options for regulatory relief of small businesses if a rule has a significant impact on a substantial number of small entities. The Small Business Administration (SBA) establishes the size of small businesses for federal government programs based on average annual receipts or the average employment of a firm. While EHR technology developers that pursue certification under the ONC HIT Certification Program represent a small segment of the overall information technology industry, we believe that the entities impacted by this proposed rule most likely fall under the North American Industry Classification System (NAICS) code 541511 ``Custom Computer Programming Services'' specified at 13 CFR 121.201 where the SBA publishes ``Small Business Size Standards by NAICS Industry.'' The SBA size standard associated with this NAICS code is set at $25 million in annual receipts \165\ which ``indicates the maximum allowed for a concern and its affiliates to be considered small entities.'' --------------------------------------------------------------------------- \165\ The SBA references that annual receipts means ``total income'' (or in the case of a sole proprietorship, ``gross income'') plus ``cost of goods sold'' as these terms are defined and reported on Internal Revenue Service tax return forms. https://www.sba.gov/sites/default/files/files/Size_Standards_Table.pdf. --------------------------------------------------------------------------- Based on our analysis, we believe that there is enough data generally available to establish that between 75% and 90% of entities that are categorized under the NAICS code 541511 are under the SBA size standard, but note that the available data does not show how many of these entities will develop a EHR product that will be certified to the 2015 Edition certification criteria under the ONC HIT Certification Program. We also note that with the exception of aggregate business information available through the U.S. Census Bureau and the SBA related to NAICS code 541511, it appears that many EHR technology developers that pursue certification under the ONC HIT Certification Program are privately held or owned and do not regularly, if at all, make their specific annual receipts publicly available. As a result, it is difficult to locate empirical data related to many of these EHR technology developers to correlate to the SBA size standard. However, although not correlated to the size standard for NAICS code 541511, we do have information indicating that over 60% of EHR technology developers that have had Complete EHRs and/or EHR Modules certified to the 2011 Edition EHR certification criteria have less than 51 employees.\166\ --------------------------------------------------------------------------- \166\ We hope to update this information in a subsequent final rule based on data obtained regarding certification to the 2014 Edition. --------------------------------------------------------------------------- We estimate that this proposed rule would have effects on EHR technology developers that are likely to pursue certification under the ONC HIT Certification Program, some of which may be small entities. However, we believe that we have proposed the minimum amount of requirements necessary to accomplish our policy goals, including a reduction in regulatory burden and additional flexibility for the regulated community, and that no additional appropriate regulatory alternatives could be developed to lessen the compliance burden associated with this proposed rule. We note that this proposed rule does not impose the costs cited in the regulatory impact analysis as compliance costs, but rather as [[Page 10937]] investments which these EHR technology developers voluntarily take on and expect to recover with an appropriate rate of return. Accordingly, we do not believe that the proposed rule will create a significant impact on a substantial number of small entities, but request comment on whether there are small entities that we have not identified that may be affected in a significant way by this proposed rule. Additionally, the Secretary certifies that this proposed rule will not have a significant impact on a substantial number of small entities. 3. Executive Order 13132--Federalism Executive Order 13132 establishes certain requirements that an agency must meet when it promulgates a proposed rule (and subsequent final rule) that imposes substantial direct requirement costs on state and local governments, preempts state law, or otherwise has federalism implications. Nothing in this proposed rule imposes substantial direct compliance costs on state and local governments, preempts state law or otherwise has federalism implications. We are not aware of any State laws or regulations that are contradicted or impeded by any of the standards, implementation specifications, or certification criteria that we propose for adoption. 4. Unfunded Mandates Reform Act of 1995 Section 202 of the Unfunded Mandates Reform Act of 1995 requires that agencies assess anticipated costs and benefits before issuing any rule whose mandates require spending in any one year of $100 million in 1995 dollars, updated annually for inflation. The current inflation- adjusted statutory threshold is approximately $141 million. This proposed rule will not impose an unfunded mandate on State, local, and tribal governments or on the private sector that will reach the threshold level. C. Request for Comments on 2017 Impact Analysis Methods In response to ONC's 2011 Edition and 2014 Edition rulemakings some stakeholders have suggested that we underestimate the burden associated with developing EHR technology to meet the certification criteria. Yet those stakeholders have not provided data or alternative(s) to the methods that we have used in our rules to prepare the best estimate we can. In our 2014 Edition Final Rule and in this proposed rule, we use a three level approach with hour ranges and multiply those ranges by the number of EHR technologies we expect to be developed to be tested and certified to those criteria. This proposed rule and the 2014 Edition Final Rule's impact analysis represented a significant improvement on our 2011 Edition's impact analysis due to the fact that we now have data on EHR technology certified to the criteria we had adopted. That being said, we believe we can do a better job estimating our certification criteria impacts so long as commenters, especially EHR technology developers, can provide company-specific responses with estimates or ranges. To facilitate more streamlined industry feedback, and in turn more accurate estimates, we are considering using the following template in our 2017 Edition rulemaking that would be part of each certification criterion's preamble discussion. We would pre- populate this template in the 2017 Edition proposed rule with our burden/compliance estimates and enable commenters to compare our estimates to their own. The proposed estimates would also reflect whether the certification criterion's capabilities had previously been adopted. We believe that this level of feedback could then be used to more accurately reflect our regulation's potential impacts. We propose to use a template that splits out specific actions/specific technical capabilities as follows. We also expect have a ``level of effort'' multiplier/coefficient in the third column to account for instances where we would assume that EHR technology developers have already invested time and resources toward implementing a regulatory requirement. This multiplier would range from zero to one (or 0% to 100%). For instance, with respect to a certification criterion that remains the same between editions, we may put a zero since our rule would not require any additional effort from the EHR technology developer to meet the criterion. Similarly, for certification criteria that only have a specific capability revised (e.g., the proposed 2015 Edition ``demographics'' certification criterion), we could put zeros for most rows and .25 for the proposed updated language standard to account for the one change to an otherwise largely unmodified certification criterion. ------------------------------------------------------------------------ First-time development Multiplier for Certification criterion effort for subsequent regulatory development level of compliance effort ------------------------------------------------------------------------ Requirements/Design X Hours.......... (0 to 1). Specification. Capability 1 Total............. XX Hours......... (0 to 1). Sub-Capability 1-1............. X Hours.......... (0 to 1). Sub-Capability 1-2............. X Hours.......... (0 to 1). Capability 2 Total............. XX Hours......... (0 to 1). Capability 2-1................. X Hours.......... (0 to 1). Capability 2-2................. X Hours.......... (0 to 1). ------------------------------------------------------------------------ We also encourage stakeholders to review the HIMSS EHRA's development estimate presentation, delivered to the Meaningful Use Workgroup of the HITPC on September 24, 2013 and available here: https://www.healthit.gov/facas/calendar/2013/09/24/policy-meaningful-use-wg. The EHRA's model can serves as another point of input for commenters to consider in suggesting alternative methods for our impact analysis. Finally, we seek comment on whether this modified approach would be beneficial and which methodology stakeholders believe we should consider. We also ask stakeholders to comment on their ability and willingness to complete company level estimates in conjunction with the general comments in response to the NPRM. OMB reviewed this proposed rule. List of Subjects in 45 CFR Part 170 Computer technology, Electronic health record, Electronic information system, Electronic transactions, Health, Health care, Health information technology, Health insurance, Health records, Hospitals, Incorporation by reference, Laboratories, Medicaid, Medicare, Privacy, Reporting and [[Page 10938]] recordkeeping requirements, Public health, Security. For the reasons set forth in the preamble, 45 CFR subtitle A, subchapter D, part 170, is proposed to be amended as follows: PART 170--HEALTH INFORMATION TECHNOLOGY STANDARDS, IMPLEMENTATION SPECIFICATIONS, AND CERTIFICATION CRITERIA AND CERTIFICATION PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY 0 1. The authority citation for part 170 continues to read as follows: Authority: 42 U.S.C. 300jj-11; 42 U.S.C. 300jj-14; 5 U.S.C. 552. 0 2. In Sec. 170.102: 0 a. Remove the ``2011 Edition EHR certification criteria'' and ``Complete EHR, 2011 Edition'' definitions; 0 b. Add in alphanumeric order the definitions for ``2015 Edition EHR certification criteria,'' ``Device Identifier,'' ``Implantable Device,'' ``Production Identifier,'' and ``Unique Device Identifier;'' and 0 c. Revise the definitions for ``Base EHR,'' paragraph (2) of ``Certified EHR Technology,'' ``EHR Module'', and paragraph (6) of the ``Common MU Data Set'' definition to read as follows: Sec. 170.102 Definitions. * * * * * 2015 Edition EHR certification criteria means the certification criteria at Sec. 170.315. Base EHR means an electronic record of health-related information on an individual that: (1) Includes patient demographic and clinical health information, such as medical history and problem lists; (2) Has the capacity: (i) To provide clinical decision support; (ii) To support physician order entry; (iii) To capture and query information relevant to health care quality; (iv) To exchange electronic health information with, and integrate such information from other sources; (v) To protect the confidentiality, integrity, and availability of health information stored and exchanged; and (3) Has been certified to the certification criteria adopted by the Secretary at: (i) Section 170.314(a)(1); or Sec. 170.315(a)(1), (2), or (3); (ii) Section 170.314(a)(3) or Sec. 170.315(a)(5); (iii) Section 170.314(a)(5) or Sec. 170.315(a)(7); (iv) Section 170.314(a)(6) or Sec. 170.315(a)(8); (v) Section 170.314(a)(7) or Sec. 170.315(a)(9); (vi) Section 170.314(a)(8) or Sec. 170.315(a)(10); (vii) Both Sec. 170.314(b)(1) and (2); or, both Sec. 170.315(b)(1) and Sec. 170.315(h)(1); or Sec. 170.314(b)(1) and (2) combined with either Sec. 170.315(b)(1) or Sec. 170.315(h)(1), or both Sec. 170.315(b)(1) and Sec. 170.315(h)(1); (viii) Section 170.314(b)(7) or Sec. 170.315(b)(6); (ix) Section 170.314(c)(1) or Sec. 170.315(c)(1); (x) Section 170.314(c)(2) or Sec. 170.315(c)(2); (xi) Section 170.314(c)(3) or Sec. 170.315(c)(3); (xii) Section 170.314(d)(1) or Sec. 170.315(d)(1); (xiii) Section 170.314(d)(2) or Sec. 170.315(d)(2); (xiv) Section 170.314(d)(3) or Sec. 170.315(d)(3); (xv) Section 170.314(d)(4) or Sec. 170.315(d)(4); (xvi) Section 170.314(d)(5) or Sec. 170.315(d)(5); (xvii) Section 170.314(d)(6) or Sec. 170.315(d)(6); (xviii) Section 170.314(d)(7) or Sec. 170.315(d)(7); and (xix) Section 170.314(d)(8) or Sec. 170.315(d)(8). (4) Has been certified to the certification criteria at Sec. 170.314(c)(1) and (2) or Sec. 170.315(c)(1) and (2): (i) For no fewer than 9 clinical quality measures covering at least 3 domains from the set selected by CMS for eligible professionals, including at least 6 clinical quality measures from the recommended core set identified by CMS; or (ii) For no fewer than 16 clinical quality measures covering at least 3 domains from the set selected by CMS for eligible hospitals and critical access hospitals. * * * * * Certified EHR Technology means: * * * * * (2) For FY and CY 2014 and subsequent years, the following: EHR technology certified under the ONC HIT Certification Program to the 2014 or 2015 Edition EHR certification criteria that has: (i) The capabilities required to meet the Base EHR definition; and (ii) All other capabilities that are necessary to meet the objectives and associated measures under 42 CFR 495.6 and successfully report the clinical quality measures selected by CMS in the form and manner specified by CMS (or the States, as applicable) for the stage of meaningful use that an eligible professional, eligible hospital, or critical access hospital seeks to achieve. Common MU Data Set * * * * * (6) Preferred language. (i) The standard specified in Sec. 170.207(g)(1) for certification to the 2014 Edition EHR certification criteria. (ii) The standard specified in Sec. 170.207(g)(2) for certification to the 2015 Edition EHR certification criteria. * * * * * Device Identifier is defined as it is in 21 CFR 801.3. * * * * * EHR Module means any service, component, or combination thereof that can meet the requirements of at least one certification criterion adopted by the Secretary. (1) MU EHR Module means any service, component, or combination thereof that is designed for purposes of the EHR Incentive Programs and can meet the requirements of at least one certification criterion adopted by the Secretary as part of the 2015 Edition EHR certification criteria. (2) Non-MU EHR Module means any service, component, or combination thereof that is designed for any purpose other than the EHR Incentive Programs and can meet the requirements of at least one certification criterion adopted by the Secretary as part of the 2015 Edition EHR certification criteria. * * * * * Implantable Device is defined as it is in 21 CFR 801.3. * * * * * Production Identifier is defined as it is in 21 CFR 801.3. * * * * * Unique Device Identifier is defined as it is in 21 CFR 801.3. 0 3. In Sec. 170.202, republish the introductory text and add paragraphs (d) and (e) to read as follows: Sec. 170.202 Transport standards. The Secretary adopts the following transport standards: * * * * * (d) Standard. ONC Implementation Guide for Delivery Notification in Direct. (e) Standard. ONC Implementation Guide for Direct Edge Protocols. 0 4. Amend Sec. 170.204 by-- 0 A. Republishing the introductory text; 0 B. Revising paragraph (a); 0 C. Revising paragraph (b)(2) and adding paragraph (b)(3); and 0 D. Adding paragraphs (d) and (e). The revisions and additions read as follows: [[Page 10939]] Sec. 170.204 Functional standards. The Secretary adopts the following functional standards: (a) Accessibility. (1) Standard. Web Content Accessibility Guidelines (WCAG) 2.0, Level A Conformance (incorporated by reference in Sec. 170.299). (2) Standard. Web Content Accessibility Guidelines (WCAG) 2.0, Level AA Conformance. (b) * * * (2) Implementation specifications. HL7 Implementation Guide: Service-Oriented Architecture Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain, Draft Standard for Trial Use, Release 1. (3) Implementation specifications. HL7 Implementation Guide: Service-Oriented Architecture Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain, Release 1. * * * * * (d) Decision Support. Standard. HL7 Implementation Guide: Clinical Decision Support Knowledge Artifact Implementation Guide. (e) Decision Support. Standard. HL7 Decision Support Service Implementation Guide. 0 5. Amend Sec. 170.205 by-- 0 A. Republishing the introductory text; 0 B. Adding paragraph (a)(4); 0 C. Removing and reserving paragraphs (b)(1), (c), and (d)(1); 0 D. Adding paragraphs (d)(4) and (5); 0 E. Removing and reserving paragraphs (e)(1), and (e)(2); 0 F. Adding paragraph (e)(4); 0 G. Removing and reserving paragraph (f); 0 H. Revising paragraphs (g), (i), and (j); and 0 I. Adding paragraphs (l) and (m). The revisions and additions read as follows: Sec. 170.205 Content exchange standards and implementation specifications for exchanging electronic health information. The Secretary adopts the following content exchange standards and associated implementation specifications: (a) * * * (4) Standard. HL7 Implementation Guide for CDA[supreg] Release 2: Consolidated CDA Templates for Clinical Notes, Draft Standard for Trial Use, Release 2.0. The use of the ``unstructured document'' document- level template is prohibited. (b) * * * (1) [Reserved] * * * * * (c) [Reserved] (d) * * * (1) [Reserved] * * * * * (4) Standard. HL7 2.5.1 (incorporated by reference in Sec. 170.299). Implementation specifications. PHIN Messaging Guide for Syndromic Surveillance: Emergency Department, Urgent Care, and Inpatient Settings, Release 1.9. (5) HL7 Clinical Document Architecture (CDA), Release 2.0, Normative Edition (incorporated by reference in Sec. 170.299). (e) * * * (1) [Reserved] (2) [Reserved] * * * * * (4) Standard. HL7 2.5.1 (incorporated by reference in Sec. 170.299). Implementation specifications. HL7 2.5.1 Implementation Guide for Immunization Messaging, Release 1.5. (f) [Reserved] (g) Electronic transmission of lab results to public health agencies. (1) Standard. HL7 2.5.1 (incorporated by reference in Sec. 170.299). Implementation specifications. HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, Release 1 (incorporated by reference in Sec. 170.299) with Errata and Clarifications, (incorporated by reference in Sec. 170.299) and ELR 2.5.1 Clarification Document for EHR Technology Certification (incorporated by reference in Sec. 170.299). (2) Standard. HL7 2.5.1 (incorporated by reference in Sec. 170.299). Implementation specifications. HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, Draft Standard for Trial Use, Release 2. * * * * * (i) Cancer information. (1) Standard. HL7 Clinical Document Architecture (CDA), Release 2.0, Normative Edition (incorporated by reference in Sec. 170.299). Implementation specifications. Implementation Guide for Ambulatory Healthcare Provider Reporting to Central Cancer Registries, HL7 Clinical Document Architecture (CDA), Release 1.0 (incorporated by reference in Sec. 170.299). (2) Standard. HL7 Clinical Document Architecture (CDA), Release 2.0, Normative Edition (incorporated by reference in Sec. 170.299). Implementation specifications. Implementation Guide for Ambulatory Healthcare Provider Reporting to Central Cancer Registries, HL7 Clinical Document Architecture (CDA), Release 1.1. (j) Electronic incorporation and transmission of lab results. (1) Standard. HL7 Version 2.5.1 Implementation Guide: S&I Framework Lab Results Interface (incorporated by reference in Sec. 170.299). (2) Standard. HL7 Version 2.5.1 Implementation Guide: S&I Framework Lab Results Interface, Release 1 (US Realm) (S&I Framework LRI) with Errata. * * * * * (l) Laboratory orders. (1) Standard. HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Orders from EHR. (2) [Reserved] (m) Family health history. (1) HL7 Version 3 Standard: Clinical Genomics; Pedigree (incorporated by reference in Sec. 170.299). Implementation specifications. HL7 Version 3 Implementation Guide: Family History/Pedigree Interoperability. (2) [Reserved] 0 6. Amend Sec. 170.207 by-- 0 A. Republishing the introductory text; 0 B. Removing and reserving paragraphs (a)(1), (a)(2), (b)(1), (c)(1), (d)(1), and (e)(1); and 0 C. Revising paragraph (g). The revisions read as follows: Sec. 170.207 Vocabulary standards for representing electronic health information. The Secretary adopts the following code sets, terminology, and nomenclature as the vocabulary standards for the purpose of representing electronic health information: (a) * * * (1) [Reserved] (2) [Reserved] * * * * * (b) * * * (1) [Reserved] * * * * * (c) * * * (1) [Reserved] * * * * * (d) * * * (1) [Reserved] * * * * * (e) * * * (1) [Reserved] * * * * * (g) Preferred language. (1) Standard. As specified by the Library of Congress, ISO 639-2 alpha-3 codes limited to those that also have a corresponding alpha-2 code in ISO 639-1 (incorporated by reference in Sec. 170.299). (2) Standard. As specified by the Library of Congress, ISO 639-2. * * * * * Sec. 170.210 [Amended] 0 7. In Sec. 170.210, remove and reserve paragraphs (a)(2) and (b). 0 8. Add Sec. 170.212 to read as follows: [[Page 10940]] Sec. 170.212 Performance standards for health information technology. The Secretary adopts the following performance standards for health information technology: (a) EHR technology must successfully electronically process documents validly formatted in accordance with the standard specified in Sec. 170.205(a)(4) no less than 95% of the time. (b) [Reserved] 0 9. In Sec. 170.300, revise paragraph (d) to read as follows: Sec. 170.300 Applicability. * * * * * (d) In Sec. Sec. 170.314 and 170.315, all certification criteria and all capabilities specified within a certification criterion have general applicability (i.e., apply to both ambulatory and inpatient settings) unless designated as ``inpatient setting only'' or ``ambulatory setting only.'' (1) Inpatient setting only means that the criterion or capability within the criterion is only required for certification of EHR technology designed for use in an inpatient setting. (2) Ambulatory setting only means that the criterion or capability within the criterion is only required for certification of EHR technology designed for use in an ambulatory setting. Sec. 170.302 [Removed and Reserved] 0 10. Remove and reserve Sec. 170.302. Sec. 170.304 [Removed and Reserved] 0 11. Remove and reserve Sec. 170.304. Sec. 170.306 [Removed and Reserved] 0 12. Remove and reserve Sec. 170.306. 0 13. In Sec. 170.314: 0 A. In Sec. 170.314(a)(3)(i)(B), remove ``Sec. 170.207(g)'' and add in its place ``Sec. 170.207(g)(1)''; 0 B. In Sec. 170.314(b)(5)(i)(A)(1), remove ``Sec. 170.205(j)'' and add in its place ``Sec. 170.205(j)(1)''; 0 C. In Sec. 170.314(b)(6), remove ``Sec. 170.205(j)'' and add in its place ``Sec. 170.205(j)(1)''; 0 D. In Sec. 170.314(e)(1)(i)(A), remove ``Sec. 170.204(a)'' and add in its place ``Sec. 170.204(a)(1)''; 0 E. In Sec. 170.314(f)(4)(i), remove ``Sec. 170.205(g)'' and add in its place ``Sec. 170.205(g)(1)''; 0 F. In Sec. 170.314(f)(6), remove ``Sec. 170.205(i)'' and add in its place '' Sec. 170.205(i)(1)''; and 0 G. Revise Sec. 170.314(f)(3) and (g)(1). The revisions read as follows: Sec. 170.314 2014 Edition electronic health record certification criteria. * * * * * (f) * * * (3) * * * (i) Ambulatory setting only. The standard specified in Sec. 170.205(d)(2), (d)(5), or (k). (B) Optional. The standard (and applicable implementation specifications) specified in Sec. 170.205(d)(4). (ii) Inpatient setting only. The standard (and implementation specifications) specified in Sec. 170.205(d)(4). * * * * * (g) * * * (1) Optional--Automated numerator recording. For each meaningful use objective with a percentage-based measure, EHR technology must be able to create a report or file that enables a user to review the patients or actions that would make the patient or action eligible to be included in the measure's numerator. The information in the report or file created must be of sufficient detail such that it enables a user to match those patients or actions to meet the measure's denominator limitations when necessary to generate an accurate percentage. * * * * * 0 14. Add Sec. 170.315 as follows: Sec. 170.315 2015 Edition electronic health record certification criteria. The Secretary adopts the following certification criteria for EHR technology certification. EHR technology must include the capability to perform the following functions electronically, unless designated as optional, and in accordance with all applicable standards and implementation specifications adopted in this part: (a) Clinical. (1) Computerized provider order entry--medications. Enable a user to electronically record, change, and access medication orders. (2) Computerized provider order entry--laboratory. (i) Enable a user to electronically record, change, and access laboratory orders. (ii) Ambulatory setting only. Enable a user to electronically create laboratory orders for electronic transmission: (A) With all the information for a test requisition as specified at 42 CFR 493.1241(c)(1) through (c)(8); and (B) In accordance with the standard specified at Sec. 170.205(l)(1) and, at a minimum the version of the standard at Sec. 170.207(c)(2). (3) Computerized provider order entry--radiology/imaging. Enable a user to electronically record, change, and access radiology and imaging orders. (4) Drug-drug, drug-allergy interaction checks. (i) Interventions. Before a medication order is completed and acted upon during computerized provider order entry (CPOE), interventions must automatically and electronically indicate to a user drug-drug and drug- allergy contraindications based on a patient's medication list and medication allergy list. (ii) Adjustments. (A) Enable the severity level of interventions provided for drug-drug interaction checks to be adjusted. (B) Limit the ability to adjust severity levels to an identified set of users or available as a system administrative function. (5) Demographics. (i) Enable a user to electronically record, change, and access patient demographic data including preferred language, sex, race, ethnicity, and date of birth. (A) Enable race and ethnicity to be recorded in accordance with the standard specified in Sec. 170.207(f) and whether a patient declines to specify race and/or ethnicity. (B) Enable preferred language to be recorded in accordance with the standard specified in Sec. 170.207(g)(2) and whether a patient declines to specify a preferred language. (ii) Inpatient setting only. Enable a user to electronically record, change, and access the preliminary cause of death and date of death in the event of a mortality. (6) Vital signs, body mass index, and growth charts. (i) Vital signs. Enable a user to electronically record, change, and access, at a minimum, a patient's height/length, weight, and blood pressure. Height/ length, weight, and blood pressure must be recorded in numerical values only. (ii) Calculate body mass index. Automatically calculate and electronically display body mass index based on a patient's height and weight. (iii) Optional--Plot and display growth charts. Plot and electronically display, upon request, growth charts for patients. (7) Problem list. Enable a user to electronically record, change, and access a patient's active problem list: (i) Ambulatory setting. Over multiple encounters in accordance with, at a minimum, the version of the standard specified in Sec. 170.207(a)(3); or (ii) Inpatient setting. For the duration of an entire hospitalization in accordance with, at a minimum, the version of the standard specified in Sec. 170.207(a)(3). (8) Medication list. Enable a user to electronically record, change, and access a patient's active medication list as well as medication history: (i) Ambulatory setting. Over multiple encounters; or [[Page 10941]] (ii) Inpatient setting. For the duration of an entire hospitalization. (9) Medication allergy list. Enable a user to electronically record, change, and access a patient's active medication allergy list as well as medication allergy history: (i) Ambulatory setting. Over multiple encounters; or (ii) Inpatient setting. For the duration of an entire hospitalization. (10) Clinical decision support. (i) Evidence-based decision support interventions. Enable a limited set of identified users to select (i.e., activate) one or more electronic clinical decision support interventions (in addition to drug-drug and drug-allergy contraindication checking) based on each one and at least one combination of the following data: (A) Problem list; (B) Medication list; (C) Medication allergy list; (D) At least one demographic specified in paragraph (a)(5)(i) of this section; (E) Laboratory tests; and (F) Vital signs. (ii) Linked referential clinical decision support. (A) EHR technology must be able to: (1) Electronically identify for a user diagnostic and therapeutic reference information; or (2) Electronically identify for a user diagnostic and therapeutic reference information in accordance with the standard specified at Sec. 170.204(b) and the implementation specifications at Sec. 170.204(b)(1) or (3). (B) For paragraph (a)(10)(ii)(A) of this section, EHR technology must be able to electronically identify for a user diagnostic or therapeutic reference information based on each one and at least one combination of the data referenced in paragraphs (a)(10)(i)(A), (B), and (D) of this section. (iii) Clinical decision support configuration. (A) Enable interventions and reference resources specified in paragraphs (a)(10)(i) and (ii) of this section to be configured by a limited set of identified users (e.g., system administrator) based on a user's role. (B) EHR technology must enable interventions to be electronically triggered: (1) Based on the data referenced in paragraphs (a)(10)(i)(A) through (F) of this section. (2) When a patient's medications, medication allergies, and problems are incorporated from a transition of care/referral summary received pursuant to paragraph (b)(1)(i)(B) of this section. (3) Ambulatory setting only. When a patient's laboratory tests and values/results are incorporated pursuant to paragraph (b)(4)(i)(A)(1) of this section. (iv) Automatically and electronically interact. Interventions triggered in accordance with paragraphs (a)(10)(i) through (iii) of this section must automatically and electronically occur when a user is interacting with EHR technology. (v) Source attributes. Enable a user to review the attributes as indicated for all clinical decision support resources: (A) For evidence-based decision support interventions under paragraph (a)(10)(i) of this section: (1) Bibliographic citation of the intervention (clinical research/ guideline); (2) Developer of the intervention (translation from clinical research/guideline); (3) Funding source of the intervention development technical implementation; and (4) Release and, if applicable, revision date(s) of the intervention or reference source. (B) For linked referential clinical decision support in paragraph (a)(10)(ii) of this section and drug-drug, drug-allergy interaction checks in paragraph(a)(4) of this section, the developer of the intervention, and where clinically indicated, the bibliographic citation of the intervention (clinical research/guideline). (vi) Decision support--knowledge artifact. Electronically process clinical decision support knowledge artifacts in accordance with the standard specified at Sec. 170.204(d). (vii) Decision support--service. Enable a user to electronically make an information request with patient data and receive in return electronic clinical guidance in accordance with the standard specified at Sec. 170.204(e). (11) Electronic notes. Enable a user to electronically: (i) Record, change, and access electronic notes; and (ii) Search within and across electronic notes stored within EHR technology. (12) Drug-formulary checks. EHR technology must automatically and electronically check whether a drug formulary (or preferred drug list) exists for a given patient and medication. (13) Smoking status. Enable a user to electronically record, change, and access the smoking status of a patient in accordance with the standard specified at Sec. 170.207(h). (14) Image results. Electronically indicate to a user the availability of a patient's images and narrative interpretations (relating to the radiographic or other diagnostic test(s)) and enable electronic access to such images and narrative interpretations. (15) Family health history. Enable a user to electronically record, change, and access a patient's family health history according to the standard and implementation specification specified at Sec. 170.205(m)(1). (16) Patient list creation. Enable a user to electronically and dynamically select, sort, access, and create patient lists by: date and time; and based on each one and at least one combination of the following data: (i) Problems; (ii) Medications; (iii) Medication allergies; (iv) At least one demographic specified in paragraph (a)(5)(i) of this section; (v) Laboratory tests and values/results; and (vi) Ambulatory setting only. Patient communication preferences. (17) Patient-specific education resources. EHR technology must be able to electronically identify for a user patient-specific education resources based on data included in the patient's problem list, medication list, and laboratory tests: (i) In accordance with the standard specified at Sec. 170.204(b) and the implementation specifications at Sec. 170.204(b)(1) or (3); and (ii) By any means other than using the standard specified in Sec. 170.204(b). (18) Inpatient setting only--electronic medication administration record. (i) In combination with an assistive technology that provides automated information on the ``rights'' specified in paragraphs (a)(18)(i)(A) through (E) of this section, enable a user to electronically verify the following before administering medication(s): (A) Right patient. The patient to whom the medication is to be administered matches the medication to be administered. (B) Right medication. The medication to be administered matches the medication ordered for the patient. (C) Right dose. The dose of the medication to be administered matches the dose of the medication ordered for the patient. (D) Right route. The route of medication delivery matches the route specified in the medication order. (E) Right time. The time that the medication was ordered to be administered compared to the current time. (ii) Right documentation. Electronically record the time and date in accordance with the standard specified in Sec. 170.210(g), and user [[Page 10942]] identification when a medication is administered. (19) Inpatient setting only--advance directives. Enable a user to electronically record whether a patient has an advance directive. (20) Implantable device list. (i) Enable a user to electronically access and view a list of Unique Device Identifiers and other relevant information associated with a patient's Implantable Device(s). (ii) Enable a user to electronically record in a patient's Implantable Device list the following information at the time the Implantable Device is implanted or removed: (A) The Unique Device Identifier associated with the Implantable Device; and (B) Other relevant information about the Implantable Device or procedure. (iii) For each Unique Device Identifier in a patient's Implantable Device list, allow a user to separately access and view electronically the Device Identifier and Production Identifier portions of the Unique Device Identifier. (b)Care coordination. (1) Transitions of care. (i) Send and receive via edge protocol. EHR technology must be able to electronically: (A) Send transitions of care/referral summaries through a method that conforms to the standard specified at Sec. 170.202(e) and that leads to such summaries being processed by a service that has implemented the standard specified in Sec. 170.202(a); and (B) Receive transitions of care/referral summaries through a method that conforms to the standard specified at Sec. 170.202(e) from a service that has implemented the standard specified in Sec. 170.202(a). (ii) Receiving accuracy. EHR technology must meet or exceed the standard specified at Sec. 170.212(a) (iii) Display. (A) EHR technology must be able to electronically display in human readable format the data included in transition of care/referral summaries received and formatted according to any of the following standards (and applicable implementation specifications) specified in: Sec. 170.205(a)(1) through (4). (B) Section views. Extract and allow for individual display each additional section or sections (and the accompanying document header information) that were included in a transition of care/referral summary received and formatted in accordance with the standard adopted at Sec. 170.205(a)(3). (iv) Create. (A) Enable a user to electronically create a transition of care/referral summary formatted according to the standard adopted at Sec. 170.205(a)(4) that includes, at a minimum, the Common MU Data Set and the following data expressed, where applicable, according to the specified standard(s): (1) Encounter diagnoses. The standard specified in Sec. 170.207(i) or, at a minimum, the version of the standard specified Sec. 170.207(a)(3); (2) Immunizations. The standard specified in Sec. 170.207(e)(2); (3) Cognitive status; (4) Functional status; (5) Ambulatory setting only. The reason for referral; and referring or transitioning provider's name and office contact information; (6) Inpatient setting only. Discharge instructions; and (7) Unique Device Identifier(s) for a patient's Implantable Device(s). (B) Patient matching data quality. EHR technology must be capable of creating a transition of care/referral summary that includes the following data and, where applicable, represent such data according to the additional constraints specified below: (1) Data. first name, last name, middle name (or middle initial in cases where only it exists/is used), suffix, date of birth, place of birth, maiden name, current address, historical address, phone number, and sex. (2) Constraint. Represent last/family name according to the CAQH Phase II Core 258: Eligibility and Benefits 270/271 Normalizing Patient Last Name Rule version 2.1.0. (3) Constraint. Represent suffix according to the CAQH Phase II Core 258: Eligibility and Benefits 270/271 Normalizing Patient Last Name Rule version 2.1.0 (JR, SR, I, II, III, IV, V, RN, MD, Ph.D., ESQ). If no suffix exists, the field should be entered as null. (4) Constraint. Represent the year, month and date of birth are required fields while hour, minute and second should be optional fields. If hour, minute and second are provided then either time zone offset should be included unless place of birth (city, region, country) is provided; in latter local time is assumed. If date of birth is unknown, the field should be marked as null. (5) Constraint. Represent current and historical address information, including the street address, city, state, zip code, according to the United States Postal Service format; (6) Constraint. Represent phone number (home, business, cell) in the ITU format specified in ITU-T E.123 and ITU-T E.164. If multiple phone numbers are present, all should be included. (7) Constraint. Represent sex according to the HL7 Version 3 ValueSet for Administrative Gender. (2) Clinical information reconciliation and incorporation. (i) Correct patient. Upon receipt of a transition of care/referral summary formatted according to the standard adopted at Sec. 170.205(a)(4), EHR technology must be able to demonstrate that the transition of care/ referral summary received is or can be properly matched to the correct patient. (ii) Reconciliation. Enable a user to electronically reconcile the data that represent a patient's active medication, problem, and medication allergy list as follows. For each list type: (A) Electronically and simultaneously display (i.e., in a single view) the data from at least two list sources in a manner that allows a user to view the data and their attributes, which must include, at a minimum, the source and last modification date; (B) Enable a user to create a single reconciled list of medications, medication allergies, or problems; (C) Enable a user to review and validate the accuracy of a final set of data; and (D) Upon a user's confirmation, automatically update the list, and electronically incorporate the following data expressed according to the specified standard(s): (1) Medications. At a minimum, the version of the standard specified in Sec. 170.207(d)(2); (2) Problems. At a minimum, the version of the standard specified in Sec. 170.207(a)(3); (3) Medication allergies. At a minimum, the version of the standard specified in Sec. 170.207(d)(2). (3) Electronic prescribing. Enable a user to electronically create prescriptions and prescription-related information for electronic transmission in accordance with: (i) The standard specified in Sec. 170.205(b)(2); and (ii) At a minimum, the version of the standard specified in Sec. 170.207(d)(2). (4) Incorporate laboratory tests and values/results. (i) Receive results. (A) Ambulatory setting only. (1) Electronically receive and incorporate clinical laboratory tests and values/results in accordance with the standard specified in Sec. 170.205(j)(2) and, at a minimum, the version of the standard specified in Sec. 170.207(c)(2). (2) Electronically display the tests and values/results received in human readable format. (B) Inpatient setting only. Electronically receive clinical laboratory tests and values/results in a structured format and electronically display such [[Page 10943]] tests and values/results in human readable format. (ii) Electronically display the test report information: (A) Specified in 42 CFR 493.1291(a)(1) through (a)(3) and (c)(1) through (c)(7); (B) Related to reference values as specified in 42 CFR 493.1291(d); (C) For alerts and delays as specified in 42 CFR 493.1291(g) and (h); and (D) For corrected reports as specified in 42 CFR 493.1291(k)(2). (iii) Electronically attribute, associate, or link a laboratory test and value/result with a laboratory order or patient record. (5) Inpatient setting only--transmission of electronic laboratory tests and values/results to ambulatory providers. EHR technology must be able to electronically create laboratory test reports for electronic transmission: (i) That includes the information: (A) For a test report as specified in 42 CFR 493.1291(a)(1) through (a)(3) and (c)(1) through (c)(7); (B) Related to reference values as specified in 42 CFR 493.1291(d); (C) For alerts and delays as specified in 42 CFR 493.1291(g) and (h); and (D) For corrected reports as specified in 42 CFR 493.1291(k)(2); and (ii) In accordance with the standard specified in Sec. 170.205(j)(2) and with laboratory tests expressed in accordance with, at a minimum, the version of the standard specified in Sec. 170.207(c)(2). (6) Data portability. Enable a user to electronically create a set of export summaries for all patients in EHR technology formatted according to the standard adopted at Sec. 170.205(a)(4) that represents the most current clinical information about each patient and includes, at a minimum, the Common MU Data Set and the following data expressed, where applicable, according to the specified standard(s): (i) Encounter diagnoses. The standard specified in Sec. 170.207(i) or, at a minimum, the version of the standard at Sec. 170.207(a)(3); (ii) Immunizations. The standard specified in Sec. 170.207(e)(2); (iii) Cognitive status; (iv) Functional status; (v) Ambulatory setting only. The reason for referral; and referring or transitioning provider's name and office contact information; (vi) Inpatient setting only. Discharge instructions; and (vii) Unique Device Identifier(s) for a patient's Implantable Device(s). (c) Clinical quality measures. (1) Clinical quality measures-- capture and export. (i) Capture. For each and every CQM for which the EHR technology is presented for certification, EHR technology must be able to electronically record all of the data identified in the standard specified at Sec. 170.204(c) that would be necessary to calculate each CQM. Data required for CQM exclusions or exceptions must be codified entries, which may include specific terms as defined by each CQM, or may include codified expressions of ``patient reason,'' ``system reason,'' or ``medical reason.'' (ii) Export. EHR technology must be able to electronically export a data file formatted in accordance with the standards specified at Sec. 170.205(h) that includes all of the data captured for each and every CQM to which EHR technology was certified under paragraph (c)(1)(i) of this section. (2) Clinical quality measures--import and calculate. (i) Import. EHR technology must be able to electronically import a data file formatted in accordance with the standard specified at Sec. 170.205(h) and use such data to perform the capability specified in paragraph (c)(2)(ii) of this section. EHR technology presented for certification to all three of the certification criteria adopted in paragraphs (c)(1) through (3) of this section is not required to meet paragraph (c)(2)(i). (ii) Calculate. EHR technology must be able to electronically calculate each and every clinical quality measure for which it is presented for certification. (3) Clinical quality measures--electronic submission. Enable a user to electronically create a data file for transmission of clinical quality measurement data: (i) In accordance with the standards specified at Sec. 170.205(h) and (k); and (ii) That can be electronically accepted by CMS. (4) Clinical quality measures--patient population filtering. EHR technology must be able to record structured data for the purposes of being able to filter CQM results to create different patient population grouping by one or a combination of the following patient characteristics: (i) practice site and address; (ii) Tax Identification Number (TIN), National Provider Identifier (NPI), and TIN/PIN combination; (iii) Diagnosis; (iv) Primary and secondary health insurance, including identification of Medicare and Medicaid dual eligibles; and (v) Demographics including age, sex, preferred language, education level, and socioeconomic status. (d) Privacy and security. (1) Authentication, access control, and authorization. (i) Verify against a unique identifier(s) (e.g., username or number) that a person seeking access to electronic health information is the one claimed; and (ii) Establish the type of access to electronic health information a user is permitted based on the unique identifier(s) provided in paragraph (d)(1)(i) of this section, and the actions the user is permitted to perform with the EHR technology. (2) Auditable events and tamper-resistance. (i) Record actions. EHR technology must be able to: (A) Record actions related to electronic health information in accordance with the standard specified in Sec. 170.210(e)(1); and (B) Record the encryption status (enabled or disabled) of electronic health information locally stored on end-user devices by EHR technology in accordance with the standard specified in Sec. 170.210(e)(3) unless the EHR technology prevents electronic health information from being locally stored on end-user devices (see 170.314(d)(7) of this section). (ii) Default setting. EHR technology must be set by default to perform the capabilities specified in paragraph (d)(2)(i)(A) of this section and, where applicable, paragraph (d)(2)(i)(B). (iii) Prevent disabling. EHR technology must prevent all users from being able to disable the capabilities specified in paragraphs (d)(2)(i)(A) and (B) of this section through the EHR technology. (iv) Audit log protection. Actions and statuses recorded in accordance with paragraph (d)(2)(i) of this section must not be capable of being changed, overwritten, or deleted by the EHR technology. (v) Detection. EHR technology must be able to detect whether the audit log has been altered. (3) Audit report(s). Enable a user to create an audit report for a specific time period and to sort entries in the audit log according to each of the data specified in the standards at Sec. 170.210(e). (4) Amendments. Enable a user to electronically select the record affected by a patient's request for amendment and perform the capabilities specified in paragraphs (d)(4)(i) or (ii) of this section. (i) Accepted amendment. For an accepted amendment, append the amendment to the affected record or include a link that indicates the amendment's location. (ii) Denied amendment. For a denied amendment, at a minimum, append the request and denial of the request to the [[Page 10944]] affected record or include a link that indicates this information's location. (5) Automatic log-off. Prevent a user from gaining further access to an electronic session after a predetermined time of inactivity. (6) Emergency access. Permit an identified set of users to access electronic health information during an emergency. (7) End-user device encryption. Paragraph (d)(7)(i) or (ii) of this section must be met to satisfy this certification criterion. (i) EHR technology that is designed to locally store electronic health information on end-user devices must encrypt the electronic health information stored on such devices after use of EHR technology on those devices stops. (A) Electronic health information that is stored must be encrypted in accordance with the standard specified in Sec. 170.210(a)(1). (B) Default setting. EHR technology must be set by default to perform this capability and, unless this configuration cannot be disabled by any user, the ability to change the configuration must be restricted to a limited set of identified users. (ii) EHR technology is designed to prevent electronic health information from being locally stored on end-user devices after use of EHR technology on those devices stops. (8) Integrity. (i) Create a message digest in accordance with the standard specified in Sec. 170.210(c). (ii) Verify in accordance with the standard specified in Sec. 170.210(c) upon receipt of electronically exchanged health information that such information has not been altered. (9) Accounting of disclosures. Record disclosures made for treatment, payment, and health care operations in accordance with the standard specified in Sec. 170.210(d). (e) Patient engagement. (1) View, download, and transmit to 3rd party. (i) Patients (and their authorized representatives) must be able to use EHR technology to view, download, and transmit their health information to a 3rd party in the manner specified below. Access to these capabilities must be online and through a secure channel that ensures all content is encrypted and integrity-protected in accordance with the standard for encryption and hashing algorithms specified at Sec. 170.210(f). (A) View. Patients (and their authorized representatives) must be able to use EHR technology to electronically view in accordance with the standard adopted at Sec. 170.204(a)(2), at a minimum, the following data: (1) The Common MU Data Set (which should be in their English (i.e., non-coded) representation if they associate with a vocabulary/code set). (2) Ambulatory setting only. Provider's name and office contact information. (3) Inpatient setting only. Admission and discharge dates and locations; discharge instructions; and reason(s) for hospitalization. (B) Download. (1) Patients (and their authorized representatives) must be able to use EHR technology to electronically download an ambulatory summary or inpatient summary (as applicable to the EHR technology setting for which certification is requested) in only human readable format, in only the format specified in accordance to the standard adopted at Sec. 170.205(a)(4), or in both formats. (2) When downloaded according to the standard adopted at Sec. 170.205(a)(4), the ambulatory summary or inpatient summary must include, at a minimum, the following data (which, for the human readable version, should be in their English representation if they associate with a vocabulary/code set): (i) Ambulatory setting only. All of the data specified in paragraph (e)(1)(i)(A)(1) and (2) of this section and Unique Device Identifier(s) for a patient's implantable device(s). (ii) Inpatient setting only. All of the data specified in paragraphs (e)(1)(i)(A)(1) and (3) of this section and Unique Device Identifier(s) for a patient's Implantable Device(s). (3) Inpatient setting only. Patients (and their authorized representatives) must be able to electronically download transition of care/referral summaries that were created as a result of a transition of care (pursuant to the capability expressed in the certification criterion adopted at paragraph (b)(1) of this section). (C) Transmit to third party. Patients (and their authorized representatives) must be able to: (1) Enter a 3rd party destination of their choice to electronically transmit: (i) The ambulatory summary or inpatient summary (as applicable to the EHR technology setting for which certification is requested) created in paragraph (e)(1)(i)(B)(1) of this section in accordance with the standard specified in Sec. 170.202(a). (ii) Inpatient setting only. Electronically transmit transition of care/referral summaries (as a result of a transition of care/referral) selected by the patient (or their authorized representative) in accordance with the standard specified in Sec. 170.202(a). (2) Accomplish a transmission of their ambulatory summary or inpatient summary through a method that conforms to the standard specified at Sec. 170.202(e) and that leads to such summary being processed by a service that has implemented the standard specified in Sec. 170.202(a). (ii) Activity history log. (A) When electronic health information is viewed, downloaded, or transmitted to a third-party using the capabilities included in paragraphs (e)(1)(i)(A) through (C) of this section, the following information must be recorded and made accessible to the patient: (1) The action(s) (i.e., view, download, transmission) that occurred; (2) The date and time each action occurred in accordance with the standard specified at Sec. 170.210(g); (3) The user who took the action; and (4) The addressee to whom an ambulatory summary or inpatient summary was transmitted and whether that transmission was successful (or failed). (B) EHR technology presented for certification may demonstrate compliance with paragraph (e)(1)(ii)(A) of this section if it is also certified to the certification criterion adopted at Sec. 170.315(d)(2) and the information required to be recorded in paragraph (e)(1)(ii)(A) is accessible by the patient. (2) Ambulatory setting only--clinical summary. (i) Create. Enable a user to create a clinical summary for a patient in human readable format and formatted according to the standards adopted at Sec. 170.205(a)(4). (ii) Customization. Enable a user to customize the data included in the clinical summary. (iii) Minimum data from which to select. EHR technology must permit a user to select, at a minimum, the following data when creating a clinical summary: (A) Common MU Data Set (which, for the human readable version, should be in their English representation if they associate with a vocabulary/code set); (B) Medications administered during the visit. At a minimum, the version of the standard specified in Sec. 170.207(d)(2); (C) Immunizations administered during the visit. At a minimum, the version of the standard specified in Sec. 170.207(e)(2); (D) Diagnostic tests pending and future scheduled tests. At a minimum, the version of the standard specified in Sec. 170.207(c)(2); (E) The provider's name and office contact information; date and location of visit; reason for visit; clinical instructions; future appointments; [[Page 10945]] referrals to other providers; and recommended patient decision aids; and (F) Unique Device Identifier(s) for a patient's Implantable Device(s). (3) Ambulatory setting only--secure messaging. Enable a user to electronically send messages to, and receive messages from, a patient in a manner that ensures: (i) Both the patient (or authorized representative) and EHR technology user are authenticated; and (ii) The message content is encrypted and integrity-protected in accordance with the standard for encryption and hashing algorithms specified at Sec. 170.210(f). (f) Public health. (1) Immunization information. Enable a user to electronically record, change, and access immunization information. (2) Transmission to immunization registries. EHR technology must be able to electronically create immunization information for electronic transmission in accordance with: (i) The standard and applicable implementation specifications specified in Sec. 170.205(e)(4); and (ii) At a minimum, the version of the standard specified in Sec. 170.207(e)(2). (3) Transmission to public health agencies--syndromic surveillance. EHR technology must be able to electronically create syndrome-based public health surveillance information for electronic transmission in accordance with: (i) Ambulatory setting only. (A) The standard specified in Sec. 170.205(d)(2), (d)(5), or (k). (B) Optional. The standard (and applicable implementation specifications) specified in Sec. 170.205(d)(4). (ii) Inpatient setting only. The standard (and applicable implementation specifications) specified in Sec. 170.205(d)(4). (4) Inpatient setting only--transmission of reportable laboratory tests and values/results. EHR technology must be able to electronically create reportable laboratory tests and values/results for electronic transmission in accordance with: (i) The standard (and applicable implementation specifications) specified in Sec. 170.205(g)(2); and (ii) At a minimum, the versions of the standards specified in Sec. 170.207(a)(3) and (c)(2). (5) Ambulatory setting only--cancer case information. Enable a user to electronically record, change, and access cancer case information. (6) Ambulatory setting only--transmission to cancer registries. EHR technology must be able to electronically create cancer case information for electronic transmission in accordance with: (i) The standard (and applicable implementation specifications) specified in Sec. 170.205(i)(2); and (ii) At a minimum, the versions of the standards specified in Sec. 170.207(a)(3) and (c)(2). (g) Utilization. (1) Automated numerator recording. For each meaningful use objective with a percentage-based measure, EHR technology must be able to create a report or file that enables a user to review the patients or actions that would make the patient or action eligible to be included in the measure's numerator. The information in the report or file created must be of sufficient detail such that it enables a user to match those patients or actions to meet the measure's denominator limitations when necessary to generate an accurate percentage. (2) Automated measure calculation. For each meaningful use objective with a percentage-based measure that is supported by a capability included in an EHR technology, electronically record the numerator and denominator and create a report including the numerator, denominator, and resulting percentage associated with each applicable meaningful use measure. (3) Safety-enhanced design. User-centered design processes must be applied to each capability an EHR technology includes that is specified in the following certification criteria: Sec. 170.315(a)(1) through (4), (8) through (10), and (18) and (b)(2) and (3). (4) Quality management system. For each capability that an EHR technology includes and for which that capability's certification is sought, the use of a Quality Management System (QMS) in the development, testing, implementation and maintenance of that capability must be identified. (i) If a single QMS was used for applicable capabilities, it would only need to be identified once. (ii) If different QMS were applied to specific capabilities, each QMS applied would need to be identified. This would include the application of a QMS to some capabilities and none to others. (iii) If no QMS was applied to all applicable capabilities such a response is acceptable to satisfy this certification criterion. (5) Non-percentage-based measures use report. (i) For each capability included in EHR technology that is also associated with a meaningful use objective and measure that is not percentage-based (except for the capabilities specified in Sec. 170.315(a)(12), (b)(1), and (d)) electronically record evidence that a user used or interacted with the capability and the date and time that such use or interaction occurred, in accordance with the standard specified at Sec. 170.210(g). (ii) Enable a user to electronically create a report of the information recorded as part of paragraph (g)(5)(i) of this section for the user's identified Medicare or Medicaid EHR Incentive Program reporting period. (h) Transmission. (1) Transmit--Applicability Statement for Secure Health Transport. Enable health information to be electronically transmitted in accordance with the standard specified in Sec. 170.202(a). (2) Transmit--Applicability Statement for Secure Health Transport and XDR/XDM for Direct Messaging. Enable health information to be electronically transmitted in accordance with the standard specified in Sec. 170.202(b). (3) Transmit--SOAP Transport and Security Specification and XDR/XDM for Direct Messaging. Enable health information to be electronically transmitted in accordance with the standard specified in Sec. 170.202(c). (4) Transmit--Applicability Statement for Secure Health Transport and Delivery Notification in Direct. Enable health information to be electronically transmitted in accordance with the standard specified in Sec. 170.202(d). Subpart D--[Removed and Reserved] 0 15. Remove and reserve subpart D, consisting of Sec. Sec. 170.400 through 170.499. 0 16. Revise Sec. 170.501 to read as follows: Sec. 170.501 Applicability. (a) This subpart establishes the processes that applicants for ONC- ACB status must follow to be granted ONC-ACB status by the National Coordinator; the processes the National Coordinator will follow when assessing applicants and granting ONC-ACB status; the requirements that ONC-ACBs must follow to maintain ONC-ACB status; and the requirements of ONC-ACBs for certifying Complete EHRs, EHR Module(s), and other types of HIT in accordance with the applicable certification criteria adopted by the Secretary in subpart C of this part. It also establishes the processes accreditation organizations must follow to request approval from the National Coordinator and that the National Coordinator in turn will follow to approve an accreditation organization [[Page 10946]] under the ONC HIT Certification Program as well as certain ongoing responsibilities for an ONC-AA. (b) References to the term Complete EHR and Complete EHR certification throughout this subpart do not apply to certification in accordance with the 2015 Edition EHR certification criteria and any subsequent edition of certification criteria adopted by the Secretary under subpart C of this part. 0 17. Amend Sec. 170.502 by adding the definition ``Certification Package,'' to read as follows: * * * * * Certification Package means an identified set of certification criteria adopted by the Secretary in subpart C of this part that represent a specific grouping of capabilities. (1) 2015 Edition Care Coordination Package includes, at a minimum, Sec. 170.315(b)(1) and (2). (2) 2015 Edition Patient Engagement Package includes, at a minimum, Sec. 170.315(e)(1) and (3). * * * * * 0 18. In Sec. 170.503, revise paragraphs (b)(1) and (e)(2) to read as follows: Sec. 170.503 Requests for ONC-AA status and ONC-AA ongoing responsibilities. * * * * * (b) * * * (1) A detailed description of the accreditation organization's conformance to ISO/IEC17011 (incorporated by reference in Sec. 170.599) and experience evaluating the conformance of certification bodies to ISO/IEC 17065. * * * * * (e) * * * (2) Verify that the certification bodies it accredits and ONC-ACBs conform to, at a minimum: (i) For fiscal years 2014 and 2015, ISO/IEC Guide 65 (incorporated by reference in Sec. 170.599); and (ii) For fiscal year 2016 and subsequent years, ISO/IEC 17065. * * * * * 0 19. In Sec. 170.523, republish the introductory text, revise paragraph (k)(1)(iii), and add paragraphs (k)(1)(iv) and (l) to read as follows: Sec. 170.523 Principles of proper conduct for ONC-ACBs. An ONC-ACB shall: * * * * * (k) * * * (1) * * * (iii) Any additional types of costs that an EP, EH, or CAH would pay to implement the Complete EHR's or EHR Module's capabilities in order to attempt to meet meaningful use objectives and measures. Beginning with EHR technology certified to the 2015 Edition EHR certification criteria, any additional types of costs that an EP, EH, or CAH would pay to implement the MU EHR Module's capabilities in order to attempt to meet meaningful use objectives and measures. EHR technology self-developers are excluded from the requirements of this paragraph. (iv) If an EHR Module developer chooses to represent that an EHR Module satisfies a certification package(s) as defined in Sec. 170.502 of this subpart, such representations must be accurate. * * * * * (l) Display the ONC Certified HIT Certification and Design Mark on all certifications issued under the ONC HIT Certification Program in a manner that complies with the Criteria and Terms of Use for the ONC Certified HIT Certification and Design Mark, and ensure that use of the mark by HIT developers whose products are certified under the ONC HIT Certification Program is compliant with the Criteria and Terms of Use for the ONC Certified HIT Certification and Design Mark. 0 20. In Sec. 170.550, remove and reserve paragraph (e), revise paragraph (f) introductory text and (f)(1), redesignate paragraph (g) as (h), and add a new paragraph (g) to read as follows: Sec. 170.550 EHR Module certification. * * * * * (e) [Reserved] (f) When certifying an EHR Module to the 2014 Edition EHR certification criteria, an ONC-ACB must certify the EHR Module in accordance with the certification criteria at: (1) Section 170.314(g)(1) or (g)(2) if the EHR Module has capabilities presented for certification that would support a meaningful use objective with a percentage-based measure; * * * * * (g) When certifying an EHR Module to the 2015 Edition EHR certification criteria, an ONC-ACB must certify the EHR Module in accordance with the certification criteria at: (1) Section 170.315(g)(1) or (g)(2) if the MU EHR Module has capabilities presented for certification that would support a meaningful use objective with a percentage-based measure; (2) Section 170.315(g)(3) if the EHR Module is presented for certification to one or more listed certification criteria in Sec. 170.315(g)(3); (3) Section 170.315(g)(4); and (4) Section 170.315(g)(5) if the MU EHR Module has capabilities presented for certification that would support a meaningful use objective with a non-percentage-based measure. * * * * * Dated: February 18, 2014. Kathleen Sebelius, Secretary. [FR Doc. 2014-03959 Filed 2-21-14; 4:15 pm] BILLING CODE 4150-45-P
This site is protected by reCAPTCHA and the Google
Privacy Policy and
Terms of Service apply.
