2014 Edition Release 2 Electronic Health Record (EHR) Certification Criteria and the ONC HIT Certification Program; Regulatory Flexibilities, Improvements, and Enhanced Health Information Exchange, 54429-54480 [2014-21633]

Download as PDF Vol. 79 Thursday, No. 176 September 11, 2014 Part IV Department of Health and Human Services tkelley on DSK3SPTVN1PROD with RULES2 Office of the Secretary 45 CFR Part 170 2014 Edition Release 2 Electronic Health Record (EHR) Certification Criteria and the ONC HIT Certification Program; Regulatory Flexibilities, Improvements, and Enhanced Health Information Exchange; Final Rule VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 PO 00000 Frm 00001 Fmt 4717 Sfmt 4717 E:\FR\FM\11SER2.SGM 11SER2 54430 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations DEPARTMENT OF HEALTH AND HUMAN SERVICES Office of the Secretary 45 CFR Part 170 RIN 0991–AB92 2014 Edition Release 2 Electronic Health Record (EHR) Certification Criteria and the ONC HIT Certification Program; Regulatory Flexibilities, Improvements, and Enhanced Health Information Exchange Office of the National Coordinator for Health Information Technology (ONC), Department of Health and Human Services. ACTION: Final rule. AGENCY: This final rule introduces regulatory flexibilities and general improvements for certification to the 2014 Edition EHR certification criteria (2014 Edition). It also codifies a few revisions and updates to the ONC HIT Certification Program for certification to the 2014 Edition and future editions of certification criteria as well as makes administrative updates to the Code of Federal Regulations. DATES: This rule is effective October 14, 2014, except for the amendments to the amendatory instruction number 3 amendment to § 170.102, the amendments to §§ 170.205, 170.207, 170.210, 170.302, 170.304, 170.306, and the amendatory instruction number 18 amendment to § 170.550, which are effective on March 1, 2015. The incorporation by reference of certain publications listed in the rule is approved by the Director of the Federal Register as of October 14, 2014. FOR FURTHER INFORMATION CONTACT: Michael Lipinski, Office of Policy, Office of the National Coordinator for Health Information Technology, 202– 690–7151. SUPPLEMENTARY INFORMATION: SUMMARY: tkelley on DSK3SPTVN1PROD with RULES2 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 VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 EHR Electronic Health Record EP Eligible Professional FDA Food and Drug Administration FY Fiscal Year HHS Department of Health and Human Services HIT Health Information Technology HITECH Health Information Technology for Economic and Clinical Health HITPC HIT Policy Committee HITSC HIT Standards Committee HL7 Health Level Seven IG Implementation Guide IHE Integrating the Healthcare Enterprise® LOINC® Logical Observation Identifiers Names and Codes MU Meaningful Use OMB Office of Management and Budget ONC Office of the National Coordinator for Health Information Technology NCPDP National Council for Prescription Drug Programs NIST National Institute of Standards and Technology PHSA Public Health Service Act SNOMED CT® Systematized Nomenclature of Medicine Clinical Terms Table of Contents I. Executive Summary A. Purpose of Regulatory Action 1. New Approach 2. Edition Naming Convention B. Summary of Major Provisions 1. Overview of the 2014 Edition Release 2 EHR Certification Criteria 2. ONC HIT Certification Program C. Costs and Benefits II. Background A. Statutory Basis 1. Standards, Implementation Specifications, and Certification Criteria 2. HIT Certification Programs B. Regulatory History 1. Standards, Implementation Specifications, and Certification Criteria Rules 2. ONC HIT Certification Programs Rules III. Adopted Proposals A. 2014 Edition Release 2 EHR Certification Criteria 1. National Technology Transfer and Advancement Act (NTTAA) of 1995 2. Certification Criteria 3. Gap Certification Eligibility Table for 2014 Edition Release 2 4. Base EHR Definition B. ONC HIT Certification Program 1. Discontinuation of the Complete EHR 2. Applicability 3. ONC Regulations FAQ 28 4. Patient List Creation Certification Criteria 5. ISO/IEC 17065 6. ONC Certification Mark C. Removal of the 2011 Edition EHR Certification Criteria From the CFR D. Removal of the Temporary Certification Program From the CFR IV. Not Adopted Proposals A. Not Adopted EHR Certification Criteria and Certification Criteria Proposals B. 2014 Edition and Proposed Voluntary Edition Equivalency Table C. HIT Definitions 1. CEHRT PO 00000 Frm 00002 Fmt 4701 Sfmt 4700 2. Common MU Data Set C. ONC HIT Certification Program 1. Non-MU EHR Technology Certification 2. ‘‘Certification Packages’’ for EHR Modules V. Comments Beyond the Scope of This Final Rule VI. Collection of Information Requirements VII. 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 I. Executive Summary A. Purpose of Regulatory Action 1. New Approach In the notice of proposed rulemaking titled ‘‘Voluntary 2015 Edition Electronic Health Record (EHR) Certification Criteria; Interoperability Updates and Regulatory Improvements; Proposed Rule’’ (79 FR 10880) (the ‘‘Proposed Rule’’), we gave many reasons for the adoption of the proposed ‘‘2015 Edition EHR certification criteria’’ or ‘‘2015 Edition’’ (henceforth the ‘‘Proposed Voluntary Edition’’ (79 FR 10880)).1 We still believe that many of these reasons remain valid. However, upon consideration of public comment, further reflection of ONC goals and timelines, and a desire to adhere to the administration’s principles embodied in Executive Order (EO) 13563, we have not adopted the Proposed Voluntary Edition. Rather, we have adopted a small subset of our original proposals in the Proposed Voluntary Edition as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria (also referred to as the ‘‘2014 Edition Release 2’’ or ‘‘2014 Edition Release 2 EHR certification criteria’’) that provide flexibility, clarity, and enhance health information exchange; and administrative proposals (i.e., removal of regulatory text from the Code of Federal Regulations) and proposals for the ONC HIT Certification Program that provide improvements. The certification criteria we have adopted in this final rule are consistent with the principles and instructions for retrospective review of regulations embodied in EO 13563 to make our program more effective and less burdensome in achieving regulatory objectives. This final rule introduces multiple means to reduce regulatory burden, increase regulatory flexibility for stakeholders, and promote further innovation. 1 79 E:\FR\FM\11SER2.SGM FR 10881–82. 11SER2 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations tkelley on DSK3SPTVN1PROD with RULES2 We note that EHR technology developers do not have to update and recertify their products to the 2014 Edition Release 2 nor do eligible professionals (EPs), eligible hospitals (EHs), and critical access hospitals (CAHs) have to upgrade to EHR technology certified to the 2014 Edition Release 2. However, we encourage EHR technology developers and the EPs, EHs, and CAHs that they support to consider whether the 2014 Edition Release 2 offers any opportunities that they might want to pursue. 2. Naming Conventions In the Proposed Rule, we proposed to call the Proposed Voluntary Edition the ‘‘2015 Edition.’’ 2 Comments. Commenters indicated that attributing years to the certification criteria editions creates unrealistic expectations for providers and other potential ‘‘users’’ of the certification program that vendors will develop products ready to be used by the designated edition year. Response. In the July 28, 2010 final rule entitled ‘‘Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology (75 FR 44590) and referred to as the ‘‘2011 Edition Final Rule,’’ the Secretary adopted certification criteria in title 45, part 170, §§ 170.302, 170.304, and 170.306 of the Code of Federal Regulations (CFR). In March 2012, to make a clear distinction between the certification criteria adopted in §§ 170.302, 170.304, and 170.306 and the certification criteria proposed for adoption in § 170.314 (the notice of proposed rulemaking with request for comments titled, ‘‘Health Information Technology: Standards, Implementation Specification and Certification Criteria for Electronic Health Record Technology, 2014 Edition; Revisions to the Permanent Certification Program for Health Information Technology’’ (77 FR 13832)), we discussed that we would be using an ‘‘edition’’ naming approach for the sets of certification criteria subsequently adopted by the Secretary. We stated that we would refer to the certification criteria adopted in the 2011 Edition Final Rule and included in §§ 170.302, 170.304, and 170.306 collectively as the ‘‘2011 Edition EHR certification criteria’’ and that the certification criterion adopted in § 170.314 would be referred to as the ‘‘2014 Edition EHR certification criteria.’’ We finalized this approach and adopted a ‘‘2014 Edition’’ in the 2 79 FR 10885. VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 September 4, 2012 final rule we issued entitled ‘‘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) (the ‘‘2014 Edition Final Rule’’). These two years ‘‘2011’’ and ‘‘2014’’ were purposefully chosen because they coincided with the first year in which compliance with that edition of EHR certification criteria would be required for use under the Medicare and Medicaid EHR Incentive Programs (‘‘EHR Incentive Programs’’). This approach was meant to simplify the communication related to the certification criteria editions and enabled generalized statements like ‘‘an EP needs to be using 2014 Edition CEHRT when they demonstrate meaningful use (MU) in CY 2014.’’ In retrospect, it appears that this approach unintentionally linked certification criteria editions solely to MU to many stakeholders, while the certification criteria editions already support and are referenced by other HHS programs (e.g., the CMS and HHS Office of Inspector General (OIG) final rules to modify the Physician Self-Referral Law exception and Anti-kickback Statute safe harbor for certain EHR donations (78 FR 78751) and (78 FR 79202), respectively).3 We and CMS recently issued a final rule (79 FR 52910) that demonstrated linking a certification criteria edition’s year to any other program’s compliance date could confuse the original intent of the edition’s year selection (due to the final rule pushing back the compliance requirement of using EHR technology certified only to the 2014 Edition to fiscal year (FY) and calendar year (CY) 2015 for EPs, EHs, and CAHs). Accordingly, we believe that a simpler approach will be for future certification criteria editions to be named by the year in which the final rule is published, and other rulemakings like this final rule (which include additional criteria or alternatives to previously adopted certification criteria) would be added to the most current edition of certification criteria. To further clarify, a rulemaking like this one that does not adopt an edition of certification criteria would be referred to as ‘‘[current edition year] Release #X.’’ 3 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). OIG final rule ‘‘Medicare and State Health Care Programs: Fraud and Abuse; Electronic Health Records Safe Harbor Under the Anti-Kickback Statute’’ (78 FR 79202). PO 00000 Frm 00003 Fmt 4701 Sfmt 4700 54431 For example, we expect that the final rule for the next edition of certification criteria we adopt will be an edition of certification criteria and will be published in 2015. Thus, that edition of certification criteria would be called the ‘‘2015 Edition’’ because it will be an edition of certification criteria and its final rule would be published in 2015. If we were to subsequently issue a final rule in 2016 with seven certification criteria to support another HHS program or to make revisions to the adopted 2015 Edition certification criteria, we would refer to that rulemaking as the ‘‘2015 Edition Release 2’’ rulemaking and ultimately make modifications to the 2015 Edition certification criteria at its CFR location and regulation text. Importantly, this provides stakeholders with a consistent and predictable naming approach for future editions and also supports ONC’s broader interests to have the ONC HIT Certification Program be generally accessible to other programs either within or outside government. Stakeholders that seek to leverage the ONC HIT Certification Program would then be able to choose which edition of certification criteria (or subset of criteria within an edition) is most relevant and appropriate for their program needs. B. Summary of Major Provisions 1. Overview of the 2014 Edition Release 2 EHR Certification Criteria The 2014 Edition Release 2 EHR certification criteria we have adopted in this final rule include ten optional and two revised certification criteria for inclusion in the 2014 Edition.4 Each of these certification criteria originate with the current 2014 Edition. The optional certification criteria include the splitting of the ‘‘computerized provider order entry’’ (CPOE) criterion into three certification criteria based on capabilities (medications, laboratory, and diagnostic imaging); a ‘‘transitions of care’’ (ToC) certification criterion that is decoupled from the transport method; three separate transport method certification criteria (corresponding to the three transport standards found in § 170.314(b)(1) and (2)); a ‘‘clinical information reconciliation and incorporation certification’’ (CIRI) certification criterion that moves 4 As we explained in the Proposed Rule (79 FR 10918), the designation of ‘‘optional’’ for certification criteria (in this case, the 2014 Edition) was developed to accommodate the Complete EHR definition. If a certification criterion is not designated ‘‘optional,’’ an EHR technology designed for the ambulatory setting or inpatient setting would need to be certified to the criterion in order to satisfy the Complete EHR definition and be issued a Complete EHR certification. E:\FR\FM\11SER2.SGM 11SER2 54432 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations ‘‘incorporation’’ from the ToC certification criterion; and a ‘‘transmission to public health agencies—syndromic surveillance’’ certification criterion that permits any electronic method for creating syndromic surveillance information for exchange. Additionally, the ‘‘automated numerator recording’’ certification criterion (§ 170.314(g)(1)) has been changed to be designated ‘‘optional’’ for the purposes of excluding it from the 2014 Edition Complete EHR definition as discussed in more detail in the ONC HIT Certification Program section below. The two revised certification criterion include a revised ‘‘view, download, and transmit to 3rd party’’ (VDT) certification criterion (§ 170.314(e)(1)) that permits the same optionality provided in the new optional ToC certification criterion as it relates to transport methods, and a revised ‘‘safety-enhanced design’’ (SED) certification criterion that includes the optional CPOE certification criteria and the optional CIRI certification criterion. We discuss the revisions to SED under the discussions of CPOE and CIRI in section III.A.2 of this preamble. Table 1 below specifies the 2014 Edition Release 2 EHR certification criteria. TABLE 1—2014 EDITION RELEASE 2 EHR CERTIFICATION CRITERIA Optional certification criteria Revised certification criteria Regulation section Title of regulation paragraph Regulation section § 170.314(a)(18) ........ Optional—computerized provider order entry— medications. Optional—computerized provider order entry— laboratory. Optional—computerized provider order entry— diagnostic imaging. Optional—transitions of care. Optional—clinical information reconciliation and incorporation. Optional—ambulatory setting only—Transmission to public health agencies— syndromic surveillance. Optional—automated numerator recording. Optional—Applicability Statement for Secure Health Transport. Optional—Applicability Statement for Secure Health Transport and XDR/XDM for Direct Messaging. Optional—SOAP Transport and Security Specification and XDR/XDM for Direct Messaging. § 170.314(e)(1) .......... View, download, and transmit to 3rd party. § 170.314(g)(3) .......... Safety-enhanced design. § 170.314(a)(19) ........ § 170.314(a)(20) ........ § 170.314(b)(8) .......... § 170.314(b)(9) .......... § 170.314(f)(7) ........... § 170.314(g)(1) .......... § 170.314(h)(1) .......... § 170.314(h)(2) .......... § 170.314(h)(3) .......... tkelley on DSK3SPTVN1PROD with RULES2 2. ONC HIT Certification Program We proposed several modifications to the ONC HIT Certification Program, some of which we have finalized in this final rule. We are discontinuing the ‘‘Complete EHR’’ certification concept, including the definition, starting with the next certification criteria edition that we adopt in a subsequent final rule. This decision has no effect on certification to the 2014 Edition. We have adopted an updated standard (ISO/ IEC 17065) for the accreditation of ONCAuthorized Certification Bodies (ACBs) to maintain alignment with industry practices. We have adopted the ‘‘ONC Certified HIT’’ certification and design mark for required use by ONC–ACBs, which we believe will provide clarity for the market as it relates to EHR technology certified under the program. We have designated the 2014 Edition ‘‘automated numerator recording’’ VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 certification criterion (§ 170.314(g)(1)) as optional for the purposes of excluding it from Complete EHR certification (it still applies for EHR Module certification) and revised § 170.550(f) to clearly require and permit EHR Module certification to either § 170.314(g)(1) or (g)(2) (‘‘automated measure calculation’’). Last, we have provided clarifying guidance for certification to the 2014 Edition ‘‘patient list creation’’ certification criterion. C. Costs and Benefits Our estimates indicate that this final rule is not an economically significant rule as its overall costs are significantly below $100 million in any one year. We have, however, estimated the costs and benefits of this final 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 adopted PO 00000 Frm 00004 Fmt 4701 Sfmt 4700 Title of regulation paragraph optional and revised 2014 Edition certification criteria (and the standards and implementation specifications they include) are represented in monetary terms in Table 2 below. We believe a small number of EHR technology developers and other health information technology (HIT) developers will seek to be tested and certified to the certification criteria adopted in this final rule. We estimate that development and preparation efforts for the optional and revised 2014 Edition certification criteria adopted in the final rule will be split evenly over CYs 2014 and 2015 and will be confined to these years because we expect to issue a 2015 Edition final rule in 2015 and expect that the majority of EHR development and preparation efforts at that time will shift towards meeting the 2015 Edition. The dollar amounts expressed in Table 2 are expressed in 2014 dollars. E:\FR\FM\11SER2.SGM 11SER2 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations 54433 TABLE 2—DISTRIBUTED TOTAL DEVELOPMENT AND PREPARATION COSTS FOR EHR TECHNOLOGY DEVELOPERS (2-YEAR PERIOD)—TOTALS ROUNDED Year Ratio (percent) 2014 ................................................................................................................................. 2015 ................................................................................................................................. 2-Year Totals ................................................................................................................... 50 50 .................... While we believe only a small number of EHR technology developers and other HIT developers will seek testing and certification to the optional and revised 2014 Edition certification criteria adopted in the final rule, the regulatory flexibility these certification criteria provide will offer several significant benefits to patients, health care providers, and HIT developers. The 2014 Edition Release 2 incorporates stakeholder feedback on particular 2014 Edition issues identified as impacting innovation and causing undue burden. The 2014 Edition Release 2 also seeks to continue to improve EHR technology’s interoperability and electronic health information exchange. Specifically, the separating out of the ‘‘content’’ and ‘‘transport’’ capabilities in the optional 2014 Edition ToC certification criterion we have adopted in this final rule (compared to the 2014 Edition ToC certification criteria adopted at § 170.314(b)(1) and (2)) and the adoption of the Implementation Guide (IG) for Direct Edge Protocols (Direct Edge Protocols IG) is aimed at improving the market availability of electronic health information exchange services for transitions of care. The new certification flexibilities offered by the optional ‘‘CPOE’’ and optional ‘‘syndromic surveillance’’ certification criteria are designed to enhance innovation and offer providers enhanced functionality and options for meeting applicable MU measures. The new flexibility in the VDT certification criterion is designed to further facilitate the exchange of patient health information between provider and patient. The optional CIRI criterion is designed to better align with clinical workflows than the process in the ToC certification criterion at § 170.314(b)(1). tkelley on DSK3SPTVN1PROD with RULES2 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. VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 111–5), was enacted on February 17, 2009. The HITECH Act amended the Public Health Service Act (PHSA) and created ‘‘Title XXX—Health Information Technology and Quality’’ (Title XXX) to improve health care quality, safety, and efficiency through the promotion of HIT and electronic health information exchange. 1. Standards, Implementation Specifications, and Certification Criteria The HITECH Act established two new federal advisory committees, the HIT Policy Committee (HITPC) and the HIT Standards Committee (HITSC) (sections 3002 and 3003 of the PHSA, respectively). Each is responsible for advising the National Coordinator for Health Information Technology (National Coordinator) on different aspects of standards, implementation specifications, and certification criteria. The HITPC is responsible for, among other duties, recommending priorities for the development, harmonization, and recognition of standards, implementation specifications, and certification criteria. Main responsibilities of the HITSC include recommending standards, implementation specifications, and certification criteria for adoption by the Secretary under section 3004 of the PHSA consistent with the ONCcoordinated 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 PO 00000 Frm 00005 Fmt 4701 Sfmt 4700 Total low cost estimate ($M) $1.46 1.46 2.92 Total high cost estimate ($M) $2.90 2.90 5.80 Total average cost estimate ($M) $2.19 2.19 4.38 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 E:\FR\FM\11SER2.SGM 11SER2 54434 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations 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.’’ tkelley on DSK3SPTVN1PROD with RULES2 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 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). The Secretary issued a notice of proposed rulemaking with request for comments titled ‘‘Health Information Technology: Standards, Implementation VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 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’’). 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 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. The interim final rule also revised the EHR Incentive Programs by adding an alternative measure for the MU Stage 2 objective for hospitals to provide structured electronic laboratory results to ambulatory providers, corrected the regulation text for the measures associated with the objective for hospitals to provide patients the ability to view online, download, and transmit information about a hospital admission, and made the case number threshold exemption policy for clinical quality measure (CQM) reporting applicable for eligible hospitals and CAHs beginning with FY 2013. The rule also provided notice of CMS’s intent to issue technical corrections to the electronic specifications for CQMs released on October 25, 2012 (77 FR 72985). On November 4, 2013, the Secretary published an interim final rule with a request for comment, 2014 Edition Electronic Health Record Certification PO 00000 Frm 00006 Fmt 4701 Sfmt 4700 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. On February 26, 2014, the Secretary issued the Proposed Rule. The Proposed Rule proposed voluntary certification criteria that would enable a more efficient and effective response to stakeholder feedback, incorporate ‘‘bug fixes’’ to improve on 2014 Edition in ways designed to make ONC’s rules clearer and easier to implement, and reference newer standards and implementation specifications. A correction notice was published for the Proposed Rule on March 19, 2014, entitled ‘‘Voluntary 2015 Edition Electronic Health Record (EHR) Certification Criteria; Interoperability Updates and Regulatory Improvements; Correction’’ (79 FR 15282). This correction notice corrected the preamble text and gap certification table for four certification criteria that were omitted from the list of certification criteria eligible for gap certification for the 2015 Edition EHR certification criteria. On May 23, 2014, CMS and ONC jointly published the ‘‘Medicare and Medicaid Programs; Modifications to the Medicare and Medicaid Electronic Health Record Incentive Programs for 2014; and Health Information Technology: Revisions to the Certified EHR Technology Definition’’ proposed rule (79 FR 29732). The rule proposed to update the MU Stage 2 and Stage 3 participation timeline. It proposed to revise the CEHRT definition to permit the use of EHR technology certified to the 2011 Edition to meet the CEHRT definition for FY/CY 2014. It also proposed to allow EPs, EHs, and CAHs that could not fully implement EHR technology certified to the 2014 Edition for an EHR reporting period in 2014 due to delays in the availability of such technology to continue to use EHR technology certified to the 2011 Edition or a combination of EHR technology certified to the 2011 Edition and 2014 Edition for the EHR reporting periods in CY 2014 and FY 2014. On September 4, 2014, a final rule (‘‘MU Flexibility Final Rule’’) was published (79 FR 52910) adopting these proposals. 2. 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 E:\FR\FM\11SER2.SGM 11SER2 tkelley on DSK3SPTVN1PROD with RULES2 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations ‘‘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. The Proposed Rule included proposals that focused on improving regulatory clarity, simplifying the certification of EHR Modules that are designed for purposes other than achieving MU, and discontinuing the use of the Complete EHR definition starting with the ‘‘Proposed Voluntary Edition.’’ VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 III. Adopted Proposals A. 2014 Edition Release 2 EHR Certification Criteria We proposed to adopt the Proposed Voluntary Edition, which included a full set of certification criteria (57 certification criteria) for the ambulatory and inpatient settings. Comments. We received both positive and negative comments on the Proposed Voluntary Edition. Commenters that supported the Proposed Voluntary Edition stated that it was responsive to stakeholder feedback, permitted certification to new functionality and standards in a timely manner, and appropriately raised the bar on interoperability. Commenters that did not support the Proposed Voluntary Edition stated that the scope was too large, some standards were too immature for adoption, additional certification would be too costly (after just preparing EHR technology for certification to the 2014 Edition), and that it set an unrealistic expectation among providers and patients that EHR technology developers could have products certified to the Proposed Voluntary Edition in a timely manner (shortly after the 2014 Edition and while preparing for the next edition that would directly support MU Stage 3). Response. We thank commenters for their support of the Proposed Voluntary Edition. We also appreciate the constructive feedback offered by other commenters. As stated in the Executive Summary, we have only adopted a small subset of our original proposals in the Proposed Voluntary Edition as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria (also referred to as the ‘‘2014 Edition Release 2’’ or ‘‘2014 Edition Release 2 EHR certification criteria’’) that provide flexibility, clarity and enhance health information exchange. While we believe there are many valid reasons for the adoption of the Proposed Voluntary Edition, including those mentioned by commenters, we believe that our approach in this final rule is the most appropriate at this time. This approach addresses commenters’ concerns and introduces multiple means to reduce regulatory burden, increase regulatory flexibility for stakeholders, and promote further innovation. 1. National Technology Transfer and Advancement Act (NTTAA) of 1995 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) PO 00000 Frm 00007 Fmt 4701 Sfmt 4700 54435 Circular A–119 5 require the use of, 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 final rule, we have adopted ISO/IEC 17065, which is a voluntary consensus standard. We have also adopted the ONC Implementation Guide for Direct Edge Protocols, Version 1.1. This standard was not developed by a voluntary consensus standards body, but was developed by a group of industry stakeholders committed to advancing the Direct Project,6 which started as an initiative under the Standards and Interoperability (S&I) Framework.7 This group used a consensus process similar to those used by other industry stakeholders and voluntary consensus standards bodies. We are aware of no voluntary consensus standard that would serve as an alternative to this standard for the purposes that we have identified in this final rule. 2. Certification Criteria Computerized Provider Order Entry Section 3000 of the PHSA, as added by section 13101 of the HITECH Act, requires that computerized provider order entry (CPOE) capabilities be included in CEHRT. We included CPOE capabilities in the Base EHR definition, which is part of the CEHRT definition, under 45 CFR 170.102. Within the 2011 and 2014 Editions, we adopted CPOE certification criteria that require EHR technology to be capable of performing CPOE for medication, laboratory, and radiology/imaging orders. In the Proposed Rule, we stated that based on stakeholder feedback since the 2014 Edition Final Rule, we understood that this approach can prevent EHR technology developers from creating more efficient, provider-specific ‘‘adaptations’’ of EHR technology that support CPOE.8 For example, a mobile adaptation of CPOE currently must include all of the capabilities listed in the 2014 Edition CPOE certification 5 https://www.whitehouse.gov/omb/circulars_a119. 6 https://www.healthit.gov/policy-researchersimplementers/direct-project. 7 https://www.healthit.gov/policy-researchersimplementers/standards-interoperability-siframework. 8 Please see 77 FR 54267–68 for a discussion of adaptations. E:\FR\FM\11SER2.SGM 11SER2 tkelley on DSK3SPTVN1PROD with RULES2 54436 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations 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. Similarly, we noted that some providers could interpret our approach to CPOE certification as inconsistent with the flexibility provided in the FY/ CY 2014 CEHRT definition under § 170.102. As one example, we noted that 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). As another example, we stated that 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. As one final example, we explained that 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 proposed 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. For the reasons above, we proposed to split the CPOE certification criterion for the Proposed Voluntary Edition into three separate certification criteria with each criterion focused on one of the three order types, reasoning that certification criteria focused on each order type would permit EHR technology developers to develop orderspecific CPOE adaptations and provide EPs, EHs, and CAHs with significantly more implementation flexibility. In the Proposed Rule, we also stated that the proposed ‘‘CPOE’’ certification criteria would omit the ‘‘at a minimum’’ language included in the 2014 Edition and 2011 Edition CPOE certification criteria. We noted that the ‘‘at a minimum’’ language was included in prior editions to indicate that EHR VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 technology developers could include capabilities that support other types of orders. We stated that this language is extraneous because we have consistently maintained that certification criteria (and certification in general) serve as minimum requirements or a baseline. Comments. We received universal support for adopting three separate CPOE certification criteria based on medications, laboratory, and radiology/ imaging orders. We also received support for the elimination of the ‘‘at a minimum’’ language found in the 2011 and 2014 Edition criteria with commenters stating that elimination of the language would remove redundancy from the criteria and reduce confusion. Response. We have adopted these three certification criteria as 2014 Edition optional certification criteria based on stakeholder feedback and for the reasons we cited in the Proposed Rule. We clarify and emphasize that there are no standards included in the optional certification criteria, unlike the proposed CPOE—laboratory certification criterion. We have also omitted the ‘‘at a minimum’’ language in these certification criteria for the reasons proposed and supported by commenters. We have changed the title of the certification criterion that supports CPOE for ‘‘radiology/imaging’’ (§ 170.314(a)(20)) to ‘‘CPOE—diagnostic imaging’’ and changed the relevant regulation text of this certification criterion from ‘‘radiology and imaging orders’’ to ‘‘diagnostic imaging orders.’’ We have also made a similar revision to § 170.3014(a)(1)(iii) by replacing ‘‘radiology/imaging’’ with ‘‘diagnostic imaging.’’ We have made these revisions to eliminate any potential confusion as to the type of orders we are referencing. We note, however, that these revisions in no way alter the required capability. We have adopted the optional certification criteria at § 170.314(a)(18) through (20) and included them in the Base EHR definition. We have also revised the ‘‘safety-enhanced design’’ (SED) certification criterion at § 170.314(g)(3) to include the three optional CPOE certification criteria. These optional CPOE certification criteria included the same ‘‘patient safety-related’’ capabilities included in the CPOE certification criterion at § 170.314(a)(1) and thus the same ‘‘patient safety risk’’ rationale for their inclusion in the SED certification criterion at § 170.314(g)(3) applies.9 9 Please see the 2014 Edition Final Rule (77 FR 54187) for a discussion of the capabilities and certification criteria that we believe present a risk PO 00000 Frm 00008 Fmt 4701 Sfmt 4700 As we noted in the Proposed Rule (79 FR 10886), we caution that this additional flexibility comes with potential risk for EPs who expect to qualify for one or more of the exclusions from the CPOE measures, 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. Therefore, 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. We note that we discuss comments received on each of the three proposed CPOE certification criteria that suggested changes to the criteria under section IV.A ‘‘Not Adopted EHR Certification Criteria and Certification Criteria Proposals.’’ This includes a discussion of our reasons for not adopting the HL7 Laboratory Orders Interface (LOI) standard and the Clinical Laboratory Improvement Amendments (CLIA)-related requirements for the proposed ‘‘CPOE—laboratory’’ certification criterion. Transitions of Care We proposed to make several changes to the ‘‘transitions of care’’ (ToC) certification criterion, including decoupling content and transport capabilities, the inclusion of the Direct Edge Protocols IG Version 1.0, and shifting the ‘‘incorporation’’ requirements into an updated ‘‘clinical information reconciliation and incorporation’’ (CIRI). We included several other proposals in the ToC certification criterion that we have not finalized. These proposals are discussed in section IV.A of this preamble. ‘‘Decoupling’’ Content and Transport In the Proposed Rule, we recited specific stakeholder feedback stating that 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. We also recited stakeholder feedback indicating that we had incorrectly imposed the coupling of technical capabilities that to patient safety and thus are included in the SED certification criterion. E:\FR\FM\11SER2.SGM 11SER2 tkelley on DSK3SPTVN1PROD with RULES2 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations can be adequately performed by two different systems. More specifically, stakeholders 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. In this regard, we illustrated how the ‘‘binding’’ of the transport and content capabilities within the scope of a single criterion has led, in some cases, to the intertwining of EHR and health information service provider (HISP) functionality (i.e., HISP functionality being built into an EHR or EHR functionality being built into a HISP) solely for the purposes of certification. As a result, we proposed to decouple content and transport capabilities and adopt a single ToC criterion that focused on content capabilities and EHR technology’s capability to connect to a service that is conformant with the primary Direct Project specification through the use of the Direct Edge Protocols IG Version 1.0. Comments. We received significant public comment on this proposal from associations representing providers, consumers, and HIT developers as well as comments from numerous HIT developers. The vast majority of the commenters supported decoupling content and transport capabilities, with some voicing concerns about the proposed Edge Protocol IG Version 1.0. Specifically, commenters noted that the decoupling represented a much-needed flexibility for HIT developers and a workflow update that reflected implementations already widely used. One commenter, an ONC–ACB, noted that ToC and HISP functionality was already separated for most EHRs across different systems. Other commenters voiced concerns that the decoupling would create a greater burden on providers and hospitals as they assemble their certified systems. Finally, comments from the EHR technology developer community stated that the change was proposed too late to provide flexibility, noting that they had already complied with the 2014 Edition requirements and combined the functionality. Response. We have decided to finalize our proposal to decouple content and transport capabilities. We have also decided to adopt an updated version of the Direct Edge Protocols IG, which we discuss in more detail below. We appreciate the support for this proposal and agree with commenters that the decoupling will achieve much needed flexibility and allow for continued innovation in the market. While this flexibility may be considered too late by some stakeholders, we believe that the VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 potential benefits of its availability for the 2015 EHR reporting period outweigh the negatives. Accordingly, we have adopted an optional ToC certification criterion at § 170.314(b)(8) that focuses on content creation and edge protocol capabilities. We do not believe the optional ToC certification criterion will cause additional burden or complexity for EPs, EHs, and CAHs because it is voluntary and if pursued by an EHR technology developer will be done so to provide additional flexibility and options for an EP, EH, or CAH to choose their HISP. Edge Protocol for EHR to HISP Connectivity for Direct Transmissions Comments. Commenters voiced support for decoupling the content and transport requirements under the ToC criterion, however, many voiced concern about the Direct Edge Protocols IG Version 1.0 (‘‘Version 1.0’’). Commenters stated the protocol optionality in Version 1.0 provided the potential for interoperability incompatibilities. Commenters also noted that this level of optionality would require technology developers to support all four protocols in Version 1.0 in order to support the variety of valid protocol implementations in ToC. Commenters recommended ONC choose a minimum set of edge protocols that would be mandatory, instead of allowing all four. Other commenters noted that Version 1.0 was never intended to be part of a regulatory framework. Commenters also voiced concern that Version 1.0 did not have widespread development and implementation experience and it that it was premature to adopt it. Finally, commenters noted that the Direct Edge Protocols IG Version 1.1 (‘‘Version 1.1’’) would be finalized shortly and urged us to include that version instead of Version 1.0 if we decided to adopt the Direct Edge Protocol IG. Response. We appreciate the diverse and specific feedback on our proposal to adopt the Version 1.0. In addition to the comments we received on the Proposed Rule, stakeholders who helped develop Version 1.0 provided feedback (through the IG development process) that the edge protocol specifications and message tracking guidance needed to be clarified and refined based upon their experiences in the field. We agree that some of the ambiguities in Version 1.0 could introduce interoperability and implementation challenges for technology developers. Version 1.0 represented a first attempt toward a consistent and uniform approach for HISPs and EHR technology (and other so-called ‘‘edge’’ systems in the IG) to PO 00000 Frm 00009 Fmt 4701 Sfmt 4700 54437 implement the most common protocols (described as ‘‘edge protocols’’ in the IG) between these systems. In response to feedback, the stakeholder community (comprised of several HISPs and EHR technology developers) released an updated version of the IG for Direct Edge Protocols, Version 1.1 through the stakeholder lead Direct Project.10 Version 1.1, as discussed in more detail below, builds on and improves Version 1.0 with consistent implementation and interoperability in mind because it includes more thoroughly documented technical constraints for the edge protocols it references. Version 1.1 addresses many stakeholder concerns because it minimizes variability between implementations. As outlined in the Proposed Rule, we believe it is important to adopt a Direct Edge Protocols IG in order to support the separation of content and transport related to ToC. If we were to not adopt a Direct Edge Protocols IG, HIT developers would likely first implement inconsistent approaches to edge protocols and then need to spend additional resources later to reconcile those inconsistencies. Providing for certification to Version 1.1 can enable greater certainty and assurance to HIT developers that products certified to this IG have implemented the IG’s edge protocol(s) in a consistent manner. The availability of certification should also enhance HIT developers’ ability to reliably connect their products without the need for customized interfaces and, ultimately, enable health care providers a greater ability to choose or switch HISP services. Therefore, in consideration of public comments and our proposal to permit content and transport capabilities to be separately tested and certified, we have decided to adopt Version 1.1 as part of this optional ToC certification criterion. EHR technology presented for certification to the criterion adopted at § 170.314(b)(8) would need to demonstrate compliance with Version 1.1. The following explains the context and reasons for our decision to adopt Version 1.1 as a standard at § 170.202(d) and reference it within the optional ToC certification criterion at § 170.314(b)(8). For clarity, we note that the optional ToC certification criterion adopted at § 170.314(b)(8) would be only applicable to EHR technology in the role of the ‘‘edge system’’ identified in Version 1.1. We also note that this 10 https://www.healthit.gov/sites/default/files/ implementationguidefordirectedgeprotocolsv1_ 1.pdf. E:\FR\FM\11SER2.SGM 11SER2 tkelley on DSK3SPTVN1PROD with RULES2 54438 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations policy only applies for the purposes of EHR technology to be certified and is not meant to impose a ‘‘ceiling’’ or limit the use of other edge protocols if so implemented in order to enable electronic exchange for the purposes of meeting the MU transitions of care objective and measures. Version 1.1 includes two key improvements upon Version 1.0: • Version 1.1 clarifies the permissible combinations of edge protocols and their applicability within the scope of the IG. For example, two of the edge protocols within the IG (Post Office Protocol (POP) and Internet Message Access Protocol (IMAP)) are unidirectional, meaning they must be paired with another protocol to enable two-way communication between an ‘‘edge system’’ and its HISP. Version 1.0 did not clearly specify what the other protocols should be paired with POP and IMAP. Thus, implementers found this guidance incomplete and unclear. Version 1.1 addresses that ambiguity and instructs Edge systems to pair POP and IMAP with Simple Mail Transfer Protocol (SMTP). • Version 1.1 clarifies technical constraints for Cross-Enterprise Document Reliable Interchange (XDR), SMTP, POP, and IMAP. Implementers of Version 1.0 noted that the IG’s level of specification for edge protocols left room for too much variation in implementations, impacting interoperability by creating interface incompatibilities in some instances. In this case, Version 1.0’s ambiguities and inherent variability proved problematic and, from a consistent implementation perspective, demonstrated that a more tightly constrained specification would be beneficial. Version 1.1 improves the specificity around XDR, SMTP, POP, and IMAP in areas such as security and authentication to minimize variability and increase interoperability. Version 1.1 references the same four edge protocols that were referenced in Version 1.0: 1. Integrating the Healthcare Enterprise (IHE) XDR profile for Limited Metadata Document Sources; 2. SMTP; 3. Internet Message Access Protocol version 4rev1 (IMAP4); and 4. Post Office Protocol version 3 (POP3). However, with respect to the edge system specifications identified in Version 1.1, such edge systems are expected to support either the ‘‘IHE XDR profile for Limited Metadata Document Sources’’ edge protocol or an SMTP-focused edge protocol (SMTP alone or SMTP in combination with either IMAP4 or POP3). Thus, for the VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 purposes of testing and certification, compliance with this specific capability within the certification criterion can be demonstrated in one of two ways: Using the specific IHE XDR approach or one of the SMTP approaches. For this final rule, we evaluated whether to adopt a single edge protocol (of the four available) and decided to conduct fact finding with several HISPs and EHR technology developers to understand what edge protocol(s) they had implemented in the absence of any specific edge protocol requirements as part of the 2014 Edition. Our fact finding identified that EHR technology developers (for the ambulatory and inpatient settings) have already started implementing the two edge protocol approaches identified in Version 1.1 and used either an IHE XDR-based or SMTP-based edge protocol approach to connect to HISPs, and that HISPs were supporting both IHE XDR and SMTPbased edge protocol approaches in order to accommodate different customer needs. We also learned that smaller EHR technology developers were more likely to have implemented an SMTP-based edge protocol approach because the IHE XDR edge protocol approach would have been too resource-intensive. Given this additional information, we determined that requiring the adoption of a single edge protocol would be unwise since such an approach could disadvantage certain EHR technology developers in addition to not providing any commensurate downstream benefit to their customers (EPs, EHs and CAHs). Overall, we believe that the adoption of Version 1.1 will further support efforts already underway by the community by enabling EHR technology developers to demonstrate through testing and certification that they have implemented an edge protocol in a manner consistent with Version 1.1. Without this consistency, interoperability could be impacted and make it difficult for any specific EHR technology to reliably connect to any HISP. It could also lead to greater costs to providers for continued customized interfaces for the edge connectivity to a HISP and, thus, make it more likely that the provider would be ‘‘locked-in’’ to that HISP instead of being able to pair with/subscribe to a HISP of their choosing. Shifting ‘‘Incorporation’’ From ToC to Clinical Information Reconciliation In response to stakeholder feedback indicating that the inclusion of ‘‘incorporation’’ capabilities in the 2014 Edition ToC criterion (§ 170.314(b)(1)(iii)) was not aligned with typical clinical workflows, we PO 00000 Frm 00010 Fmt 4701 Sfmt 4700 proposed to include ‘‘incorporation’’ capabilities in a proposed ‘‘clinical information reconciliation and incorporation’’ (CIRI) certification criterion. The ‘‘incorporation’’ capabilities require EHR technology, upon receipt of a transition of care/ referral summary formatted according to the Consolidated CDA Release 1.1, to demonstrate that the transition of care/ referral summary received is or can be properly matched to the correct patient and it can electronically incorporate medications, problems, and medication allergies according to specified vocabulary standards. Comments. We received comments from several EHR developers on this proposal. Commenters overwhelmingly supported including the incorporation functionality in a CIRI criterion instead of a ToC criterion. Commenters stated that this was a better fit for the capabilities and more appropriate for clinical workflow. One commenter stated that we should change the language in the CIRI criterion to clarify ambiguities around the ‘‘extract’’ term and its associated requirements. Response. Given the comments in support, we have finalized our proposal to ‘‘move’’ the incorporation requirements into an updated CIRI criterion as proposed. We have adopted the updated CIRI criterion as an optional 2014 Edition certification criterion at § 170.314(b)(9). We agree with commenters that this approach will clarify the interplay between the ToC and CIRI certification criteria and will clear up any misconceptions about anticipated workflow. We decline to change the term ‘‘extract’’ at this time because: 1) It is not part of the CIRI criterion; and 2) the same term is used in the 2014 Edition ToC certification criterion at § 170.314(b)(1) as well as the new optional 2014 Edition ToC criterion at § 170.314(b)(8), and the term’s meaning and context is discussed in the 2014 Edition Final Rule (77 FR 54219). Clinical Information Reconciliation and Incorporation We proposed a CIRI certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. As discussed in more detail under the ToC certification criterion above, we proposed a CIRI criterion that included the same type of incorporation capabilities that we previously adopted as part of the ToC certification criterion at § 170.314(b)(1). Comments. As noted in the ToC certification criterion above, we received widespread support for ‘‘moving’’ the incorporation capabilities E:\FR\FM\11SER2.SGM 11SER2 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations into a CIRI certification criterion. One commenter suggested that we make this certification criterion eligible for gap certification. Response. We have adopted a new optional 2014 Edition CIRI certification criterion that includes the incorporation capability. We appreciate the comments in support of this proposal and believe it will more align with clinical workflow. This certification criterion is not eligible for gap certification because the change in capabilities required to meet this optional CIRI certification criterion make it a ‘‘revised’’ certification criterion as compared to the current 2014 Edition ‘‘clinical information reconciliation’’ (CIR) certification criterion and thus ineligible for gap certification. We have also revised the SED certification criterion at § 170.314(g)(3) to include this optional CIRI certification criterion. The optional CIRI certification criterion includes the same ‘‘patient safety-related’’ capabilities included in the CIR certification criterion at § 170.314(b)(4) and thus the same ‘‘patient safety risk’’ rationale for its inclusion in the SED certification criterion at § 170.314(g)(3) applies.11 tkelley on DSK3SPTVN1PROD with RULES2 View, Download, and Transmit to 3rd Party (VDT) The Proposed Rule summary in this section only summarizes and includes the ‘‘comments’’ and ‘‘response’’ for the proposal that we have adopted as part of this final rule. We included several other proposals in the proposed VDT certification criterion that we have not finalized. These proposals are discussed in section IV.A of this preamble. Decoupling Transport and Content For the reasons we provided in the Proposed Rule for the separation of content capabilities and transport capabilities (79 FR 10896–97, 10906) and recited under the ToC certification criterion discussed previously in this preamble section, we proposed to ‘‘decouple’’ the transport and content capabilities of the VDT certification criterion. We noted that similar to the proposed ToC revisions, the certification criterion would focus on content requirements and EHR technology’s ability to demonstrate conformance with the Direct Edge Protocols IG Version 1.0 and enable a successful transmission. We further specified that this would require EHR technology to enable a patient to 11 Please see the 2014 Edition Final Rule (77 FR 54187) for a discussion of the capabilities and certification criteria that we believe presented a risk to patient safety and thus included in the SED certification criterion. VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 accomplish a transmission that conforms to the Direct Edge Protocols IG Version 1.0 and is used by a service that has implemented the primary Direct Project specification. We clarified that ‘‘accomplish’’ was intended to convey our expectation and that our anticipated approach through testing would be to assess whether the transmitted Consolidated Clinical Document Architecture (CDA) arrived at its destination. We emphasized that under this proposed revision EHR technology developers seeking testing and certification would be permitted to demonstrate compliance with the transport requirement without having to be a HISP (or be bound to a single HISP through certification). However, we indicated that 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 (sent and received) in accordance with the primary Direct Project specification (under our new proposal for this to be a separate certification criterion). Comments. Given the parallels between this proposal and the proposal we made for the ToC criterion, the vast majority of commenters expressed the same general support for the ‘‘decoupling.’’ Commenters also expressed similar concerns about the proposed Edge Protocol IG Version 1.0 interoperability incompatibilities and the need for HIT developers to support all four protocols in order to support the variety of valid protocol implementations. In general, commenters stated that the decoupling of content and transport represented a much-needed flexibility for developers and a workflow update that reflected implementations already widely used. Response. For the same reasons we provide in response to the ToC certification criterion related to the decoupling of content and transport as well as the Direct Edge Protocols IG Version 1.1, we have adopted Version 1.1 for the purposes of the VDT certification criterion. In light of our overall approach for this final rule’s scope, we have determined that the best and simplest approach to include this new flexibility is to modify the existing VDT certification criterion at § 170.314(e)(1). This modification would add an alternative pathway for EHR technology developers to demonstrate compliance with the certification criterion. The modification would do so in a way that recognizes the content and transport separation we discussed in the Proposed Rule. Specifically, we have modified § 170.314(e)(1)(i)(C)(1) and (2) to PO 00000 Frm 00011 Fmt 4701 Sfmt 4700 54439 include the alternative ‘‘decoupled’’ approach. This revised regulatory text expresses that compliance with the specific transport capability requirement can be demonstrated in one of two ways. One way is the original approach adopted as part of the 2014 Edition Final Rule (certification to the ONC Applicability Statement for Secure Health Transport (Direct)).12 The other way is the new approach adopted in this final rule (certification to the Edge Protocol IG Version 1.1). We note that this optionality is specified with regulatory text that states ‘‘at least one of the following’’ to more clearly convey that both transport approaches do not need to be supported for the purposes of certification nor would an EHR technology developer customers need the other approach certified if the alternative was demonstrated for the purposes of certification. Transmission to Public Health Agencies—Syndromic Surveillance We proposed to revise the 2014 Edition ‘‘syndromic surveillance’’ certification criterion and adopt a parallel ‘‘syndromic surveillance’’ certification criterion for the Proposed Voluntary Edition. 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, nonhospital providers, and there was no corresponding HL7 2.5.1 IG available at the time of the final rule’s publication (77 FR 54025). CMS also noted, however, 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. We stated in the Proposed Rule that only a few public health agencies are currently accepting syndromic surveillance data from the ambulatory setting using HL7 2.5.1. We stated that due to lack of demand, the CDC no longer planned to develop an HL7 2.5.1 IG for ambulatory reporting of syndromic surveillance data and that without such an IG most public health agencies would not have enough specific guidance to build systems to receive syndromic surveillance data from the ambulatory setting formatted to HL7 2.5.1. Further, we noted that the MU Stage 2 final rule permits an EP, EH, or CAH to claim an exclusion if the public health agency does not have the 12 77 E:\FR\FM\11SER2.SGM FR 54182. 11SER2 tkelley on DSK3SPTVN1PROD with RULES2 54440 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations capacity to accept reporting (77 FR 54021) and, therefore, 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 proposed to revise the current 2014 Edition certification criterion to 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 indicated that syndromic surveillance data was being sent to public health agencies through new query-based models, including the QueryHealth initiative.13 Query-based models take patient level data, de-identify it, and aggregate it for population health use. In the Proposed Rule, we also noted that we understood that the query-based models use HL7 CDA and QRDA Category III (‘‘QRDA III’’) standards, and did not necessarily use the HL7 2.5.1 standard. Further, we stated that CDA and QRDA III standards were adopted and referenced by 2014 Edition certification criteria and, as a result, had become more widely implemented. 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 noted that we sought 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 proposed to specifically revise the 2014 Edition ‘‘syndromic surveillance’’ certification criterion at § 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. For EHR technology certification to the inpatient setting, we proposed to revise the 2014 Edition certification criterion by replacing the adopted version of the HL7 2.5.1 IG with a newer version of the IG that incorporates an addendum clarifying conformance guidance (PHIN Messaging Guide for Syndromic Surveillance: Emergency Department, Urgent Care, and Inpatient Settings, Release 1.9 (April 2013)). We proposed the same ambulatory and inpatient setting requirements in a parallel ‘‘syndromic surveillance’’ certification criterion for the Proposed Voluntary Edition. 13 https://wiki.siframework.org/Query+Health. VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 We solicited comment on whether public health agencies are using the QRDA Category I standard to receive query-based syndromic surveillance data, and whether we should consider adopting the standard for the ambulatory setting. Comments. We received a range of comments on the use of the CDA and QRDA III standards in addition to the HL7 2.5.1 standard for ambulatory setting certification. Some commenters stated that the added flexibility of allowing alternate standards would increase the exchange of syndromic surveillance data. Commenters stated that the lack of a HL7 2.5.1 IG for the ambulatory setting has led to variation across EHRs. Other commenters opined that the absence of an HL7 2.5.1 IG for the ambulatory setting has also resulted in reluctance from EHR developers to build custom interfaces to enable public health agencies to receive ambulatory syndromic surveillance. One public health agency commented that they have built the infrastructure to receive CDA and QRDA III through their HIE and related partners. This public health agency stated that CDA and QRDA III standards could represent significant advances for timely and efficient ambulatory syndromic surveillance data collection and supported the proposal to allow alternate standards for certification. Commenters in opposition to the proposal to allow use of CDA and QRDA III standards for certification stated that ONC should promote a single standard for ambulatory syndromic surveillance rather than allow multiple standards. Others commented that despite the proposed regulation text permitting use of HL7 2.5.1, CDA, ‘‘or’’ QRDA III standards, the ‘‘or’’ would really be implemented as an ‘‘and’’ if the EHR technology developer’s customers want to use CDA or QRDA III because an EHR developer would have to offer any and all options desired by their customers. Some commenters expressed concern that public health agencies are not ready to develop the infrastructure to receive CDA and QRDA III data if they had not previously done so. Commenters noted that, without specific IGs for the use of CDA and QRDA III for ambulatory syndromic surveillance, the standards are not constrained enough to reach uniform submission of the data. Likewise, commenters indicated that the CDA and QRDA III standards have not been piloted or tested for syndromic surveillance purposes. The majority of commenters supported adoption of the proposed updated IG for inpatient certification. However, many commenters stated that PO 00000 Frm 00012 Fmt 4701 Sfmt 4700 since the IG Release 1.9 publication numerous errors have been identified with Release 1.9. For example, many commenters pointed to the report issued by the International Society for Disease Surveillance identifying issues and errors with Release 1.9.14 Commenters opined that those issues and errors should be addressed before requiring compliance with Release 1.9. A few commenters noted that stakeholders are working toward Release 2.0 of the IG, which they noted would include more substantive updates relative to Release 1.8 in comparison to the updates included in Release 1.9. Therefore, the commenters recommended waiting to adopt Release 2.0 to avoid redundant and unnecessary work for EHRs and public health agencies as well as to get the maximum benefit for updated systems. A few commenters stated that QRDA Category I is not being used for querybased syndromic surveillance in ambulatory settings and opined that Category I is not appropriate as it includes patient-level results rather than aggregate results which are more suitable for syndromic surveillance. Response. We proposed revisions to the 2014 Edition version of this criterion and a ‘‘syndromic surveillance’’ certification criterion for the Proposed Voluntary Edition to permit alternate standards for the transmission of ambulatory syndromic surveillance data as a means of providing additional flexibility for EHR technology certification and for EPs attempting to meet the syndromic surveillance MU objective and measure. Since publication of the Proposed Rule we have heard from the CDC that some public health agencies have requested that the CDC reconsider developing an IG for HL7 2.5.1 as the HL7 2.5.1 standard is used by some public health agencies. With consideration of the request to CDC, our overall approach to this final rule as described in the Executive Summary, and to provide the most clarity for certification as possible, we are not removing or revising the current 2014 Edition ‘‘syndromic surveillance’’ certification criterion (§ 170.314(f)(3)) nor adopting a separate ‘‘syndromic surveillance’’ certification criterion for the Proposed Voluntary Edition. Rather, we have adopted an optional 2014 Edition ‘‘syndromic surveillance’’ certification criterion (§ 170.314(f)(7)) for the ambulatory setting. The optional 14 The ISDS Issue Report is available at https:// docs.google.com/spreadsheet/ ccc?key=0AlhELG407-6OdFVPa0ZjZXFjYnNVd0 tPSHRCRGF0WXc&usp=sharing. E:\FR\FM\11SER2.SGM 11SER2 tkelley on DSK3SPTVN1PROD with RULES2 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations certification criterion permits EHR technology, for the purposes of certification, to use any method or standard to electronically create syndrome-based public health surveillance information for electronic transmission. Consistent with the intent of our proposal, this will provide additional certification flexibility for EHR technology developers and flexibility for EPs attempting to achieve MU. We note that this approach does not affect the corresponding MU Stage 2 objective and measure.15 We agree with commenters that without specific IGs for the use of CDA and QRDA III for the transmission of ambulatory syndromic surveillance data, the standards are not constrained enough on their own to enable interoperable submissions. However, even before publication of the Proposed Rule, query-based standards were piloted and demonstrated in a few cases for ambulatory syndromic surveillance data, including through the QueryHealth initiative. These efforts and the use of query-based models continue and we expect the use of query-based models to grow among public health agencies. Therefore, we concluded that the best approach at this time was to adopt an optional ‘‘syndromic surveillance’’ certification criterion that permits EHR technology designed for the ambulatory setting to simply demonstrate that it can electronically create syndrome-based public health surveillance information for electronic submission (using any method or standard) to be certified to this criterion. This provides certification flexibility and potential EP flexibility as mentioned above, while also providing a path forward as described below. Because there is no current IG that supports ambulatory syndromic surveillance data submission using query-based standards, we have also included an optional set of data elements within this optional certification criterion to provide some additional specificity and to which EHR technology developers may choose to have their EHR technology certified. These data elements are: Patient demographics, provider specialty, provider address, problem list, vital signs, laboratory results, procedures, medications, and insurance. While the aforementioned data elements are optional for the purposes of demonstrating compliance to this certification criterion, if an EHR 15 MU2 Measure: Successful ongoing submission of electronic syndromic surveillance data from certified EHR technology to a public health agency for the entire EHR reporting period. VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 technology developer wishes to certify its EHR technology to this criterion as a whole, including the optional data set, the EHR technology would need to demonstrate that it can electronically produce syndromic surveillance information that contains all of the data elements. In other words, an EHR technology that could only produce half of the data elements would not be able to be certified to this optional portion of the criterion. The public health agencies and stakeholders that have piloted and continue to pilot query-based models for transmitting ambulatory syndromic surveillance data send all of the data elements identified above. Therefore, by identifying these data elements for certification, EHR technology developers will have clarity as to the data elements they should focus on for creating syndrome-based public health information submissions and will need to include to support query-based models now and in the future, including any potential certification requirements introduced through future rulemaking. The use of the QRDA III standard represents the response portion of a query-response model, but there currently are no mature standards for the query portion of the model of which we are aware. We intend to continue working with stakeholders on standards for both the query and response portions to support the electronic transmission of ambulatory syndromic surveillance data. We intend to gather more information regarding the implementation guidance provided by stakeholders that are currently piloting or using CDA or constrained QRDA III for ambulatory syndromic surveillance data transmissions to inform our consideration of what standards to propose in the future. This work will include confirming which data elements are commonly transmitted through these and other query-based models, such as the ones identified above and any other data elements that may also be typically sent using query-based approaches. Given our approach to this final rule as stated in the Executive Summary, we have not adopted the IG Release 1.9 for inpatient certification to either the current ‘‘syndromic surveillance’’ certification criterion or the optional ‘‘syndromic surveillance’’ certification criterion we have adopted in this final rule. We agree with comments that any issues or errors identified in Release 1.9 should be remedied before requiring the IG for adoption. We also recognize that the industry is working on Release 2.0 of the IG. Therefore, we will consider this feedback for future rulemaking concerning a ‘‘syndromic surveillance’’ certification criterion. PO 00000 Frm 00013 Fmt 4701 Sfmt 4700 54441 We also thank commenters for the input on the usefulness of QRDA Category I for query-based ambulatory syndromic surveillance and will consider this feedback for future rulemaking. Transport Methods (Formerly ‘‘Transmission’’) Certification Criteria As a result of our proposal to decouple content and transport capabilities from the ToC certification criteria and VDT certification criterion, we proposed to adopt three separate transport certification criteria. These three proposed transport certification criteria mirrored the specific transport capabilities identified within the 2014 Edition ToC certification criteria at § 170.314(b)(1) and (2). The first criterion mirrored the capability expressed at § 170.314(b)(1)(i)(A) and § 170.314(b)(2)(ii)(A) (i.e., Direct); the second mirrored the ‘‘optional’’ capability expressed at § 170.314(b)(1)(i)(B) and § 170.314(b)(2)(ii)(B) (i.e., Direct and XDR/XDM for Direct Messaging); and the third mirrored the ‘‘optional’’ capability expressed at § 170.314(b)(1)(i)(C) and § 170.314(b)(2)(ii)(C) (i.e., SOAP RTM and XDR/XDM for Direct Messaging). We stated for all three proposed certification criteria that we expected them to be tested similarly to how they are tested today except that only these capabilities would be tested. Comments. Commenters generally supported the separation of content and transport (as outlined in more detail under the ToC certification criterion above) and the inclusion of independent transport certification criteria in order to support our overall approach to decoupling content and transport capabilities. Some commenters believed the first three transport criteria (i.e., Direct, Direct and XDR/XDM for Direct Messaging, and SOAP RTM and XDR/ XDM for Direct Messaging) should be eligible for gap certification because each capability could be tested as part of the 2014 Edition ToC criteria. One commenter asked for clarification regarding the grouping of the proposed certification criteria. Specifically, the commenter asked if the transport criteria were separate and could be individually tested and certified. Response. We have revised the title of this category of certification criteria for clarity. We now refer to this category of certification criteria (§ 170314(h)) as ‘‘transport methods’’ instead of ‘‘transmission.’’ We believe this provides better attribution to the type of criteria and functionality that are included in this category. E:\FR\FM\11SER2.SGM 11SER2 tkelley on DSK3SPTVN1PROD with RULES2 54442 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations We appreciate the widespread support and feedback regarding the decoupling of content and transport requirements. We believe finalizing three, independent transport criteria will allow technology developers to build in the transport capabilities suited to their customers’ needs. Therefore, consistent with our earlier discussion related to the optional ToC certification criterion (§ 170.314(b)(8)), we have decided to adopt all three of the proposed transport capabilities (previously contained within the ToC certification criteria) in three separate certification criteria that can be individually tested and certified. For all three adopted criteria, we have removed the term ‘‘transmit’’ from the title of criteria and replaced the regulation text ‘‘electronically transmitted’’ in each criterion with ‘‘electronically sent and electronically received.’’ These changes provide clarity in two ways. They eliminate any confusion with the use of the term ‘‘transmit’’ (or ‘‘transmitted’’), which we used in the 2014 Edition Final Rule to mean only ‘‘send from one point to another’’ (77 FR 54168). Equally important, the changes clearly specify how these standards will be tested and certified, which is consistent with how these standards are currently tested and certified. The changes are also consistent with our expectations expressed in the Proposed Rule and recited above about testing and certification. As noted in the following section (III.A.3 ‘‘Gap Certification Eligibility Table for 2014 Edition Release 2’’), the certification criteria for Direct, Direct and XDR/XDM for Direct Messaging, and SOAP RTM and XDR/XDM for Direct Messaging are eligible for gap certification. We discuss each certification criterion in more detail in the following comments and responses. Comments. Some commenters asked that we identify one transport criterion as the minimum required for transport. The commenters noted that if one method of transmission were not required, vendors would be forced to support all transport methods. Response. As we explained in the preamble of the Proposed Rule, we seek to maintain the same policy we included in the 2014 Edition Final Rule—that in order for EPs, EHs, and CAHs to have EHR technology that met the CEHRT definition they would need to have EHR technology capable of performing transmissions in accordance with the primary Direct Project specification. We accentuated this policy by proposing to modify the Base VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 EHR definition to ensure that it reflected this policy, which we have finalized in this final rule. Thus, in response to these comments, we reiterate that the primary Direct Project specification is still the minimum required transport capability EPs, EHs, and CAHs will need to meet the CEHRT definition. Applicability Statement for Secure Health Transport Comments. Commenters widely supported the adoption of this certification criterion. One commenter noted that in the case of immunization information, Direct is a suboptimal transport method. Response. We appreciate the comments received on this certification criterion and have adopted this criterion as a new optional certification criterion at § 170.314(h)(1). We recognize that the primary Direct Project specification may not be the best fit for every type of transmission. However, we note that the standard is not required for public health transmissions. Applicability Statement for Secure Health Transport and XDR/XDM for Direct Messaging Comments. We did not receive any comments suggesting we not adopt this specific criterion. Response. We have adopted this criterion as a new optional certification criterion at § 170.314(h)(2). We note that the proposed regulation text in the Proposed Rule was not consistent with the Proposed Rule preamble in that it did not mirror the ‘‘optional’’ capability expressed at § 170.314(b)(1)(i)(B) and§ 170.314(b)(2)(ii)(B) (i.e., Direct and XDR/XDM for Direct Messaging). Rather, it only referenced the XDR/XDM for Direct Messaging standard. In what we are adopting in this final rule, we have now aligned the regulation text with our proposal by including references to both the XDR/XDM for Direct Messaging (§ 170.202(b)) and the Direct standard (§ 170.202(a)). SOAP Transport and Security Specification and XDR/XDM for Direct Messaging Comments. Commenters supported the adoption of this certification criterion. One commenter noted that this criterion would best support immunization information transmissions. Response. We appreciate the comments we received on this criterion and have adopted this criterion as a new optional certification criterion at § 170.314(h)(3). We note that the PO 00000 Frm 00014 Fmt 4701 Sfmt 4700 proposed regulation text in the Proposed Rule was not consistent with the Proposed Rule preamble in that it did not mirror the ‘‘optional’’ capability expressed at § 170.314(b)(1)(i)(C) and § 170.314(b)(2)(ii)(C) (i.e., SOAP RTM and XDR/XDM for Direct Messaging). Rather, it only referenced the SOAP RTM standard. In what we are adopting in this final rule, we have now aligned the regulation text with our proposal by including references to both the SOAP RTM standard (§ 170.202(c)) and the XDR/XDM for Direct Messaging (§ 170.202(b)). 3. Gap Certification Eligibility Table for 2014 Edition Release 2 ‘‘Gap certification’’ is defined 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. 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. In the Proposed Rule, we included a table (79 FR 10916) that provided a crosswalk of unchanged Proposed Voluntary Edition EHR certification criteria to the corresponding 2014 Edition EHR certification criteria. We provided corrections to this table in a notice published in the Federal Register on March 19, 2014 (79 FR 15282). We have provided a new table (Table 3) in this final rule because we have not adopted the full Proposed Voluntary Edition and have also made revisions to a proposed certification criterion that we are including in the 2014 Edition as part of Release 2 (i.e., ‘‘CPOE— laboratory’’ § 170.314(a)(19)). The table below provides a crosswalk of 2014 Edition Release 2 certification criteria that are eligible for gap certification using the test results of EHR technology previously certified to the 2014 Edition and 2011 Edition. E:\FR\FM\11SER2.SGM 11SER2 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations 54443 TABLE 3—GAP CERTIFICATION ELIGIBILITY FOR 2014 EDITION, RELEASE 2 EHR CERTIFICATION CRITERIA 2014 edition release 2 Regulation section Title of regulation paragraph § 170.314(a) (18). § 170.314(a) (19). § 170.314 (a)(20). § 170.314(f)(7)* § 170.314(h)(1) 2014 Edition Regulation section Optional—computerized physician order entry—medications. Optional—computerized physician order entry—laboratory. Optional—computerized physician order entry—diagnostic imaging. Optional—ambulatory setting only—transmission to public health agencies— syndromic surveillance. Optional—Applicability Statement for Secure Health. 2011 Edition Title of regulation paragraph Regulation section Title of regulation paragraph § 170.314 (a)(1). Computerized physician order entry. § 170.304(a); Computerized physician § 170.306(a). order entry. § 170.314(f)(3) Transmission to public health agencies—syndromic surveillance (ambulatory setting only). Transitions of care—receive, display, and incorporate transition of care/referral summaries.Transitions of care—create and transmit transition of care/referral summaries.. Transitions of care—receive, display, and incorporate transition of care/referral summaries Transitions of care—create and transmit transition of care/referral summaries.. Transitions of care—create and transmit transition of care/referral summaries. § 170.302(1) .. Public health surveillance (ambulatory setting only). Not applicable Not applicable. Not applicable Not applicable. Not applicable Not applicable. § 170.314(b) (1)(i)(A) and § 170.314(b) (2)(ii)(A). § 170.314(h)(2) Optional—Applicability Statement for Secure Health Transport and XDR/XDM for Direct Messaging. § 170.314(b) (1)(i)(B) and § 170.314(b) (2)(ii)(B). § 170.314(h)(3) Optional—SOAP Transport and Security Specification and XDR/XDM for Direct Messaging. § 170.314(b) (1)(i)(C) and § 170.314(b) (2)(ii)(C). * Gap certification does not apply for the optional data elements listed in § 170.314(f)(7). tkelley on DSK3SPTVN1PROD with RULES2 4. Base EHR Definition We proposed to include in the Base EHR definition (a foundational part of the CEHRT definition) the Proposed Voluntary Edition EHR certification criteria that corresponded 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, clinical decision support (CDS), CQMs, transitions of care, data portability, and privacy and security). Comments. We received a comment that supported the inclusion of the proposed CPOE certification criteria in the Base EHR definition because it would provide the potential for more flexibility and less burden for EPs, EHs, and CAHs in meeting the Base EHR definition. Response. We have not revised the Base EHR definition as proposed. However, we have revised the Base EHR definition to include the optional CPOE, ToC, and the Direct transport (§ 170.314(h)(1)) certification criteria adopted in this final rule. The inclusion of these certification criteria in the Base VerDate Mar<15>2010 20:03 Sep 10, 2014 Jkt 232001 EHR definition will, as noted by the commenter in relation to the CPOE certification criteria, offer flexibility and reduced burden in meeting the Base EHR definition for some EPs, EHs, and CAHs. B. ONC HIT Certification Program 1. Discontinuation of the Complete EHR We proposed to discontinue use of the Complete EHR definition as a regulatory concept and the certification of Complete EHRs beginning with the Proposed Voluntary Edition. As an alternative to the proposal, if we were to keep the Complete EHR concept and definition for editions of certification criteria beyond the 2014 Edition, we proposed to either continue the same policy of adopting an edition-specific Complete EHR (e.g., ‘‘2015 Edition’’ Complete EHR) or 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.’’ For the latter, we noted that ONC–ACBs PO 00000 Frm 00015 Fmt 4701 Sfmt 4700 would be responsible for issuing Complete EHR certifications that specify the edition the Complete EHR was certified to and that the information would be evident through listing on the Certified HIT Product List (CHPL). Comments. We received many comments from associations representing providers, consumers, and HIT developers as well as comments from numerous HIT developers. The overwhelming majority supported our proposal to discontinue the Complete EHR definition and Complete EHR certification for the reasons we specified in the Proposed Rule (recited below in the response). One association was neither for nor against our proposal, but was more concerned that providers have a clear understanding of what they are purchasing. In particular, the association stated that information outlining the product’s criteria should be readily apparent when purchasing the product and also available on ONC’s Web site. A few commenters suggested that we retain Complete EHR certification as an option for EHR technology developer and consumer purchasing. One of these commenters recommended that we tailor a Complete E:\FR\FM\11SER2.SGM 11SER2 tkelley on DSK3SPTVN1PROD with RULES2 54444 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations EHR certification by the MU Stage it would be associated with, while another suggested calling it a ‘‘Comprehensive EHR.’’ Response. We have finalized our proposal to discontinue the Complete EHR definition and Complete EHR certification. While we have not adopted the Proposed Voluntary Edition, this approach will apply for all future adopted editions of certification criteria as specified in § 170.501(b) (discussed in more detail under section III.B.2 ‘‘Applicability’’ of this preamble). To be clear, the discontinuation of the Complete EHR definition and Complete EHR certification will have no impact on current 2014 Edition Complete EHR certifications or in using a 2014 Edition Complete EHR to meet the current CEHRT definition. In regard to additional 2014 Edition Release 2 certification criteria, we have adopted them all as optional criteria and thus they do not impact the 2014 Edition Complete EHR definition. In the Proposed Rule (79 FR 10917– 10918), we explained our rationale for discontinuing the Complete EHR definition. We are reciting our rationale again here as we still believe these reasons hold true. Following the recitation of these reasons, with minor modifications due to the MU Flexibility Final Rule (79 FR 52910), we offer further rationale and responses to comments. (1) The Complete EHR definition initially was intended to support the original CEHRT definition established in the 2011 Edition Final Rule under § 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. The CEHRT definition based on EHR technology certification to the 2014 Edition (2014 Edition CEHRT definition) and Complete EHR definition no longer share the same symmetry. In fact, the 2014 Edition Complete EHR definition now exceeds the 2014 Edition 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 VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 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. However, some stakeholders believe incorrectly that their only regulatory option to meet the CEHRT definition is to adopt a certified Complete EHR when, under the CEHRT definition for FY/CY 2014 and subsequent years in § 170.102, they can use EHR technology (EHR Module(s)) 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 (§ 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, and 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 2014 Edition CEHRT definition. Consequently, by discontinuing the availability of the Complete EHR certification, the EHR technology market could be driven by EHR technology developers competing on the capabilities included in their PO 00000 Frm 00016 Fmt 4701 Sfmt 4700 EHR technology rather 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 new edition 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 following the structure of the 2014 Edition Complete EHR 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 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). As stated in the Proposed Rule, discontinuation of Complete EHR definition and certification does not affect EHR Module certification. In fact, as it stands now with 2014 Edition certification, an EHR Module certificate can be issued to an EHR technology that includes every certification criterion that is included in a Complete EHR certificate issued to an EHR technology (and even with the EHR Module certificate, the capabilities can be integrated in the same manner),16 but would not be given the ‘‘Complete EHR’’ designation. The discontinuation of the Complete EHR definition and certification will also help to address commenters’ concerns about clearly knowing what certification criteria an EHR technology is certified to because, unlike Complete EHR developers for their Complete EHRs, an EHR Module developer is required by regulation to specifically list in communications and marketing materials all the certification criteria to which the EHR technology was certified and for which it was issued an EHR Module certificate. 16 To note, the ONC HIT Certification Program does not include integration testing and certification of Complete EHRs or EHR Modules as that is left to the EHR technology developer and its customers. E:\FR\FM\11SER2.SGM 11SER2 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations Therefore, with only EHR Module certificates on the market, we believe it will be easier to know and compare the certification criteria to which they have been certified. Last, while we do not believe the use of the terms ‘‘Complete’’ or ‘‘Comprehensive’’ are appropriate for ‘‘labeling’’ EHR technology going forward, we will consider for our next rulemaking whether any other ‘‘labeling’’ for certified technologies could continue to make the scope of certification clearer. 2. Applicability We proposed to revise the ‘‘applicability’’ section (§ 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 Proposed Voluntary Edition and any subsequent edition of certification criteria adopted by the Secretary under subpart C. This proposal was consistent with our proposal to discontinue the use of the Complete EHR concept and Complete EHR certification beginning with the Proposed Voluntary Edition. Comments. We received two comments expressing agreement with our proposal. Response. We have finalized our proposal consistent with our decision to finalize the proposals to discontinue use of the Complete EHR concept and Complete EHR certification for any subsequent adopted edition of certification criteria. We have, however, finalized this proposal in a manner that accounts for our decision not to adopt the Proposed Voluntary Edition. Specifically, we have revised § 170.501(b) to read: ‘‘References to the term Complete EHR and Complete EHR certification throughout this subpart do not apply to certification in accordance with any edition of certification criteria that is adopted by the Secretary under subpart C after the 2014 Edition EHR certification criteria.’’ tkelley on DSK3SPTVN1PROD with RULES2 3. ONC Regulations FAQ 28 In ONC regulations FAQ 28,17 we provide guidance on the application of § 170.314(g)(1) and (g)(2) to the certification of Complete EHRs and EHR Modules. We state in FAQ 28 and in the 2014 Edition Final Rule (77 FR 54186) that ONC–ACBs can certify an EHR Module to either the 2014 Edition ‘‘automated numerator recording’’ certification criterion or the 2014 17 https://www.healthit.gov/policy-researchersimplementers/28-question-11-12-028. VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 Edition ‘‘automated measure calculation’’ certification criterion. To provide regulatory clarity, we proposed to revise § 170.550(f)(1) to specify this flexibility for the certification of EHR Modules to the 2014 Edition and proposed the same flexibility in § 170.550(g)(1) for MU EHR Modules certified to the Proposed Voluntary Edition ‘‘automated numerator recording’’ certification criterion and the ‘‘automated measure calculation’’ certification criterion. We also clarified that an EHR Module (or proposed ‘‘MU EHR Module’’ with regard to the Proposed Voluntary Edition) could be certified to only the ‘‘automated measure calculation’’ certification criterion (§§ 170.314(g)(2) or proposed 170.315(g)(2)) in situations where the EHR Module does not include a capability that supports a percentagebased MU objective and measure, but can meet the requirements of the ‘‘automated measure calculation’’ certification criterion (§§ 170.314(g)(2) or proposed 170.315(g)(2)). We noted that 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, we stated that § 170.550(f)(1) or (g)(1) would not be implicated or need to be applied. We proposed to revise § 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, which would implement the guidance provided in FAQ 28. In FAQ 28, we stated that EHR technology issued a 2014 Edition Complete EHR certification must be certified to § 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 § 170.314(g)(1) (even though it too was designated as a mandatory certification criterion) because a 2014 Edition Complete EHR would have demonstrated capabilities beyond those included in § 170.314(g)(1) by being certified to (g)(2). We proposed that if were to retain the Complete EHR concept for the Proposed Voluntary Edition, we would take the same approach for Complete EHRs as specified in FAQ 28 and in our proposed regulatory changes to § 170.314(g)(1). PO 00000 Frm 00017 Fmt 4701 Sfmt 4700 54445 Comments. We received a few comments supporting the continued requirement for Complete EHRs to be certified to the ‘‘automated measure calculation’’ certification criterion (§ 170.314(g)(2)). We received one comment supporting our proposal to revise § 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. Response. We have not finalized the proposals related to the Proposed Voluntary Edition because we have not adopted the Proposed Voluntary Edition. We have, however, finalized the proposals related to the 2014 Edition. We have designated the ‘‘automated numerator recording’’ certification criterion at § 170.314(g)(1) as an optional certification criterion, which will provide greater regulatory clarity for ONC–ACBs as they determine whether EHR technology meets the 2014 Edition Complete EHR definition and therefore must be certified to § 170.314(g)(2). Certification to § 170.314(g)(2) is required to meet the 2014 Complete EHR definition as it is a mandatory certification criterion. This approach is also supported by commenters. We have revised § 170.550(f)(1) to require ONC–ACBs to certify EHR Modules to either § 170.314(g)(1) or (2), rather than just requiring certification to § 170.314(g)(1). This will implement FAQ 28 guidance and flexibility as well as provide regulatory clarity. We also maintain our clarification and guidance included in the Proposed Rule related to an EHR Module being able to be certified to only the ‘‘automated measure calculation’’ certification criterion (§ 170.314(g)(2)) in situations where the EHR Module does not include a capability that supports a percentagebased MU objective and measure, but can meet the requirements of the ‘‘automated measure calculation’’ certification criterion. 4. Patient List Creation Certification Criteria In the Proposed Rule, we discussed how the 2014 Edition (and Proposed Voluntary Edition) ‘‘patient list creation’’ certification criterion includes 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 E:\FR\FM\11SER2.SGM 11SER2 54446 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations reminders’’) 18 and ‘‘generate lists of patients by specific conditions to use for quality improvement, reduction of disparities, research, or outreach,’’ respectively). We clarified that in situations where EHR technology is presented for certification to the 2014 Edition (and Proposed Voluntary Edition) ‘‘patient list creation’’ certification criterion and does not include a capability to support ‘‘patient reminders,’’ it would not need to be certified to the ‘‘automated numerator recording’’ certification criterion (§ 170.314(g)(1)) nor the ‘‘automated measure calculation’’ certification criterion (§ 170.314(g)(2)) for ‘‘patient reminders’’ percentage-based measure capabilities. Comments. We received a few comments supporting our clarification and guidance. An ONC–ACB further noted that, in its experience, there are only a ‘‘handful’’ of EHR technologies presented for certification for which this type of scenario would be applicable. Response. We appreciate commenters’ support and agreement with our clarification and guidance. While we have not adopted the proposed ‘‘patient list creation’’ certification criterion, our clarification and guidance remains applicable for the certification of EHR technology to the 2014 Edition ‘‘patient list creation’’ certification criterion (§ 170.314(a)(14)). As noted by the ONC–ACB, the clarification and guidance will be helpful in facilitating the proper certification of at least some EHR technology to the 2014 Edition ‘‘patient list creation’’ certification criterion. tkelley on DSK3SPTVN1PROD with RULES2 5. 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 International Organization for Standardization/ International Electrotechnical Commission (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, Guide 65. The ISO issued ISO/IEC 17065: 2012 19 (ISO 17065), which cancels and replaces Guide 65. 18 The MU measure for this objective is: More than 10 percent of all unique patients who have had 2 or more office visits with the EP within the 24 months before the beginning of the EHR reporting period were sent a reminder, per patient preference when available. 19 https://www.iso.org/iso/catalogue_ detail.htm?csnumber=46568. ISO slide presentation on 17065: https://www.iso.org/iso/ppt_presentation_ 17065.ppt. VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 that the ISO/IEC standards will be referred to as ‘‘ISO/IEC 17011,’’ ISO/IEC Guide 65,’’ and ISO/IEC 17065’’ when used in subpart E of Part 170. This approach is consistent with guidance from the Office of the Federal Register. Because ISO has replaced Guide 65 with ISO/IEC 17065, we proposed to revise § 170.503(b)(1) and (e)(2) to replace the references to Guide 65 with ISO 17065. For § 170.503(b)(1), we proposed that the change would be effective as of the effective date of this final rule. We noted that we anticipated that the effective date of this final rule would occur after we select an accreditation body as the ONC–AA for the next three-year term as ANSI’s 20 initial term expired in June 2014. Because of this, we noted that we would next need to assess applicants for ONC– AA status in early 2017 and by then we expected that any applicant would have experience evaluating the conformance of certification bodies to ISO 17065. For § 170.503(e)(2), we proposed to require compliance with ISO 17065 beginning in FY 2016 (in other words, as of October 1, 2015). We stated that 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 also proposed to revise our references to ISO/IEC standards 17011, 17065 and Guide 65 in § 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 § 170.599. This approach aligns with guidance we received from the Office of the Federal Register. Comments. We received comments from the ONC–AA and ONC–ACBs. The comments from these organizations specifically supported our proposals transition from Guide 65 to ISO 17065 and to remove the date reference for each standard. Response. We appreciate the comments of support for our proposals and also note that, as anticipated, an accreditation organization (ANSI) was selected to serve as the ONC–AA for a 3-year term that began in June 2014.21 Based on comments received and the rationale cited in the Proposed Rule, we have finalized revisions to § 170.503(b)(1) and (e)(2) as proposed. We have also removed the date references for the standards in § 170.503 as proposed. In regard to removing the dates, we have also revised § 170.599(b) to provide clear attribution to the version of the ISO/IEC standards we are referring to in § 170.503. More specifically, we identify in § 170.599 ONC has developed and administers the ‘‘ONC Certified HIT’’ certification and design mark (the ‘‘Mark’’).22 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 part 170, Subpart C; and has met all other required conditions of the ONC HIT Certification Program at 45 CFR part 170, Subpart E. We proposed to require ONC–ACBs to use the Mark in connection with HIT they certify under the ONC HIT Certification Program. More specifically, we proposed to revise § 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’’).23 In addition, we proposed to revise § 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. We noted that, in the event that the Terms of Use are revised or updated, compliance with the most recent version would be required. Comments. Commenters expressed agreement with our proposals citing to the consistency and clarity that a standard mark would provide in terms of identifying HIT certified under the ONC HIT Certification Program. One commenter requested clarification as to whether ONC–ACBs may also use their own mark in conjunction with the Mark, while another commenter requested clarity as to whether a HIT developer would be required to use the Mark. Response. We thank commenters for their support. We have finalized the revisions to § 170.523 as proposed. As noted by commenters and in the 20 American National Standards Institute, the ONC–AA. 21 https://www.hhs.gov/news/press/2014pres/05/ 20140513c.html. 22 https://www.healthit.gov/policy-researchersimplementers/onc-hit-certification-program. 23 https://www.healthit.gov/sites/default/files/hit_ certificationterms_of_use_final.pdf. PO 00000 Frm 00018 Fmt 4701 Sfmt 4700 6. ONC Certification Mark E:\FR\FM\11SER2.SGM 11SER2 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations tkelley on DSK3SPTVN1PROD with RULES2 Proposed Rule, the required use of a singular identifying mark will provide consistency in the recognition of HIT certified under the ONC HIT Certification Program and mitigate any potential market confusion for purchasers between HIT products certified under the ONC HIT Certification Program and those certified under any other program. While every ONC–ACB will be required to display the Mark on all certifications issued under the ONC HIT Certification Program in a manner that complies with the Terms of Use, they will also be able to use their own marks in conjunction with the Mark as specified in the Terms of Use under the ‘‘Accompanying Marks, Logos, and Symbols’’ section. This would also hold true for a HIT developer that chose to use the Mark. To this point and to address the requested commenter clarification, an HIT developer is not required to use the Mark. However, if they choose to use the Mark, then the ONC–ACB that issued the certification to the HIT developer would be required to ensure that the use of the Mark by the HIT developer is compliant with the Terms of Use. Our expectation is that HIT developers will want to use the Mark as a way of clearly and easily identifying that their product was certified under the ONC HIT Certification Program. C. Removal of the 2011 Edition EHR Certification Criteria From the CFR We proposed to remove the 2011 Edition EHR Certification Criteria and related standards, terms, and requirements from the CFR. Specifically, we proposed to remove 45 CFR 170.302, 170.304, and 170.306. We also proposed to remove the standards and implementation specifications found in 45 CFR 170.205, 170.207, 170.210, and 170.299 that are only referenced in the 2011 Edition EHR certification criteria. In regard to terms, we proposed to retire the definitions found in 45 CFR 170.102 related to the 2011 Edition, including ‘‘2011 Edition EHR certification criteria’’ and ‘‘Complete EHR, 2011 Edition.’’ In regard to requirements, we proposed to remove § 170.550(e) and any other requirement in subpart E, §§ 170.500 through 170.599 that is specific to the 2011 Edition and does not have general applicability to other editions of certification criteria. Comments. We received one comment supporting this ‘‘administrative update.’’ Response. In the Proposed Rule, we stated that EHR technology certified to 2011 Edition no longer meets the CEHRT definition. We also referenced VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 recent rulemakings by the HHS Office of Inspector General and CMS around donations of EHR items and services that cited our expectations to retire old/ no longer applicable certification criteria editions.24 As noted in the Proposed Rule, we believe this approach will streamline our requirements and ensure there is no regulatory confusion involving administration of ONC’s rules and the rules of other agencies’ such as CMS’s Physician Self-Referral Law exception and OIG’s Anti-kickback Statute safe harbor for certain EHR donations. Therefore, 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 removing the 2011 Edition EHR certification criteria and related standards, terms, and requirements from the CFR. Since publication of our Proposed Rule, we and CMS jointly issued a final rule entitled ‘‘Medicare and Medicaid Programs; Modifications to the Medicare and Medicaid Electronic Health Record Incentive Programs for 2014; and Health Information Technology: Revisions to the Certified EHR Technology Definition’’ (79 FR 52910). The final rule permits EPs, EHs, and CAHs to use EHR technology certified to the 2011 Edition or a combination of EHR technology certified to the 2011 Edition and 2014 Edition to meet the CEHRT definition in CY 2014 and FY 2014. To account for the permitted use of EHR technology certified to the 2011 Edition to meet the CEHRT definition in 2014 and the potential certification of EHR technology to the 2011 Edition through the end of CY 2014, the effective date for the removal of the 2011 Edition EHR certification criteria and related standards, terms, and requirements from the CFR will be March 1, 2015. D. Removal of the Temporary Certification Program From the CFR The temporary certification program sunset on October 4, 2012, and is no longer in existence (77 FR 54268). Accordingly, we proposed to remove from the CFR the associated regulations, consisting of subpart D (§§ 170.400 through 170.499). 24 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).OIG final rule ‘‘Medicare and State Health Care Programs: Fraud and Abuse; Electronic Health Records Safe Harbor Under the Anti-Kickback Statute’’ (78 FR 79202). PO 00000 Frm 00019 Fmt 4701 Sfmt 4700 54447 Comments. We received no comments on this proposal. Response. We are removing the temporary certification program regulations from the CFR on the effective date of this final rule. IV. Not Adopted Proposals This section of the preamble discusses proposals from the Proposed Rule that we have not adopted, including comments received on those proposals and our response to those comments. As noted in the Executive Summary, we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange; and administrative proposals (i.e., removal of regulatory text from the CFR) and proposals for the ONC HIT Certification Program that provide improvements. A. Not Adopted EHR Certification Criteria and Certification Criteria Proposals Applicability—§ 170.300 Section 170.300 establishes the applicability of subpart C—Certification Criteria for Health Information Technology. We proposed to revise paragraph (d) of § 170.300 to add in a reference to § 170.315, which would clarify which specific capabilities within a certification criterion included in § 170.315 have general applicability (i.e., apply to both ambulatory and inpatient settings) or apply only to an inpatient setting or an ambulatory setting. Comments. We did not receive any comments on this specific proposal. Response. As noted in the Executive Summary, we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. Therefore, we have not revised paragraph (d) of § 170.300 to add in a reference to § 170.315. The optional certification criteria that we have adopted in this final rule will be part of the 2014 Edition and are included in § 170.314, which is already referenced in paragraph (d) of § 170.300. Computerized Provider Order Entry— Medications We proposed to adopt for the Proposed Voluntary Edition a CPOE E:\FR\FM\11SER2.SGM 11SER2 54448 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations tkelley on DSK3SPTVN1PROD with RULES2 certification criterion specific to medication ordering. The proposed criterion was structured substantially similar to the 2014 Edition CPOE certification criterion, except it did not reference laboratory and radiology/ imaging orders. We did not request any specific public comments on this certification criterion. Comments. One commenter recommended that we add functionality that would allow health care providers to electronically report adverse events related to medications directly to manufacturers and the Food and Drug Administration (FDA). Another commenter suggested that when providers order medication, labs and radiology that providers electronically send a CDA formatted document to the patient, where the capability exists. Response. We appreciate these comments, but they are outside the scope of the proposed criterion. We have not adopted this certification criterion as part of the Proposed Voluntary Edition because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As discussed under section III.A.2 of this preamble, we have adopted this certification criterion without modification as a 2014 Edition optional certification criterion. Computerized Provider Order Entry— Laboratory We proposed to adopt for the Proposed Voluntary Edition a CPOE certification criterion specific to laboratory ordering. We proposed 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 (LOI).25 We also proposed to require the use of, at a minimum, the version of Logical Observation Identifiers Names and Codes (LOINC®) adopted at § 170.207(c)(2) (version 2.40) as the vocabulary standard for laboratory orders. Last, we proposed that laboratory orders must include all the information for a test requisition as specified at 42 CFR 493.1241(c)(1) through (c)(8). We stated that the use of these standards and compliance with these requirements should greatly 25 https://www.hl7.org/special/committees/ projman/searchableprojectindex.cfm?action=edit& ProjectNumber=922. VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 improve the interoperability of laboratory orders sent from ambulatory EHR technology to a laboratory and laboratory compliance with the Clinical Laboratory Improvements Amendments (CLIA). Comments. Commenters were generally supportive of adoption of interoperable laboratory standards, particularly the LOI IG, and aligning requirements with CLIA. Commenters did, however, express concern with the LOI IG, the use of LOINC® for all orders, and the lack of a proposal to adopt the Electronic Directory of Services (eDOS) IG. Commenters stated that the LOI IG was new, likely incomplete, and will require substantial updates over the next 12–18 months. Commenters suggested waiting for a more complete version of the LOI IG, including pilot testing of the IG. Commenters expressed considerable concern that without the eDOS IG it would be difficult to achieve optimal interoperability. Commenters stated that LOINC® does not cover all orderable tests and that testing and certification would need to accommodate this fact. Commenters suggested additional guidance was necessary for compliance with the proposed CLIA requirements. Response. We have not adopted this certification criterion as part of the Proposed Voluntary Edition because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As discussed under section III.A.2 of this preamble, we have adopted this certification criterion without modification as a 2014 Edition optional certification criterion. We first note that we did not propose to adopt the eDOS IG because it was our understanding that the eDOS IG was still undergoing revisions at the time the Proposed Rule was being drafted. We also understood that the LOI IG was fairly new and we appreciate the stakeholder feedback on potential concerns with the LOI IG. We also thank commenters for their insight related to the use of LOINC® for all laboratory orders. While we have not adopted the LOI IG at this time, we plan to reconsider it for adoption in our next rulemaking along with the eDOS IG. We believe the time between now and our next final rule will permit many of the concerns with these IGs to be sufficiently addressed. Overall, the work towards laboratory interoperability and electronic exchange shows great PO 00000 Frm 00020 Fmt 4701 Sfmt 4700 promise, including the work on the Lab Results Interface (LRI) IG, Electronic Laboratory Reporting to Public Health (ELR) IG and harmonization of all laboratory IGs. The adoption of these standards for the ONC HIT Certification Program could help facilitate laboratory interoperability and electronic exchange among providers, assist laboratories with CLIA compliance. and reduce provider burden with respect to the availability and use of the eDOS IG. As such, we plan to revisit these standards in future rulemaking. Computerized Provider Order Entry— Radiology/Imaging We proposed to adopt for the Proposed Voluntary Edition a CPOE certification criterion specific to radiology/imaging. The proposed criterion was structured substantially similar to the 2014 Edition CPOE certification criterion, except it did not reference medications and laboratory orders. We did not request any specific public comments on this certification criterion. Comments. A few commenters questioned the value of this certification criterion as is, while other commenters suggested that an appropriate IG be developed and adopted for this certification criterion. Response. We have not adopted this certification criterion as part of the Proposed Voluntary Edition because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As discussed under section III.A.2 of this preamble, we have adopted this certification criterion without modification as a 2014 Edition optional certification criterion. We will consider comments on the value of the certification criterion without any associated standards or IGs and whether there are any appropriate standards or IGs to adopt as part of future rulemaking. Drug-Drug, Drug-Allergy Interaction Checks We proposed a ‘‘drug-drug, drugallergy interaction checks’’ certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. However, we solicited comment on whether drugdrug interaction (DDI) or drug-allergy interaction (DAI) checks-capable EHR technology should be able to track E:\FR\FM\11SER2.SGM 11SER2 tkelley on DSK3SPTVN1PROD with RULES2 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations 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 sought 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. In addition, we sought comment on whether a DDI/DAI tracking capability should only track inaction or responses related to certain drug-drug and drugallergy reactions, such as only tracking DDI/DAI alerts that if missed or ignored would cause severe reactions in patients. Last, we sought comment on what factors, definitions, standards, and existing consensus should be considered in determining whether a likely DDI/DAI reaction should be considered severe. Comments. Responses from commenters varied. Some commenters expressed strong support for response tracking for DDI and DAI, and suggested that a certification criterion also include response tracking for other interactions, such as drug/lab, drug/diagnosis, food allergy, drug-gene, therapeutic duplication, and environmental allergy interactions. One commenter suggested that response tracking certification exist for CDS interventions in general. Of those commenters that opposed the inclusion of response tracking as a certification criterion, several themes surfaced. Some commenters noted that response tracking would be burdensome, require significant time and investment, and could conflict with existing system configuration settings already designed for tracking DDI/DAI provider responses. Other commenters noted that response tracking functionality should not be included in a certification criterion and should be developed in the private sector according to the needs of individual providers and their health IT developers. A few commenters noted that response tracking could add an additional layer of alerting and impact provider workflow. A few others noted that response tracking should apply specifically to active alerts and should not apply to passive alerts. A few commenters noted that response tracking is not appropriate for an EHR system and that such information is stored and tracked within VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 Risk Management Information Systems (RMIS) for liability purposes and for analysis related to efforts to minimize the risk of future adverse events. We received a number of specific comments on the scope of response tracking. Commenters who supported response tracking noted the value such tracking provides to quality measurement, the improved usefulness of a DDI/DAI alert criterion that would result from response tracking, and the importance of such tracking being automated. One commenter noted that response tracking should track whether the DAI/DAI alert is ‘‘displayed’’ and not whether it is ‘‘viewed,’’ which the commenter suggested would impact the provider workflow by requiring provider action. Others noted that in addition to tracking the response of a provider, the factors that may have impacted a provider response would be important to track—such as relevant patient factors or system construction factors that can influence a provider’s reaction to a specific alert. A similar concern was raised by another commenter who stated that provider response only provides part of the information needed, and noted that whether the provider is a seasoned health care professional or less experienced is an example of corollary information that could impact whether an ignored DDI/DAI alert is a concern. We received a variety of comments on who should be able to review the responses of providers and who should be able to adjust tracking configuration. Some commenters noted that in order for this proposal to be operational and, if not already part of existing security protocols, EHR vendors may need to implement new security classes to control viewing privileges related to alerts. Some commenters noted that adjustment of the tracking configuration should be done by the care team and members of the ordering team, while other commenters noted that the ability to adjust configuration or review the response tracking results should be limited to a select few. Many commenters stated that the decision on who should be able to adjust the tracking configuration should be determined by the provider or the organization. One commenter stated that EHR systems also should allow an administrator to modify the workflow that a provider must take when certain DDI/DAI alerts appear. As part of the request for comment, we asked whether EHR systems should be able to track when an adverse event occurs for a DDI/DAI alert that is ignored. Many commenters expressed concern regarding adverse event PO 00000 Frm 00021 Fmt 4701 Sfmt 4700 54449 tracking. Some commenters stated that significant development would be required to enable this capability in EHR systems. Other commenters stated that the number of factors that can contribute to an adverse event would inhibit the usefulness of such a criterion. Conversely, we heard from several commenters that adverse event reporting related to DDI/DAI alerts plays an important role. Some commenters noted that providers should be able to make reports directly to manufacturers and the FDA about adverse events associated with medications. One commenter stated that in order for this criterion to be useful, an approach to adverse events similar to the Vaccine Adverse Event Reporting System would be needed. Regarding what factors, definitions, standards, and existing consensus should be considered in determining whether a likely DDI/DAI reaction should be considered severe, some commenters noted that standard vocabularies should be used for exchanging drug-allergy information and that the DDI/DAI terminology should be standardized. Other commenters opposed limiting tracking to only DDI/DAI that are considered severe and suggested that the proposed tracking should apply to all DDI/DAI because there is little consensus on what characterizes a severe reaction. Another commenter stated that in lieu of defining the term ‘‘severe,’’ the EHR technology developer or DDI/DAI content provider should define the term. Another commenter stated that any life threatening interaction should be considered severe. A few commenters stated that in the case of medication allergies, an assessment of severity would not be appropriate. Rather, a ‘‘criticality assessment’’ should be used. We also received several comments on how to improve any future response tracking certification criterion. One commenter stated that we should consider how to leverage patientgenerated health data to inform drug interaction and intolerance-related notifications (including over-thecounter medications). Another commenter suggested that compendia information should be updated monthly to ensure the efficacy of DDI/DAI alerts, which the commenter suggested would help ensure that providers are accessing up-to-date information about allergies and warnings, and would ensure that the list of FDA-approved treatments is current. A few commenters stated that pharmacists can play an important role in DDI/DAI functionality. These E:\FR\FM\11SER2.SGM 11SER2 54450 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations tkelley on DSK3SPTVN1PROD with RULES2 commenters stated that pharmacists should be able to review data collected by DDI/DAI response tracking, noting that pharmacists can help improve the DDI/DAI alert workflow by minimizing provider alert fatigue as well as mitigate against future adverse events through review of adverse outcomes. One commenter stated that pharmacy standards development organizations should be involved in the development of standards for any future response tracking certification criterion. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition ‘‘drug-drug interaction, drug-allergy interaction’’ certification criterion. We will, however, consider all comments regarding response tracking of DDI/DAI alerts for future rulemaking concerning a ‘‘drug-drug interaction, drug-allergy interaction’’ certification criterion. Demographics We proposed a ‘‘demographics’’ certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. The criterion included a requirement that EHR technology designed for the inpatient setting be capable of enabling a user to electronically record, change, and access the ‘‘date of death.’’ We previously included the capability to access the date of death as part of the 2011 Edition ‘‘demographics’’ certification criterion and inadvertently omitted it from the 2014 Edition. We also proposed to adopt a new preferred language standard because 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, we noted that 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 proposed three options for which we solicited public comments: The full ISO 639–2, ISO 639–3, or Request for Comments (RFC) 5646 to be the preferred language standard for the proposed VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 ‘‘demographics’’ certification criterion. To implement this proposal, we proposed to modify the regulatory text hierarchy in § 170.207(g) to designate the standard referenced by the 2014 Edition ‘‘demographics’’ certification criterion at § 170.207(g) to be at § 170.207(g)(1). Comments. We received a few comments on our proposal related to ‘‘date of death’’ stating that there was value in such information, but that commenters were unaware of any EHR technology developers certified to the 2011 Edition who removed this capability. We received comments on the preferred language for the ‘‘demographics’’ certification criterion advocating for: No change in the standard, the full ISO 639–2, ISO 639– 3, and RFC 5646. Commenters representing consumer groups and patients advocated for the inclusion of a standard that covered all languages and dialects. A commenter noted that, in California, both Hmong and Cantonese are Medicaid ‘‘threshold languages,’’ requiring additional language assistance services from Medicaid providers. Many commenters questioned the relative benefit of changing the standard (a few more languages) in relation to the cost and burden of switching standards. Commenters also emphasized the need for standards to have backwards compatibility with already adopted standards and not conflict with industry standards already adopted for the same purpose, such as those included in the Consolidated CDA and National Council for Prescription Drug Programs (NCPDP) standards. Response. We have not adopted a ‘‘demographics’’ certification criterion. The insightful comments we received on the preferred language standard necessitate further evaluation of whether the preferred language standard should be changed, including assessment of the compatibility and alignment of alternative standards with already adopted standards and additional cost-benefit analysis of any potential change in the adopted preferred language standard. Further, based on comments, there appears to be no need to adopt a revised ‘‘demographics’’ certification criterion that simply includes the ‘‘date of death’’ functionality. In future rulemaking that may address the ‘‘demographics’’ certification criterion, we will reconsider the need for specifically including functionality related to ‘‘date of death.’’ We will also consider comments we received on preferred language standards and our subsequent research on the matter. PO 00000 Frm 00022 Fmt 4701 Sfmt 4700 Vital Signs, Body Mass Index (BMI), and Growth Charts We proposed a ‘‘vital signs, body mass index, and growth charts’’ certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. However, we solicited comment on whether to require EHR technology to record vital signs in standardized vocabularies (e.g., LOINC®, Systemized Nomenclature of Medicine Clinical Terms (SNOMED CT®), and The Unified Code of Units of Measure (UCUM)). We also solicited comments on two approaches if EHR technology were to be required to record vital signs in standardized vocabularies: Option 1: Require EHR technology to record vital signs in standardized vocabularies natively within the EHR; Option 2: Require EHR technology to record vital signs in standardized vocabularies only when data was exchanged. Comments. The majority of commenters supported leaving this certification criterion unchanged and suggested waiting until the next edition to propose any changes. A commenter recommended linking weight information to drug formularies in order to assist licensed clinicians in selecting the appropriate dosage. Commenters also suggested that the calculation for creatinine clearance should appear in the header along with the BMI for the purposes of patient safety and proper dosing of medications. Another commenter recommended standardizing the use of international BMI as risk of health conditions may vary by race or ethnicity. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition ‘‘vital signs, body mass index, and growth charts’’ certification criterion. We will, however, consider comments regarding support for medication dosing and use of international BMI references for future rulemaking concerning a ‘‘vital signs, body mass index, and growth charts’’ certification criterion. We clarify that the comment solicitation regarding standardized vocabularies and E:\FR\FM\11SER2.SGM 11SER2 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations tkelley on DSK3SPTVN1PROD with RULES2 options for recording vital signs within the EHR was intended to inform a future edition of certification criteria, not the Proposed Voluntary Edition. Therefore, we will also consider the comments received on this topic as we develop proposals for future rulemaking. Problem List We proposed a ‘‘problem list’’ certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion. Comments. The majority of commenters supported an unchanged criterion. One commenter suggested removing this criterion in future editions because lists in of themselves have no value, but the commenter noted that lists are useful within the context of CQMs, ToC, and VDT certification criteria. A few commenters stated that they support the use of SNOMED CT® coding for this criterion and not the use of International Classification of Diseases-10 (ICD–10) as an additional coding system because its use would require more mappings and added complexity when using the Consolidated CDA templates. One commenter recommended adopting the most recent releases of SNOMED CT® (International July 2013 and US Extension September 2013). Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition ‘‘problem list’’ certification criterion. We will, however, consider feedback suggesting that this criterion is unnecessary in of itself for future rulemaking. In regard to comments on ICD–10, as we stated in the 2014 Edition Final Rule, we believe SNOMED CT® is more appropriate than ICD–10 for clinical purposes and provides greater clinical accuracy (77 FR 54210). Therefore, it was adopted for the 2014 Edition ‘‘problem list’’ certification criterion. We confirm that the 2014 Edition ‘‘problem list’’ certification criterion requires the use of the SNOMED CT® July 2012 International Release and VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 March 2012 US Extension as a minimum standard. Regarding the comment recommending that we adopt the updated SNOMED CT® versions, we will reassess whether a newer version of the minimum standard should be adopted in future rulemaking. As we stated in the 2014 Edition Final Rule, based on our experience, newer versions of the ‘‘minimum standards’’ code sets that we have adopted are issued more frequently than our current process can reasonably accommodate. We do not believe that permitting EHR technology to be upgraded and certified to newer versions of these code sets would normally pose an interoperability risk, and therefore we allow use of a newer version voluntarily for certification without adversely affecting the EHR technology’s certified status unless the Secretary specifically prohibits the use of a newer version (77 FR 54268). Thus, EHR technology may be certified to newer versions of SNOMED CT®. Medication List We proposed a ‘‘medication list’’ certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion. Comments. The majority of commenters supported an unchanged criterion. One commenter suggested removing this criterion in future editions because lists in of themselves have no value, but the commenter noted that lists are useful within the context of CQMs, ToC, and VDT certification criteria. A few commenters stated that medications can come from a number of sources, including over-the-counter, samples, and alternative medicines. These commenters recommended that a medication list include the most complete list possible to help minimize patient safety risks. One commenter stated that the FDA is working to implement requirements in the Drug Supply Chain Security Act regarding standards for the interoperable exchange of information for tracing human, finished, and/or prescription drugs. The commenter recommended that we be aware of these efforts and align current and future EHR requirements with any future FDA requirements for standards-based identification of prescription drugs. Another commenter recommended that EHR technology be able to track DDI/ DAI checks based on a patient’s medication list. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary PO 00000 Frm 00023 Fmt 4701 Sfmt 4700 54451 Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition ‘‘medication list’’ certification criterion. We will consider feedback suggesting that this criterion is unnecessary in of itself for future rulemaking. We will also consider comments regarding the FDA’s work to implement requirements in the Drug Supply Chain Security Act, EHR support of DDI/DAI checks, and the definition and inclusion of types of medications for future rulemaking. Medication Allergy List We proposed a ‘‘medication allergy list’’ certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. Comments. The majority of commenters supported an unchanged criterion. One commenter suggested removing this criterion in future editions because lists in of themselves have no value, but the commenter noted that lists are useful within the context of CQMs, ToC, and VDT certification criteria. Many commenters recommended that the medication allergy list should include other types of allergies and intolerances, including food and environmental allergies. One commenter stated that the FDA is working to implement requirements in the Drug Supply Chain Security Act regarding standards for the interoperable exchange of information for tracing human, finished, and/or prescription drugs. The commenter recommended that we be aware of these efforts and align current and future EHR requirements with any future FDA requirements for standards-based identification of prescription drugs. Another commenter recommended that EHR technology be able to track DDI/ DAI checks based on a patient’s medication allergy list. One commenter recommended the development of an ‘‘idealized’’ interoperable allergy value set that would encompass the same terminology code base and support documenting patient allergies and drug sensitivities. This commenter was concerned that currently active patient medication allergy and drug sensitivities are dominated by the use of multiple proprietary code sets. The commenter E:\FR\FM\11SER2.SGM 11SER2 54452 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations tkelley on DSK3SPTVN1PROD with RULES2 stated that codified allergy and drug sensitivity information is commonly exchanged as free-text or when converted to interoperable code sets, the original meaning of the documented allergy is lost. The commenter stated that the National Library of Medicine (NLM)’s RxNorm source vocabulary concepts and cross-referenced vocabulary terms best meet the characteristics of the ‘‘idealized’’ allergy value set. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition ‘‘medication allergy list’’ certification criterion. We will consider feedback suggesting that this criterion is unnecessary in of itself and comments regarding the FDA’s work to implement requirements in the Drug Supply Chain Security Act for future rulemaking. We note that we solicited specific feedback on vocabularies to code medication allergies and intolerances for a future edition of certification criteria and thank the commenters for their detailed feedback and recommendations on these topics. We will take these comments into consideration for future rulemaking. Clinical Decision Support (CDS) We proposed a ‘‘clinical decision support’’ certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion in several ways. First, we proposed to incorporate the guidance we provided in FAQ 39 26 that EHR technology certified to the CDS criterion must demonstrate the capability to use at least one of the more specific data categories included in the ‘‘demographics’’ certification criterion (§ 170.315(a)(5)) (e.g., the sex or date of birth). We also proposed to incorporate guidance we provided in FAQ 34 27 to clarify that the CDS criterion would not require compliance with the Infobuttonenabled capability for vital signs or medication allergies data. Additionally, 26 https://www.healthit.gov/policy-researchersimplementers/39-question-04-13-039. 27 https://www.healthit.gov/policy-researchersimplementers/34-question-12-12-034. VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 we proposed to discontinue referencing ‘‘laboratory values/results’’ data as stakeholder feedback indicated that the Infobutton standard cannot support this specific data. We proposed to include and adopt the HL7 Implementation Guide: ServiceOriented Architecture Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain, Release 1, August 2013 (at § 170.204(b)(3)) in place of the older version referenced by the 2014 Edition certification criterion. We proposed to adopt two new IGs from the Health eDecisions (HeD) S&I Framework initiative that support shareable CDS. The first IG defines requirements for the contents of ‘‘CDS Knowledge Artifacts’’ 28 for event condition action rules, order sets, and documentation templates (HL7 Implementation Guide: Clinical Decision Support Knowledge Artifact Implementation Guide, Release 1 (January 2013) (‘‘HeD standard’’)). In addition to proposing to adopt this IG, we proposed to require EHR technology be able to electronically process a CDS artifact in the HeD standard. The second IG defines SOAP and REST web interface requirements needed to send patient data and receive CDS guidance when a request for clinical guidance is made to a CDS guidance supplier (HL7 Decision Support Service Implementation Guide, Release 1, Version 1 (December 2013)). We also proposed 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 the HeD proposals, we solicited comment on what we should focus on for testing and certification of CDS Knowledge Artifacts, decision support services, and user experience to-date with implementing the HeD standards. Comments. Commenters overwhelmingly supported our proposed approach in FAQ 39 to require that EHR technology certified to a CDS criterion must demonstrate the capability to use at least one of the more specific data categories included in the ‘‘demographics’’ certification criterion (§ 170.315(a)(5)) (e.g., the sex or date of birth). Some commenters noted that our FAQs have been previously issued and 28 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. PO 00000 Frm 00024 Fmt 4701 Sfmt 4700 that most EHR technology developers have already implemented the policy clarifications offered by the FAQs. Therefore, the commenters stated that there is no added value in codifying the FAQs. Commenters also overwhelmingly supported the proposed approach in FAQ 34 to not require adherence to the Infobutton standard for medication allergies or vital signs. They also supported our proposal to not require adherence to the Infobutton standard for laboratory test values/results. A few commenters indicated that a more recent version of the Infobutton standard (Release 4 of the HL7 Infobutton URL-based Implementation Guide) does support laboratory test values/results. We received support to adopt the updated HL7 Implementation Guide: Service-Oriented Architecture Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain, Release 1, August 2013. Commenters also recommended that we do not discontinue referencing the Infobutton URL-Based IG (HL7 Version 3 Implementation Guide: URL-Based Implementations of the Context-Aware Information Retrieval (Infobutton) Domain). We received mixed feedback on the proposals to adopt the HeD standards for the two use cases. Some commenters supported adoption of the HeD standards in the Proposed Voluntary Edition, while others cautioned that the standards are immature and not welltested. Those in support of adoption contended that providers and patients would benefit from standardized CDS that could help providers make informed decisions about their patients’ care. Commenters also stated that adopting a standard would lessen the implementation burden on providers as CDS has normally been customized for each EHR system. A few organizations commented that they have already successfully piloted the HeD standards and are in production with a number of groups. Thus, they stated that the standards were mature and tested enough to require as part of voluntary certification. A few commenters suggested further development of diagnostic imaging CDS and alignment with clinical recommendations for immunizationbased CDS. One commenter recommended that providers be able to view the HIT developer, bibliographic citation, source of funding, and release/ revision date of a CDS rule for full transparency. Other commenters noted that the regulation text language of the proposed CDS certification criterion was E:\FR\FM\11SER2.SGM 11SER2 tkelley on DSK3SPTVN1PROD with RULES2 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations unclear and that the regulation text could be improved with more specificity. The majority of commenters who opposed the HeD proposals expressed concern about the HeD standards immaturity and lack of testing. Some also argued that the standards would still be too immature to propose for the next edition of certification criteria. To support their claim, many pointed to the work of the S&I Clinical Quality Framework (CQF) initiative to harmonize and update HeD with standards for CQMs (e.g., the Health Quality Measures Format standard (HQMF)). Commenters were concerned that EHR technology developers would have to significantly upgrade their systems once the harmonized HeD and HQMF standards become available and that the amount of rework was not worth the short-term benefit. Some commenters stated that market demand should drive the standards and technology for shareable CDS rather than regulation. One commenter suggested that the two HeD use cases should be evaluated separately and not lumped together as the user experience to date may be different between the two. For testing and certification, many commenters recommended a focus on a few simple and/or high impact or high clinical value Knowledge Artifacts and decision support services to simplify the development, testing, and certification processes. For example, one commenter recommended focusing testing for the first use case on event action condition rules as the commenter thought these are the most common type of Knowledge Artifact and most tested. A few commenters recommended that we and CMS consider allowing successful pilot testing of the HeD standards to count toward meeting MU requirements. Last, some commenters noted at least one case where an EHR accesses a CDS service based on the HeD standards outside of the EHR and recommended allowing the CDS service to be external to the EHR. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. We agree with commenters that our issued FAQs have addressed earlier concerns and that most EHR developers have already implemented the policy VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 clarifications offered by the FAQs. Therefore, there is no added value in codifying the FAQs at this point in time. There is also no substantial value in adopting a criterion solely with an updated Service-Oriented Architecture IG when, as commenters noted, there is a new URL-based IG that we should also consider for adoption. We will consider the comments regarding the updated Infobutton Service-Oriented Architecture IG and updated Infobutton URL-Based IG for future rulemaking activities and appreciate the detailed responses commenters provided. To clarify, we did not propose to remove the Infobutton URL-Based IG (at § 170.204(b)(1)) from the 2014 Edition CDS certification criterion. Rather, we proposed to include the updated Service-Oriented Architecture IG as part of the voluntary proposed CDS certification criterion that we have not adopted. We also agree with commenters that more deliberation and clarity is needed regarding the HeD proposals. We will consider the comments on HeD standards maturity, appropriate use cases, and testing, as well as comments suggesting improved clarity is needed in the CDS certification criterion regulatory text in developing future proposals for rulemaking. Electronic Notes We proposed an ‘‘electronic notes’’ certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. We included in the proposed certification criterion a capability to search for information across separate notes within EHR technology rather than just within one particular note. We stated that this expanded requirement was intended to reduce the time providers spend looking for specific patient information and noted that the requirement to search across notes was not limited to a specific method. In addition to this proposal, we requested comments regarding: Whether the proposed functionality should extend to all patient electronic notes stored in the EHR or just to a specific patient’s electronic notes or specific types of patient notes; whether we should wait to include the proposed functionality in a future edition of certification criteria; and whether additional metadata should be required as part of electronic notes (such as the HL7 R2 header). We also asked for health care provider opinions on whether the availability of the proposed 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 PO 00000 Frm 00025 Fmt 4701 Sfmt 4700 54453 widespread that it would be unnecessary to require it as a condition of certification. Comments. We received comments, including those from provider organizations, expressing support for expanding the search functionality both across a patient’s notes and across all patients’ notes in the EHR as a means of improving provider usability. We also received comments recommending that we not expand the search capability. These commenters argued that the functionality is not required for participation in a particular government program (e.g., the EHR Incentive Programs), it could stifle innovation, and market-driven approaches are sufficient to determine if additional search capabilities are essential or not. Some commenters supported including enhanced search functionality in the proposed certification criterion, while others thought we should wait for a future edition. A few comments supported metadata inclusion with the electronic note, while most comments saw no value in mandating the inclusion of metadata. Response. We have not adopted the proposed certification criterion. Based on comments, we believe further evaluation is necessary as to whether an enhanced search capability should be included in an ‘‘electronic notes’’ certification criterion and for what purpose the certification of any enhanced search capability would serve. We will consider the comments received in developing proposals future rulemaking. Drug Formulary Checks We proposed a ‘‘drug formulary checks’’ certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. However, we solicited public comment on whether we should leave the criterion as-is (flexible and without reference to a standard) or if it would be appropriate for us to adopt a standard in the Proposed Voluntary Edition certification criterion for which compliance would be required. In the 2014 Edition Final Rule, we stated it was necessary to require the use of a particular standard for certification as our certification criterion was flexible and permitted EHR technology to access and store external drug formularies in support of MU. As described in more detail in the Proposed Rule (79 FR 10892), CMS recently finalized a proposal to recognize NDPDP Formulary and Benefit Standard v3.0 as a backwards compatible version of NCPDP Formulary and Benefit Standard 1.0 for E:\FR\FM\11SER2.SGM 11SER2 54454 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations tkelley on DSK3SPTVN1PROD with RULES2 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 (78 FR 74787–74789).29 As such, we stated in the proposed rule that it was an opportune time to solicit comment on whether to adopt a particular standard for the drugformulary checks criterion. We also noted the NCPDP Formulary and Benefit Standard v.4.0’s 30 potential limitations as discussed by the HITSC, including that the version does not support expanded use cases such as real-time benefit checks.31 Thus, we also solicited comment on whether there are other standards or solutions (e.g., NCPDP Telecommunication Standard) that could be used in conjunction with or in place of the NCPDP Formulary and Benefit Standard to address the potential limitations or expanded use cases identified by the HITSC. Comments. We received mixed comments regarding the proposal to adopt a standard (namely the NCPDP Formulary and Benefit Standard v3.0) for the proposed certification criterion. Some commenters supported adopting the NCPDP Formulary and Benefit Standard v3.0 (‘‘v3.0’’) in this rule, but most of these commenters recommended its adoption for the next edition of certification criteria. Those in support of adopting v3.0 noted the potential to reduce file sizes, which is beneficial when checking thousands of drug formularies on a daily basis. Many recommended that we should also accept test results from the current Surescripts e-prescribing certification without additional testing requirements. Some commenters were concerned about known problems with v3.0, and pointed to the NCPDP Formulary and Benefit Standard v4.0 (‘‘v4.0’’), which may fix some of these known problems. Other commenters were concerned about rework if we required v3.0 in the proposed certification criterion followed by requiring v4.0 in the next edition. One commenter stated that v4.0 is too 29 CMS originally proposed retiring version 1.0 on July 1, 2014, but, in response to comment, subsequently decided to postpone the retirement date to March 1, 2015, to allow the industry adequate time to implement the necessary changes and testing to implement version 3.0 (78 FR 74789). 30 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 adopted v.3.0 (77 FR 74787–74789), which includes substantive changes from previous versions. 31 The HITSC has discussed these potential limitations. Please refer to 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 VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 unstable to require for certification at this point. Some commenters also stated that the industry should determine the EHR’s drug formulary features and that we should not be prescriptive in naming a particular standard for adherence. One ONC–ACB noted that, in their experience, the current drug-formulary check criterion is considered an ‘‘easy’’ pass during the certification process. The test procedure requires EHRs to simply show formulary query results, and therefore the commenter recommended that we consider expanding the test procedure to capture more of the real-world setup of the formulary at the patient or practice level. However, the ONC–ACB noted that this capability may be working fine and may not need further changes as they have never received any surveillance complaints regarding formulary features of certified EHR technologies. Most commenters were in support of the expanded use case for real-time, patient-level formulary benefit checking. However, we received mixed opinions on the appropriateness of leveraging the NCPDP Telecommunication Standard in conjunction with the NCPDP Formulary and Benefit Standard v3.0 for this expanded use case. One commenter stated that some of the issues found with the NCPDP Formulary and Benefit Standard are due to payer implementations rather than issues with the standard itself. The commenter recommended that we review an NCPDP-authored white paper describing how payers and vendors should implement the Formulary and Benefit Standard for maximum benefit.32 Some commenters stated that it was inappropriate to use the NCPDP Telecommunication Standard for realtime, patient-level benefit checking as it was not developed with that use case in mind. Rather, it was developed to respond with coverage information for a pre-selected medication, not a complete range of treatment options. Additionally, commenters opined that use of the NCPDP Telecommunication Standard could result in delays, workflow issues during provider ordering, and additional EHR performance issues because the standard can take several minutes to return a response. In addition to the NCPDP Telecommunication Standard, commenters suggested that we consider the pros and cons of additional 32 https://www.ncpdp.org/Education/Whitepaper ‘‘Challenges and Opportunities for Stakeholders Regarding ePrescribing Technologies and Formulary Compliance’’. PO 00000 Frm 00026 Fmt 4701 Sfmt 4700 standards that could be leveraged for real-time benefit checking. These standards include the ASC X12/ 005010X279 Health Care Eligibility Benefit Inquiry and Response (270/271) standard and the Proposed Real Time Benefit Check (RTBC) transaction based on a previous version of NCPDP SCRIPT standard (also referred to by some commenters as the Surescripts RealTime Benefit Check standard). Commenters also referred to different versions of the NCPDP Telecommunications Standard (e.g., B1 (Billing), D1 (Pre-termination of Benefits), D.0). One commenter recommended that as we evaluate alternative standards for real-time benefit checking, we should also consider protections to ensure that direct communication between pharmacy benefit managers and providers does not lead to unwanted advertising or pop-up messaging intended to influence the prescription decision of a health care professional at the point of care. A few commenters also recommended that we consider proposals for automated electronic prior authorization of medications to allow a prescriber to initiate prior authorization electronically as part of future rulemaking. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. We will consider comments regarding the pros and cons and maturity of the NCPDP Formulary and Benefit Standard v3.0 and v4.0 for future rulemaking. We will also examine whether we can learn from and/or leverage the processes of existing certification programs as well as improve the test procedure for this certification criterion as part of future rulemaking. We thank commenters for their detailed responses about specific standards for the expanded use case of real-time, patient-level formulary and benefit checking, and will continue to examine the pros and cons of each to inform our future rulemaking. We will consider these comments and comments encouraging adoption of standards for electronic prior authorization for future rulemaking. Additionally, as part of our continued work, we will seek to understand the differences among the versions of the NCPDP Telecommunication Standard and E:\FR\FM\11SER2.SGM 11SER2 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations between the RTBC transaction with the Surescripts Real-Time Benefit Check standard. As to the comment suggesting that we prohibit unwanted advertising or pop-up messaging in communications between providers and pharmacy benefit managers, we believe this request falls outside the scope of the ONC HIT Certification Program. tkelley on DSK3SPTVN1PROD with RULES2 Smoking Status We proposed a ‘‘smoking status’’ certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion. Comments. We received comments expressing support for this certification criterion as unchanged. A few commenters noted that there is misalignment with the code sets adopted for the 2014 Edition and proposed ‘‘smoking status’’ certification criteria and the Consolidated CDA Release 2.0 and e-clinical quality measures (eCQMs). A few commenters also suggested that we consider requiring the capture of additional forms of tobacco use, such as smokeless tobacco and betel nut use. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition ‘‘smoking status’’ certification criterion. We note that we have also not adopted the proposed Consolidated CDA Release 2.0 as discussed under the ToC certification criterion in this section (IV.A). We will, however, take the comments about expansion of the smoking code set and alignment with the Consolidated CDA Release 2.0 and eCQMs under consideration for future rulemaking concerning a ‘‘smoking status’’ certification criterion and the Consolidated CDA standard. Image Results We proposed an ‘‘image results’’ certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion. VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 Comments. We received a small number of comments on this proposed unchanged criterion. A majority of the comments received on this proposal simply indicated their support for keeping this certification criterion as-is. However, some commenters offered additional suggestions, including one that suggested we remove this certification criterion in the next edition. This commenter did not believe the functionality expressed in the certification criterion would be relevant until a quality or incentive program existed that defined clear objectives for its use as well as the requirement of consistent vocabulary and interoperability support through common standards. Another commenter recommended that images be of diagnostic quality. Other commenters suggested that we incorporate the adoption of the Digital Imaging and Communication in Medicine (DICOM) standards in future editions. One commenter suggested that future editions should go beyond the ‘‘accessibility’’ of images to focus on the transmission of images. Commenters also stated that the interoperability of imaging among different EHR systems must be supported through standards. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition ‘‘image results’’ certification criterion. The 2014 Edition certification criterion was expressly adopted to support the correlated MU objective and associated measure, which focuses on the accessibility of electronic imaging results through CEHRT. We point readers to the 2014 Edition Final Rule (77 FR 54173) in which we concluded ‘‘that the adoption of the DICOM standard (or any other standards) was unnecessary to enable users with electronic access to images and their narrative interpretations.’’ We will take the DICOM suggestion as well as those comments that encouraged a broader certification criterion into consideration for future rulemaking, if the intended purpose for which this certification criterion was adopted changes or new PO 00000 Frm 00027 Fmt 4701 Sfmt 4700 54455 functionality for testing and certification appears necessary. Family Health History We proposed a ‘‘family health history’’ (FHH) certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. We proposed to adopt the HL7 Pedigree IG, HL7 Version 3 Implementation Guide: Family History/Pedigree Interoperability, Release 1 and to include only the HL7 Pedigree standard and the new IG in this certification criterion, and no longer permit demonstrating the use of only SNOMED CT® to code family health history as a means of meeting this certification criterion. Comments. Some commenters expressed general agreement with the proposal, noting that the proposed approach should improve interoperability by moving to one standard and patient care through use of a more comprehensive standard. Many commenters were against moving solely to the HL7 Pedigree standard. Commenters argued that there was a high burden in shifting to HL7 Pedigree, particularly after just adopting SNOMED CT® for FHH. Commenters also expressed concern about Consolidated CDA compatibility and, as they described it, HL7 Pedigree’s nominal benefit in terms of genomics. Commenters also recommended identifying an appropriate use case for moving solely to HL7 Pedigree, noting that HL7 Pedigree relies on SNOMED CT® for coding problems and problems is the predominate use case for coding FHH among most providers. Response. We have not adopted the proposed FHH certification criterion. The comments received suggest further evaluation is needed as to whether moving to solely the HL7 Pedigree standard for FHH serves an appropriate use case for certification and whether the benefits exceed any potential costs and burden for developers and providers. Patient List Creation We proposed a ‘‘patient list creation’’ certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. We proposed to include text in the proposed ‘‘patient list creation’’ certification criterion clarifying that EHR technology must demonstrate its capability to use at least one of the more specific data categories included in the proposed ‘‘demographics’’ certification criterion (e.g., sex or date of birth), which E:\FR\FM\11SER2.SGM 11SER2 54456 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations tkelley on DSK3SPTVN1PROD with RULES2 incorporated the guidance provided in FAQ 39.33 Comments. We received only a few comments on this proposal. Commenters expressed support for this proposal. Commenters also stated that the certification criterion was essentially the ‘‘same’’ as the 2014 Edition by incorporating FAQ 39 because the FAQ applies for certification to the 2014 Edition certification criterion. One commenter suggested that instead of requiring the use of ‘‘at least one’’ demographic data element in the creation of patient lists that we require ‘‘at least two’’ demographic data elements. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would simply incorporate guidance that EHR technology developers are already following for certification to the 2014 Edition ‘‘patient list creation’’ certification criterion. The required use of a minimum of two demographic elements was not proposed. Therefore, we have insufficient stakeholder feedback on the potential requirement’s benefit versus its burden. We will, however, consider this suggestion in relation to future rulemaking activity concerning a ‘‘patient list creation’’ certification criterion. Patient-Specific Education Resources We proposed a ‘‘patient-specific education resources’’ certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. We proposed to adopt this certification without the requirement that EHR technology be capable of electronically identifying patientspecific education resources based on ‘‘laboratory values/results’’ due to stakeholder feedback indicating that the Infobutton standard does not support this level of data specificity. We proposed to adopt the HL7 Implementation Guide: ServiceOriented Architecture (SOA) Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain, Release 1, August 2013, which is an updated version of the IG we adopted for the 2014 Edition. To clearly distinguish this IG in the regulation text from the prior version, we proposed a technical amendment to § 170.204(b)(2). We proposed to revise the regulation text to be more consistent with the intent and interpretation of the 2014 Edition certification criterion regulation text that we expressed in the 2014 Edition Final Rule.34 We noted that the text of the proposed certification criterion made 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. We also noted that the guidance we provided in FAQ 40 35 would still be applicable to the proposed ‘‘patientspecific education resources’’ certification criterion. We requested comment on whether we should adopt a different approach related to the methods EHR technology uses to electronically identify patientspecific education resources for the proposed certification criterion, a potential future ‘‘patient-specific education resources’’ certification criterion, or both. The 2014 Edition and proposed certification criterion require EHR technology to demonstrate the capability to electronically identify for a user patient-specific education resources using Infobutton and an alternative method. We sought 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 sought 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 proposed 34 77 33 https://www.healthit.gov/policy-researchers- implementers/39-question-04-13-039. VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 FR 54216. 35 https://www.healthit.gov/policy-researchers- implementers/40-question-04-13-040. PO 00000 Frm 00028 Fmt 4701 Sfmt 4700 certification criterion, in a potential future certification criterion, or in both. Comments. We received comments supporting removal of the laboratory values/results data element, adoption of the updated SOA IG, and the proposed clarifying regulation text. We received comments supporting both options (1) and (3) related to the methods EHR technology must demonstrate for providing patient-specific education resources. Most commenters preferred option (3). No commenters expressed support for option (2). Consumer and patient advocacy groups supported providing patient-specific education resources in a patient’s preferred language, while EHR technology developers did not support this proposal due to the burden they stated it would create because of the great number of potential languages and the lack of content resources for all potential languages. These commenters also noted that burden would far exceed the benefits (e.g., the number of patients requesting patient-specific education resources in a preferred language). Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. We will consider the comments on the specific proposed changes to the certification criterion as well as the comments on the methods EHR technology must demonstrate for providing patient-specific education resources and the use of preferred language in providing those resources for future rulemaking concerning a ‘‘patient-specific education resources’’ certification criterion. Electronic Medication Administration Record We proposed an ‘‘electronic medication administration record’’ (eMAR) certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion. Comments. The majority of commenters supported an unchanged criterion. One commenter suggested removing this criterion in future editions because the market drove availability and adoption of this functionality before it was introduced in the 2014 Edition. This commenter also opined that the functionality could be E:\FR\FM\11SER2.SGM 11SER2 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations record the electronic location of an advance directive, provide a link or instructions to the location of an advance directive, provide the content of an advance directive, and include other care planning documents such as a Physicians Order for Life-Sustaining Treatment (POLST). Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition ‘‘advance directives’’ certification criterion. We will, however, consider whether this certification criterion should be enhanced in any of the ways mentioned by commenters as part of future rulemaking activity concerning an ‘‘advance directive’’ certification criterion. tkelley on DSK3SPTVN1PROD with RULES2 better improved as part of or in the context of the CDS criterion. Another commenter stated that CDS at the point of medication administration would serve as an additional quality check. A commenter stated that a bar code administration process is needed to fulfill this requirement. A commenter also suggested that a distinction be made for data models that include pro re nata (PRN) medications that are prescribed ‘‘as needed’’ and may not actually be given on a regular basis. The commenter stated that these medications may be included in the denominator even though they may never be included in the numerator, and thus the commenter opined that PRN medications should be treated differently than other medications. One commenter stated that the FDA is working to implement requirements in the Drug Supply Chain Security Act regarding standards for the interoperable exchange of information for tracing human, finished, and/or prescription drugs. The commenter recommended that we be aware of these efforts and align current and future EHR requirements with any future FDA requirements for standards-based identification of prescription drugs. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. We will consider, in regards to future rulemaking, feedback that this criterion is unnecessary in of itself, comments regarding the FDA’s work to implement requirements in the Drug Supply Chain Security Act, comments providing guidance for fulfilling this requirement, and comments noting the distinction between PRN medications and other medications given on a regular basis. We proposed to adopt a new certification criterion for EHR technology to demonstrate that it is able to record and display a unique device identifier (UDI) 36 and other information about a patient’s implantable devices. We noted that this proposal represented 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 devicerelated patient safety information, and achieve other important patient safety and public health benefits consistent with the fundamental aims of the HITECH Act and the July 2, 2013 HHS Health Information Technology Patient Advance Directives We proposed an ‘‘advance directives’’ certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion. Comments. Commenters expressed support for the proposed unchanged certification criterion. Some commenters suggested, however, that this certification criterion be further enhanced by requiring HIT certified to this certification criterion to be able to 36 A UDI is a unique numeric or alphanumeric code that consists of two parts: (1) A device identifier (DI), a mandatory, fixed portion of a UDI that identifies the labeler and the specific version or model of a device, and (2) a production identifier (PI), a conditional, variable portion of a UDI that identifies one or more of the following when included on the label of a device: The lot or batch number within which a device was manufactured; the serial number of a specific device; the expiration date of a specific device; the date a specific device was manufactured; the distinct identification code required by 21 CFR 1271.290(c) for a human cell, tissue, or cellular and tissue-based product (HCT/P) regulated as a device. https:// www.fda.gov/MedicalDevices/ DeviceRegulationandGuidance/ UniqueDeviceIdentification/. VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 Implantable Device List PO 00000 Frm 00029 Fmt 4701 Sfmt 4700 54457 Safety Action and Surveillance Plan.37 We also provided a short summary of the FDA’s regulatory activity associated with the UDI. In our proposal, we explained our belief that EHR technology will play a key role in the widespread adoption and utilization of UDIs and that EHRs’ use of UDIs can help reduce device-related medical errors and provide other significant patient safety, health care quality, and public health benefits. For example, 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. We also noted that 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. As part of our proposal, we recognized that additional standards and technical specifications would be required to support the full range of contemplated capabilities and uses, and that efforts to identify or develop these standards are already underway. Nevertheless, we stated our belief that specifying some baseline functionality as part of a certification criterion would be important in order for EHR technology developers to consider the functionality necessary to capture, store, and retrieve UDIs and other contextually relevant information associated with a patient’s medical devices, specifically implantable devices. Our proposal focused on a certification criterion that would assess an EHR technology’s ability to record UDI information about implantable devices. More specifically, we proposed that EHR technology would have to show that it could 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.’’ We also proposed that EHR technology would need 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. Our last proposal focused on an EHR technology’s ability to parse the UDI in order to extract and allow a user to view the ‘‘device 37 https://www.healthit.gov/sites/default/files/ safety_plan_master.pdf E:\FR\FM\11SER2.SGM 11SER2 tkelley on DSK3SPTVN1PROD with RULES2 54458 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations identifier’’ and ‘‘production identifier’’ portions of the UDI. Combined with this specific certification criterion’s proposal, we also proposed that the UDI would need to be included as part of a Consolidated CDA in each of the following proposed criteria: • § 170.315(b)(1)—Transitions of care; • § 170.315(b)(6)—Data portability; • § 170.315(e)(1)—View, download, and transmit to 3rd party; and • § 170.315(e)(2)—Clinical summary. Finally, we proposed to modify § 170.102 to include new definitions for ‘‘implantable device,’’ ‘‘unique device identifier,’’ ‘‘device identifier,’’ and ‘‘production identifier’’ in order to prevent any misinterpretation and ensure that each term’s specific meaning reflected the same meaning given to them in the Unique Device Identification System Final Rule and in 21 CFR 801.3. We also sought public comment on issues outside the scope of the Proposed Rule in order to inform future rulemaking considerations, which we noted in the Proposed Rule would not be responded to in this final rule. Comments. Many commenters supported the overall intent behind the proposed certification criterion. These commenters recognized its potential benefits to patient safety and supported the adoption of a certification criterion focused on implantable device list functionality. Some commenters (including those that conceptually supported the proposed criterion) contended that the proposed certification criterion was complex, included new workflow considerations and, from a timing perspective, that it would be premature to adopt a certification criterion including the proposed functionality in this final rule. Instead, they suggested that we wait for the next rulemaking (the rulemaking we expressed our intention to issue with CMS to accompany policy updates to the EHR Incentive Programs) as that would provide EHR technology developers more time to design their systems as well as time for the FDA to continue to make progress on the broader technical infrastructure necessary to comprehensively support the UDI. Other commenters, mostly EHR technology developers, suggested that the proposed criterion would not be applicable or relevant to the ambulatory setting (due to where implantable device UDI data would be most routinely captured in the inpatient setting) and requested that we scope this criterion to be specific to the inpatient VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 setting. A few commenters suggested that this certification criterion might be ill-suited for both the ambulatory and inpatient settings because the capture of implantable device identifiers would take place in surgical HIT systems. Additionally, some commenters suggested limiting the scope of the certification criterion to focus just on storing only the UDI number as structured data and include the criterion in a future edition of certification criteria without any of the added functional requirements proposed in the Proposed Rule. Another commenter suggested expanding the scope of the certification criterion to include all devices as opposed to the implantable device scope we had included in our proposal, as greater alignment should exist between EHR technology and other technologies used to support supply chain management. Commenters stated that we had not clearly identified specific use cases that the proposed certification criterion was meant to support. They requested greater clarity in order to better understand how the UDI data was to be used. In that regard, some commenters expressed concern that including the UDI data as part of information exchange transactions (specifically in the Consolidated CDA only) would be premature and suggested that we work with other standards development organizations (such as HL7, NCPDP, and X12) to clarify when and to whom the UDI would need to be communicated. Along different lines, one commenter suggested that we modify the proposal to ‘‘electronically record the UDI’’ to focus on the EHR technology recording the UDI in its complete and parsed state and similarly presented to users in an understandable manner. Another commenter suggested that EHR technology have the capability to generate patient lists by a particular device. Several commenters requested that we require as part of the certification criterion the use of AIDC technology, while another commenter acknowledged that the system behavior for EHR technology could be similar to that described in the 2014 Edition eMAR certification criterion. These commenters reasoned that an EHR user should not have to manually enter the UDI as it would be inefficient and that the UDI’s length could increase the risk of harm due to inaccurate data entry. At least one commenter indicated that financial constraints surrounding AIDC technology could hamper investments in such technology and cause its use to be delayed. PO 00000 Frm 00030 Fmt 4701 Sfmt 4700 Response. We have not adopted this certification criterion. We believe additional work is necessary to further refine our proposal based on public comments. We very much appreciate the detailed comments submitted, including those that pointed to areas where we need to provide additional detail and clarity. We believe that our next rulemaking can provide such detail and clarity, and intend to propose a UDI-focused certification criterion that reflects the input provided. Transitions of Care We proposed to make several changes to the ToC certification criterion, including adopting an updated version of the Consolidated CDA, certain data quality constraints on the creation of Consolidated CDAs to improve patient matching, a proposed ‘‘performance standard’’ that would have required EHR technology to successfully electronically process validly formatted Consolidated CDAs no less than 95% of the time, and the inclusion of UDI information. Updated Consolidated CDA Standard We proposed to incorporate an updated version of the Consolidated CDA Standard, HL7 Implementation Guide for CDA Release 2: Consolidated CDA Templates for Clinical Notes (U.S. Realm), Draft Standard for Trial Use, Release 2.0 (‘‘Release 2.0’’), which was balloted in the summer of 2013. We proposed to include Release 2.0 in four certification criteria: ToC, VDT, clinical summary, and data portability. Comments. We received many comments on this proposal. The majority of commenters, especially those from EHR technology developers, developer associations, and certification bodies, did not support this proposal. Commenters voiced concerns that Release 2.0 was so new that many stakeholders had not had the chance to review it and it had not been sufficiently piloted. In addition, commenters pointed out a technical problem with the update, known as ‘‘bilateral asynchronous cutover’’ wherein Release 2.0 is not backwards compatible with previous versions of the Consolidated CDA and therefore a provider with a 2014 Edition certified product could not receive a document conformant to the Release 2.0 standard. These commenters supported considering Release 2.0 for future editions of our certification rules. Consumer advocacy groups supported the proposal, noting that the additional functionality included in Release 2.0 such as new structural elements for care plans, patient goals, and health E:\FR\FM\11SER2.SGM 11SER2 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations tkelley on DSK3SPTVN1PROD with RULES2 outcomes were important to longitudinal health and care planning and therefore should be included. Response. We have not adopted Release 2.0 for any certification criteria in this final rule. We appreciate the detailed feedback we received from the developer community and agree that more work remains to address some of the challenges expressed by stakeholders. We remain interested in moving to Release 2.0 and acknowledge that pilot testing is occurring. We will continue to monitor the pilot testing and any other developments concerning Release 2.0 and will consider them in determining whether to include Release 2.0 in a future rulemaking. ToC Interoperability and MU Stage 2 ‘‘Cross-Vendor’’ Exchange We proposed to create a new ‘‘crossvendor’’ exchange requirement. We proposed to require EHR technology certified to the ToC certification criterion to demonstrate that it can successfully electronically process validly formatted Consolidated CDAs no less than 95% of the time. Comments. We received many comments on this proposal. Overall, commenters did not support our proposal. Commenters voiced concerns about the testability of this requirement. Commenters also questioned the likelihood that the proper set of testing documents could be collected, which would prevent efficient testing and development. Commenters questioned how we determined the 95% threshold and requested we provide evidence supporting that limit. Commenters stated that the 95% threshold would be impractical, time consuming, and expensive to implement, given the wide variation in Consolidated CDA implementation. Commenters also noted that the proposal was vague and confusing, and sought additional information about various portions of the proposal, including what it means to ‘‘electronically process.’’ Commenters supported constraining the Consolidated CDA as a better way to achieve our stated goals. Response. Given our approach in this final rule to only adopt a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and include revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange, we have not finalized this proposal. We agree that a more constrained Consolidated CDA is an equally implementable approach to reducing the implementation ambiguity and flexibility afforded in the current VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 54459 Consolidated CDA. We encourage industry stakeholders to take such steps. We will re-consider this proposal and the comments received for future rulemaking. health information exchange, we have not adopted this proposal. We will consider comments regarding patient matching functionality for future rulemaking. ‘‘Create’’ and Patient Matching Data Quality We proposed to include a limited set of standardized data (79 FR 10900) as a part of the ‘‘create’’ portion of the Proposed Voluntary Edition ToC criterion to improve the quality of the data included in outbound summary care records. We also sought comment on additional data to include and other constraints that could be applied to this data to improve its quality. Comments. Overall, the vast majority of commenters supported the policy that standardized patient identifying attributes should be required and captured by certified EHR technology for use in relevant exchange transactions. Commenters overwhelmingly supported the inclusion of the proposed constrained specifications for last name/family name, suffix, first/given name, middle/ second name, date of birth, current address and historical address, phone number, and sex in support of patient matching. We received an especially large amount of feedback regarding the address proposal. Commenters suggested that we delay support for international standards for address until future editions of certification criteria. Commenters also provided feedback that the United States Postal Service format specifications are not in sync with other MU requirements, such as the LRI and LOI IGs, and recommended further review of the appropriate address standardization. Commenters also recommended the inclusion of a field for ‘‘former name’’ as many patients change their names for purposes beyond marriage. Commenters noted that some of the proposed data elements would come from practice management systems that EHRs do not control, including maiden name, historical address and phone number (including multiple phone numbers), and recommended these fields be made optional. Some commenters stated that the proposed standardization was premature, raising usability and privacy concerns and urging us to do further analysis. Response. Given our approach in this final rule to only adopt a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and include revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance Unique Device Identifier Information We proposed to include UDIs for a patient’s implantable device within a created Consolidated CDA formatted document. Comments. As noted in the UDI section, commenters stated that it was premature to include implantable device information in Consolidated CDA formatted documents and raised questions about the Consolidated CDA’s ability to support such information. Response. We have not finalized our proposal to include the UDI information in a Consolidated CDA formatted document given our decision not to adopt a UDI certification criterion at this time. We appreciate the comments from stakeholders and will consider them for future rulemakings. PO 00000 Frm 00031 Fmt 4701 Sfmt 4700 Electronic Prescribing (e-prescribing) We proposed an ‘‘e-prescribing’’ certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion. Comments. The majority of commenters supported an unchanged criterion. One commenter suggested merging this criterion with the CPOE— medications certification criterion. Multiple commenters recommended that we adopt the NCPDP ‘‘SCRIPT Implementation Recommendations’’ guidance document that provides clarity on how to populate e-prescribing transactions.38 One commenter endorsed the inclusion of RxNorm drug identifiers to provide quality controls for drug identification and promote interoperable exchange of medication information. This commenter recommended use of RxNorm in place of a representative National Drug Code (NDC). One commenter suggested that we consider requiring transmission of in-language prescription labels to prevent inappropriate misuse of prescriptions. A commenter noted that the FDA is working to implement requirements in the Drug Supply Chain Security Act regarding standards for the interoperable exchange of information for tracing human, finished, and/or prescription drugs. The commenter recommended that we be aware of these 38 The most recent version of this document is Version 1.26 May 2014. E:\FR\FM\11SER2.SGM 11SER2 54460 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations tkelley on DSK3SPTVN1PROD with RULES2 efforts and align current and future EHR requirements with any future FDA requirements for standards-based identification of prescription drugs. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. We will consider comments including those on vocabularies, the NCDPD SCRIPT implementation guidance, prescription labeling, and the FDA’s work to implement the requirements in the Drug Supply Chain Security Act for future rulemaking activity concerning an ‘‘eprescribing’’ certification criterion. Incorporate Laboratory Tests and Values/Results We proposed an ‘‘incorporate laboratory tests and values/results’’ certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. Specifically, we proposed to include in the criterion the HL7 Version 2.5.1 Implementation Guide: Standards and Interoperability Framework Laboratory Results Interface, Release 1 (U.S. Realm) (S&I Framework LRI) with Errata.39 We also proposed more specific requirements for how EHR technology must be capable of electronically displaying the information included in a test report. As stated in the Proposed Rule, this specificity would improve the consistency with how laboratory tests and values/results are displayed, which would also assist laboratories with CLIA compliance. We proposed to require EHR technology to be capable of displaying the following information included in laboratory test reports it receives: 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). Comments. Commenters were generally supportive of adoption of interoperable laboratory standards, particularly the LRI IG with errata, and with aligning requirements with CLIA. 39 https://www.hl7.org/implement/standards/ product_brief.cfm?product_id=279. VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 Commenters did, however, express concerns. Commenters recommended that major errata in the proposed LRI IG be tested further before normative balloting, stating that this would give laboratories and HIT developers more awareness of significant changes and time to implement and test the changes before the IG becomes normative. EHR technology developers expressed concerns with specific requirements for EHRs to display information that they stated would routinely be captured in a laboratory information system or other system and not available to EHRs. Commenters also strongly recommended that there should be harmonization across all IGs (e.g., LRI, LOI, ELR, eDOS, CDA and other IGs) for consistent process, behavior, terminology, and usage. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. We believe, however, that there is great promise and value in the LRI IG in terms of improving the interoperability of laboratory test results/values, the electronic exchange of laboratory test results/values, and compliance with CLIA for laboratories. We believe work is currently being done to address the concerns of commenters, such as addressing interoperability concerns and ambiguities with the LRI IG with errata, testing use of the LRI IG, developing implementation guidance for EHR functionality, and harmonizing all laboratory standards and IGs. Accordingly, while we have not adopted the proposed certification criterion at this time or the LRI IG with errata, we intend to revisit this certification criterion and the use of an updated LRI IG along with CLIA requirements in a future rulemaking. Transmission of Electronic Laboratory Tests and Values/Results to Ambulatory Providers We proposed a ‘‘transmission of electronic laboratory tests and values/ results to ambulatory providers’’ certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. Specifically, we proposed to include in the criterion the HL7 Version 2.5.1 Implementation Guide: Standards and Interoperability Framework Laboratory Results Interface, PO 00000 Frm 00032 Fmt 4701 Sfmt 4700 Release 1 (U.S. Realm) (S&I Framework LRI) with Errata.40 We also proposed to include new functionality that would improve the consistency with how laboratory tests and values/results are sent, received, and displayed. As stated in the Proposed Rule, this would assist laboratories with CLIA compliance. We proposed to require EHR technology to be capable of including in the laboratory test reports it creates for electronic transmission: 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). To make the CFR easier to follow for readers, we proposed to adopt the updated S&I Framework LRI at § 170.205(j)(2), which would require the modification of the regulatory text hierarchy in § 170.205(j) to designate the standard referenced by the 2014 Edition version of this certification criterion at § 170.205(j) to be at § 170.205(j)(1). Comments. The comments we received on this proposed certification criterion were substantially similar to the comments we received on the ‘‘incorporate laboratory tests and values/results’’ certification criterion discussed above. We refer readers to those comments. Response. We have not adopted this certification criterion. Our rationale for not adopting this certification criterion is the same as that provided for the ‘‘incorporate laboratory tests and values/results’’ certification criterion discussed above. We refer readers to that response. Data Portability We proposed a ‘‘data portability’’ certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. We proposed to include in the certification criterion the Consolidated CDA Release 2.0 and UDIs for a patient’s implantable device within a created Consolidated CDA formatted document. Comments. The comments we received regarding the Consolidated CDA Release 2.0 in response to this criterion were similar to those received on the other four criteria that we proposed to incorporate it within. The majority of commenters thought it was premature to adopt Release 2.0 and that 40 https://www.hl7.org/implement/standards/ product_brief.cfm?product_id=279. E:\FR\FM\11SER2.SGM 11SER2 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations tkelley on DSK3SPTVN1PROD with RULES2 Release 2.0 would create backwards compatibility issues with previous versions of the Consolidated CDA, thus preventing the receipt of the new version. Commenters recommended we do not include it in the data portability certification criterion at this time. Commenters also stated that it was premature to include patient implantable device information (i.e., UDIs) in Consolidated CDA formatted documents. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As discussed under the ToC certification criterion in this section (IV.A) of the preamble, we have not adopted the Consolidated CDA Release 2.0. As discussed under the ‘‘implantable device list’’ certification criterion in this section (IV.A) of the preamble, we have not adopted that proposed certification criterion. We will, however, in relation to future rulemaking activity, consider the comments received concerning a ‘‘data portability’’ certification criterion, the Consolidated CDA Release 2.0, and a patient’s implantable device list and associated UDIs. Clinical Quality Measures—Capture and Export We proposed a ‘‘clinical quality measures—capture and export’’ certification criterion as part of the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did, however, solicit public comment on the potential usefulness of broadening the export requirement to include a QRDA Category II formatted data file. Comments. We received a few comments that the immunization CQMs do not match well with the Advisory Committee on Immunization Practice’s recommendations. A commenter suggested that we should not update the standards we adopted for CQMs in the 2014 Edition until the industry has had sufficient time to adjust to the current standards. One commenter suggested that we and CMS revise the current eCQM process and provide a database configuration that all EHR technology developers, EPs, EHs, and CAHs would install. The commenter stated that the configuration would be able to take raw data and produce the desired output for each eCQM and QRDA submission, VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 thereby reducing the burden on EHR technology developers to adapt to changes in the database schema and data collection. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition ‘‘clinical quality measures—capture and export’’ certification criterion. Our request for comment on the potential usefulness of broadening the export requirement to also include a QRDA Category II formatted data file was to inform our decision-making for future rulemaking. We will take comments received on this topic into consideration with the comments received regarding clinical recommendations, standards maturity, and the current eCQM process for future rulemaking concerning CQMs. Clinical Quality Measures—Import and Calculate We proposed a ‘‘clinical quality measures—import and calculate’’ certification criterion as part of the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion. Comments. One commenter stated that this criterion requires a level of patient matching that does not currently exist. This commenter encouraged the creation of a national patient identification number. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition ‘‘clinical quality measures—import and calculate’’ certification criterion. We thank commenters and understand the importance of matching clinical quality data with the right patient. We note that PO 00000 Frm 00033 Fmt 4701 Sfmt 4700 54461 we solicited comments on patient matching in the Proposed Rule and discuss this topic in more detail under the ‘‘ToC’’ certification criterion in this section (IV.A) of the preamble. However, we note that we have not adopted patient matching requirements in this final rule given our rulemaking approach and will consider comments on the topic for future rulemaking. Clinical Quality Measures—Electronic Submission We proposed a ‘‘clinical quality measures—electronic submission’’ certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion. Comments. A few commenters noted the discrepancies between the QRDA Category I and III standards referenced in the 2014 Edition and the subsequently issued CMS QRDA Category I and III IGs dictating the ‘‘form and manner’’ of eCQM submission to CMS, as required for participation in the Physician Quality Reporting System and Inpatient Prospective Payment System programs. Commenters noted that the CMS QRDA IGs issued in 2013 had some conflicts with the base QRDA Category I and III standards named in the 2014 Edition. Commenters also stated that the CMS QRDA IG publication dates (April 1, 2013 for EHs, June 1, 2013 for EPs) did not provide sufficient time for EHR updates, testing, and rollout to providers. Therefore, these commenters suggested we remove the language in paragraph (ii) of this criterion requiring the electronic data file can be electronically accepted by CMS. Two commenters recommended that we not adopt standards that are in draft standard for trial use (DSTU) form and wait until they become normalized standards. These commenters noted that the QRDA Category I and III standards adopted in the 2014 Edition are still DSTUs. One commenter added that no regulatory action has been taken to incorporate the errata to the QRDA Category I and III standards since their release in 2013. Another commenter stated that the QRDA Category I and III standards are not widely used to transmit data. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR E:\FR\FM\11SER2.SGM 11SER2 54462 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations tkelley on DSK3SPTVN1PROD with RULES2 certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition ‘‘clinical quality measures—electronic submission’’ certification criterion. We will consider comments received on this criterion regarding QRDA standards maturity and program-specific QRDA IGs for future rulemaking concerning CQMs. Clinical Quality Measures—Patient Population Filtering We proposed a new ‘‘clinical quality measures—patient population filtering’’ certification criterion for the Proposed Voluntary Edition that would require filtering of CQMs by patient population characteristics. Certain CMS reporting programs such as the Comprehensive Primary Care initiative and Pioneer Accountable Care Organization model may determine financial incentives or bonus payments based on the performance of an entity other than the individual provider. To support CQM reporting for these groups, we proposed to require 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 more of 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; and • Demographics including age, sex, preferred language, education level, and socioeconomic status (SES). To inform our proposal, we solicited comment on whether current CQM standards (e.g., QRDA Category I and Category III) can collect metadata for the characteristics listed above, and filter and create a CQM report for a particular characteristic or combination of characteristics. We also solicited comment on vocabulary standards that could be used to record the characteristics proposed above. Comments. We received mixed comments on the proposal to adopt a new certification criterion to support filtering of CQMs by patient characteristics. Those commenters in support of the proposal stated that the added functionality included in the VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 certification criterion would help address health disparities and social determinants of health. Some commenters believed that collecting the data in a structured way would allow data to be filtered. One commenter pointed to the National Quality Forum’s draft report on ‘‘Risk Adjustment for Socioeconomic Status or Other Socioedemographic Factors,’’ which recommends stratification of measures on the basis of relevant sociodemographic factors when the intended purpose is to identify and reduce disparities.41 Additionally, commenters stated that the proposal would help providers participating in programs where the reporting is at an aggregate, rather than individual, provider level. Some commenters noted that the use case for this functionality was not made clear in the preamble. A few commenters pointed out that race and ethnicity were not included in the proposed list of characteristics and strongly urged us to consider including race and ethnicity. Commenters also suggested the inclusion of practice type, practice specialty, sexual orientation and gender identity, and disability status in the list of characteristics required for filtering. Some commenters suggested that we perform a full inventory of the possible data elements that CQMs could be filtered by before proposing a list. We also received comments expressing concern about the level of work required to build the proposed functionality into EHRs. Commenters pointed out that some of the proposed data elements are typically found within administrative systems (e.g., practice address and insurance data) while other data is found within clinical systems such as the EHR. Commenters opined that while some systems can easily merge administrative and clinical data, not all systems currently have this capability and thus the ability to support this proposed criterion varies. Many commenters noted that proposed characteristics, such as age, sex, diagnosis, NPI, and TIN, are being collected in standardized ways within EHRs, but that there are not standard vocabularies or definitions for other data elements such as education and SES. One commenter recommended using a standard for collecting education based on the standard used by the National Center for Health Statistics. Some commenters were concerned about the complexity of establishing a definition and standard for SES as it could factor in information 41 https://www.qualityforum.org/WorkArea/ linkit.aspx?LinkIdentifier=id&ItemID=75398. PO 00000 Frm 00034 Fmt 4701 Sfmt 4700 on occupation, education, income, wealth, and place of residence. Commenters stated that this kind of data is not typically collected in a clinical setting. Additionally, SES could change over time and thus the inputs may change, adding further complexity. Regarding standards for quality measurement, some commenters remarked that the QRDA standards can currently capture the data elements needed to filter CQMs by certain patient population characteristics, although not all data elements in standardized form as noted above. Commenters stated that the HQMF standard can currently support filtering by patient characteristics but not by other provider or location variables such as address, TIN, and NPI. Additionally, a commenter stated that HQMF does not have the ability to indicate the level at which a measure needs to be evaluated and summarized. The commenter contended that this could affect whether patients are identified in the initial patient population for group reporting or not, and would impact whether the patient is filtered or not. Response. Given the feedback we received, we believe additional work is needed to further refine our proposal. Therefore, we have not adopted this certification criterion. We clarify that we envision two types of uses for this functionality: 1) Filtering of CQM results to support the identification of health disparities, to help providers identify gaps in quality, and to support a provider in delivering more effective care to sub-groups of their patient populations, and 2) to support administrative and group/ACO reporting of CQMs where the unit of measurement is not the individual provider. We are considering whether this functionality could be a standalone certification criterion or an additional functionality included in a new version of the ‘‘clinical quality measures— import and calculate’’ certification criterion at § 170.314(c)(2). As we have considered stakeholder feedback on the workflow to filter CQMs, EHRs may need to first calculate the CQM and then be able to stratify/filter results by certain characteristics. We agree with commenters that there are standardized vocabularies to collect some of the data elements we proposed, but not all. We recognize that more work is needed to identify standards for other data elements we proposed. We also recognize that the list we proposed is not a complete set, and that there are additional data elements the stakeholders may wish to filter by. We appreciate the comments regarding standards for quality reporting (e.g., E:\FR\FM\11SER2.SGM 11SER2 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations tkelley on DSK3SPTVN1PROD with RULES2 QRDA and HQMF), and will use this feedback to inform our future rulemaking. We will also take into consideration comments on the level of filtering and summarization of CQMs for group and ACO reporting. Authentication, Access Control, and Authorization We proposed an ‘‘authentication, access control, and authorization’’ certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did, however, solicit comments on the issue of twofactor authentication to support two use cases: E-prescribing of controlled substances; and remote provider access. In 2010, the Drug Enforcement Agency (DEA) removed the federal ban on eprescribing controlled substances. The DEA requires the use of two-factor authentication protocol when eprescribing. In 2012, the HITPC recommended that we adopt multifactor authentication by providers remotely accessing protected health information. We asked the public to respond to two questions: (1) Should we adopt a general twofactor authentication requirement for certification? (2) Were the HITPC’s recommendations appropriate and actionable? Comments. All commenters supported the certification criterion as unchanged. Commenters did not support a broad two-factor authentication requirement for certification. The majority of the commenters did, however, support the inclusion of two-factor authentication functionality for the specific purpose of e-prescribing controlled substances. Some commenters noted that the DEA’s requirements were more complex than basic two-factor authentication and urged us to consult with the DEA before creating a criterion to support this use case. Commenters were divided in their support for requiring two-factor authentication for remote access for providers. Commenters agreed that the HITPC’s recommendations regarding remote access for providers were actionable. However, comments varied with regard to whether the recommendation was appropriate for remote access. Specifically, commenters were concerned that differences in EHR systems (i.e., cloud-based versus practice-installed) created ambiguity as to when the requirement would apply and sought clarity in the term ‘‘remote access.’’ In addition, commenters voiced concern about the potential criterion becoming too prescriptive, with many VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 commenters urging us to propose a criterion that required EHRs to support these use cases without describing how they did so. Commenters further noted concern about the ability to test twofactor authentication. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition ‘‘authentication, access control, and authorization’’ certification criterion. We will consider comments regarding the use of two-factor authentication to support e-prescribing of controlled substances and remote access for providers in future rulemaking concerning an ‘‘authentication, access control, and authorization’’ certification criterion. Auditable Events and TamperResistance We proposed an ‘‘auditable events and tamper-resistance’’ certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. We proposed this certification criterion in response to a report by the OIG entitled, ‘‘Not All Recommended Safeguards Have Been Implemented in Hospital EHR Technology’’ (OEI–01–11– 00570).42 We proposed to require EHR technology to prevent all users from being able to disable an audit log. We asked for public comment on the impact and potential unintended consequences of such a change and for specific examples where disabling an EHR technology’s audit log is warranted. Comments. The majority of commenters, including EHR technology developers, EHR developer associations, and the HITSC, did not support preventing all users from being able to disable the audit log. Commenters stressed that there were valid and important reasons for users to disable the audit log, including allowing a system administrator to disable the audit log for performance fixes, stability, disaster recovery, and system updates or allowing a system administrator to disable it when there is rapid server 42 https://oig.hhs.gov/oei/reports/oei01-1100570.pdf. PO 00000 Frm 00035 Fmt 4701 Sfmt 4700 54463 space loss which is hindering a provider from accessing needed clinical information in a timely manner. Commenters stated that the majority of EHR developers do not currently allow audit logs to be disabled. Commenters also stated that preventing the disabling of the audit log was a best practice, but should not be included in the certification criterion because of cases of emergency or disaster that would necessitate disabling of the audit log. Other commenters, including providers, provider associations, consumer advocates, and EHR technology developers, supported the OIG recommendation. Consumer advocates and others commented that preventing the audit log from being disabled would improve consumers’ trust. A minority of commenters supported identifying a baseline set of auditable actions that should be prevented from being disabled. The baseline set included additions, deletions, and other changes. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. Additionally, in response to the significant and detailed feedback we received recommending that we do not finalize our proposal, we will further evaluate whether it is appropriate to implement the OIG report’s recommendation. As many commenters noted, there are valid reasons that require a limited number of EHR users to be capable of disabling the audit log. We will continue to engage with stakeholders regarding audit log functionality, and will consider stakeholder feedback in regard to future rulemaking concerning an ‘‘auditable events and tamper-resistance’’ certification criterion. Audit Report(s) We proposed an ‘‘audit report(s)’’ certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion as part of the Proposed Voluntary Edition. Comments. Commenters supported the proposed certification criterion as unchanged. Response. We thank commenters for their support of this proposed unchanged certification criterion. We have not, however, adopted this E:\FR\FM\11SER2.SGM 11SER2 54464 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition ‘‘automatic log-off’’ certification criterion. Amendments We proposed an ‘‘amendments’’ certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion. Comments. Commenters supported the proposed certification criterion as unchanged. Some commenters noted the importance of this certification criterion and recommended records tag patientgenerated amendments to denote the appropriate provenance. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition ‘‘amendments’’ certification criterion. We will, however, consider the comments about data provenance of amendments for future rulemaking activity concerning an ‘‘amendments’’ certification criterion. tkelley on DSK3SPTVN1PROD with RULES2 certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition ‘‘audit report(s)’’ certification criterion. We proposed an ‘‘emergency access’’ certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion. Comments. Commenters supported the proposed certification criterion as unchanged. One commenter expressed concerns that untrained users could make a mistake in a complex EHR system related to access. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition ‘‘emergency access’’ certification criterion. In response to the comment on ‘‘untrained’’ users, we note that the 2014 Edition certification criterion (and the proposed ‘‘emergency access’’ criterion) requires EHR technology to be able to designate a ‘‘set of users.’’ A provider would determine appropriate users and access to their system in conjunction with the EHR technology developer, which is not part of the certification process under the ONC HIT Certification Program. Automatic Log-Off We proposed an ‘‘automatic log-off’’ certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion. Comments. Commenters supported the proposed certification criterion as unchanged. Response. We thank commenters for their support. However, we have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 Emergency Access End-User Device Encryption We proposed an ‘‘end-user device encryption’’ certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion. Comments. Commenters supported the proposed certification criterion as unchanged. PO 00000 Frm 00036 Fmt 4701 Sfmt 4700 Response. We thank commenters for their support. However, we have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition ‘‘end-user device encryption’’ certification criterion. Integrity We proposed an ‘‘integrity’’ certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion. Comments. Commenters supported the proposed certification criterion as unchanged. Response. We thank commenters for their support. However, we have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition ‘‘integrity’’ certification criterion. Accounting of Disclosures We proposed an ‘‘accounting of disclosures’’ certification criterion for the Proposed Voluntary Edition that was unchanged substantively as compared to the 2014 Edition certification criterion. We did, however, propose to remove the ‘‘optional’’ designation from this certification criterion for the Proposed Voluntary Edition because such a designation would no longer be necessary with the proposed discontinuation of the Complete EHR concept. Comments. All of the comments received supported leaving the certification criterion unchanged. Commenters overwhelmingly recommended that we do not remove the optional designation regardless of E:\FR\FM\11SER2.SGM 11SER2 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations tkelley on DSK3SPTVN1PROD with RULES2 other proposed changes. Commenters suggested removing the optional designation would create confusion in the marketplace and require significant additional development work. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. We note that commenters apparently misunderstand the purpose of designating certification criteria as optional. As we explained in the Proposed Rule (79 FR 10918), the designation of ‘‘optional’’ for certification criteria was 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 definition and certification). Complete EHR certification is still permitted to the 2014 Edition. Therefore, as proposed, it would make no sense to adopt this certification criterion as part of the 2014 Edition as it is substantively the same as the current 2014 Edition ‘‘accounting of disclosures’’ certification criterion and, without the optional designation, it would directly contradict the current 2014 Edition ‘‘accounting of disclosures’’ certification criterion and EHR technology would be required to certify to it for a Complete EHR certification. View, Download, and Transmit to 3rd Party The summary of the proposals in the Proposed Rule recited in this section only summarize and include the ‘‘comments’’ and ‘‘response’’ for the proposals that we have not adopted in this final rule. For the VDT proposal made in the Proposed Rule and adopted in this final rule, including a summary of what was proposed for that proposal, please see section III.A.2 of this preamble. We proposed to revise the VDT criterion in a number of ways, including: Clarifying introductory text in order to clearly specify that this criterion expressed patient facing capabilities for patient use; decoupling the content and transport requirements and in tandem proposing a revision that would more clearly express EHR technology’s ability to support a patient’s ability to choose the destination or to whom they wanted to VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 send their health information; updating the Consolidated CDA version with the corresponding inclusion of UDI information; increasing the Web Content Accessibility Guidelines (WCAG) level to level AA; and revising the activity history log requirement to record two additional data elements (the addressee to whom an ambulatory summary or inpatient summary was transmitted and whether that transmission was successful). Comments. Commenters generally supported clarifying the introductory text of VDT. Commenters stressed the importance of allowing authorized representatives the ability to perform the VDT functionality. Some EHR technology developers opposed revisions related to the clarification around a patient’s ability to ‘‘download’’ a human readable file, a Consolidated CDA file, or both. A commenter representative of the majority of EHR technology developers indicated that the revised criterion is overly prescriptive and not in sync with actual software development. The commenter stated that EHR technology developers enable users to download the XML version and the style sheet together, since the style sheet is applied to the XML to provide the human-readable information. The commenter concluded that most patients would find making a choice confusing and did not believe that patients would benefit from this proposal. With respect to our proposal for EHR technology to enable a patient to choose the destination or whom they wanted to send their health information via Direct, many commenters opposed or raised concerns about this proposal. Most of these commenters were EHR technology developers who identified a number of technical concerns with the proposal. They stated that: • EHR technology cannot guarantee that any message sent to a Direct address specified for transmission will reach the endpoint. Each HISP has rules beyond the EHR’s control specifying their exchange with other HISPs. • The ability of a patient to enter a third party destination of their choice (i.e., initiate a direct exchange using a valid direct exchange address) would imply that the EHR technology has the ability to determine if the address entered is valid. When a patient enters an address, the EHR technology would not know if it is valid and with the separation of content from transport, the EHR technology would no longer control the Domain Name System/ Lightweight Directory Access Protocol (DNS/LDAP) look up to ensure that the PO 00000 Frm 00037 Fmt 4701 Sfmt 4700 54465 certificate is valid and included within the sender’s HISP trust circle. • Patients have not, and will not any time soon, be given Direct addresses because it is too great an expense. We received many comments on our proposal to update the Consolidated CDA version to Release 2.0. The majority of commenters, especially those from EHR technology developers, HIT developer associations, and certification bodies, did not support this proposal. Commenters voiced concerns that Release 2.0 was so new that many stakeholders had not had the chance to review it and it had not been sufficiently piloted. In addition, commenters pointed out a technical problem with the update, known as ‘‘bilateral asynchronous cutover’’ wherein Release 2.0 is not backwards compatible with previous versions of the Consolidated CDA and therefore a provider with a 2014 Edition certified product could not receive a document conformant to the updated Consolidated CDA standard. These commenters supported considering Release 2.0 for future editions of our certification criteria. Consumer advocacy groups supported the proposal, noting that the additional functionality included in Release 2.0, such as new structural elements for care plans, patient goals, and health outcomes, were important to consumers and care planning. We received mixed comments on our proposal to move to WCAG Level AA, including many from EHR technology developers. Some opposed the increased level citing the cost and burden to reach Level AA. Conversely, other EHR technology developers supported the move and offered no concerns. In both cases, EHR technology developers noted that WCAG conformance tools are somewhat sparse and that they have had difficulty finding viable tools. Of the few comments on whether a hybrid of Level A and Level AA would be preferred, the comments opposed this type of approach because it would lead to variability and inconsistency. Most commenters supported the inclusion of the intended recipient in the activity history log. Commenters voiced concern about requiring a history log to record whether the transmission was successful, noting that EHRs do not have information on what happens to a message once it leaves the EHR and is processed by the HISP. Commenters stated that prior to being able to make this information patient accessible, standards development would be necessary to support this use case. Some commenters agreed that activity history logs should record and include both new data points and stated that this E:\FR\FM\11SER2.SGM 11SER2 54466 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations tkelley on DSK3SPTVN1PROD with RULES2 transaction history provides important information about care coordination that patients should be able to access. Response. We appreciate the detailed feedback we received on many of the VDT proposals. While we are not revising the 2014 Edition VDT to include the proposed clarifying regulation text, we note for commenters that the requirement to provide patients with the ability to download a human readable version, a Consolidated CDA version, or both, already exists within the 2014 Edition VDT certification criterion. As discussed in the Proposed Rule, the clarification was not a modification of existing policy. Rather, it was an attempt at more clearly articulating existing policy to avoid any confusion. As EHR technology developers indicated, we have longstanding policy that permits them to satisfy this approach through the use of a style sheet, which would be an acceptable approach because it would give a patient both human readable and Consolidated CDA versions. We have also decided to leave the 2014 Edition certification criterion unmodified with respect to our proposal to enable a patient to choose the destination or whom they wanted to send their health information via Direct. We will consider the technical challenges raised by EHR technology developers. In the case of the Consolidated CDA update, we have already discussed our decision not to adopt this proposal in the discussion on the ToC criterion (Section IV.A) and do not adopt it for the VDT certification criterion for the same reasons. In response to comments, we will continue to evaluate the WCAG level and suitable testing approaches. Last, we will continue to evaluate comments on our proposal to expand the activity history log and its connection to some of the technical challenges identified by comments. Overall, given our approach in this final rule to only adopt a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and include revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange, we have not adopted any of the proposals discussed in this section. Clinical Summary We proposed a ‘‘clinical summary’’ certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. We proposed to reflect the clarifications we provided in VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 FAQ 33 43 (i.e., require the use of LOINC® for diagnostic tests pending and future scheduled tests to the degree such test could be coded in LOINC®), to require the use of CVX codes for immunizations, and reference the Consolidated CDA Release 2.0 (including UDI(s) for a patient’s implantable device(s) as data within a created Consolidated CDA formatted document) in the proposed certification criterion. We requested comment on whether LOINC® can be used to represent all possible diagnostic tests pending and future scheduled tests. We also reiterated 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 certification criterion as well as the 2014 Edition ‘‘clinical summary’’ certification criterion. We stated that 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. We clarified that in terms of customization of the clinical summary, this permits the user to limit this data in the clinical summary if so desired. We further clarified that 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. Last, we noted that this certification criterion, like the 2014 Edition ‘‘clinical summary’’ certification criterion, was designed to support the associated MU objective and measure that seeks to provide a patient with a record of the office visit and specific lab tests or specific follow-up actions and treatment related to the office visit. Comments. We received many comments supporting the required use of CVX and LOINC®. A few commenters opposed the use of LOINC® codes, while others suggested the use be required ‘‘where applicable’’ because LOINC® cannot currently cover all possible tests. We received comments for and against the use of the Consolidated CDA Release 2.0 and the 43 https://www.healthit.gov/policy-researchersimplementers/33-question-12-12-033. PO 00000 Frm 00038 Fmt 4701 Sfmt 4700 inclusion of UDI(s). Commenters also expressed varying opinions on the data that should be included in a clinical summary. Some commenters suggested that EHR technology allow for complete customization of the data. Others commenters recommended not including historical information or code sets in the clinical summary (which they claimed were confusing to patients). Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. We also note that we have not adopted the proposed Consolidated CDA Release 2.0 as discussed under the ToC certification criterion and the ‘‘implantable device list’’ certification criterion in this section of the preamble (IV.A). We expect EHR technology developers to follow FAQ 33 for certification to the 2014 Edition ‘‘clinical summary’’ certification criterion and we continue to encourage, but not require, the use of CVX codes for immunizations. The data element requirements for certification to the 2014 Edition ‘‘clinical summary’’ certification criterion remain the same as does the ‘‘situational dependency’’ guidance we provided in the Proposed Rule and have recited above. We will, however, take into consideration the comments we received about the data that should be in a clinical summary and how it should be expressed for future rulemaking activity concerning a ‘‘clinical summary’’ certification criterion. Secure Messaging We proposed a ‘‘secure messaging’’ certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion. Comments. The majority of commenters supported adopting this certification criterion as unchanged. However, a few commenters recommended that we take steps to allow a patient’s authorized representative to send and receive secure messages on the patient’s behalf as part of the Proposed Voluntary Edition. In addition, one commenter suggested that this criterion should utilize the same ‘‘decoupling’’ of content and transport requirements as E:\FR\FM\11SER2.SGM 11SER2 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations was proposed for the ToC certification criterion. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition ‘‘secure messaging’’ certification criterion. We also note that the comment about decoupling is unclear. This certification criterion does not establish message content requirements so we are not certain about what the commenter thinks should be decoupled. Further, any method of transport that meets the security requirements of the proposed criterion would have been permitted, as it is currently permitted with the 2014 Edition ‘‘secure messaging’’ certification criterion. Public Health Certification Criteria We received comments related to the public health certification criteria, but not specific to the proposed criteria or our proposals. We summarize and respond to these comments below. Comments. We received a comment in favor of bidirectional exchange between EHRs and clinical registries. The commenter encouraged us to consider certification requirements to promote bidirectional data exchange and data standardization between EHRs and clinical data registries, such as certification of clinical data registries. The commenter stated that this would assist physicians and health care systems as well as align with payment programs that utilize clinical data registries (e.g., PQRS). The commenter also suggested that we consider utilizing existing national standards being used for EHRs. Response. We appreciate the feedback and will consider the suggestions on standards and to require certification of clinical data registries for future rulemaking. tkelley on DSK3SPTVN1PROD with RULES2 Immunization Information We proposed an ‘‘immunization information’’ certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion. VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 Comments. The majority of commenters supported an unchanged criterion. One commenter suggested that we not adopt this criterion, or similar criteria in future editions, because the ‘‘transmission to immunization registries’’ criteria sufficiently addressed the interoperability aspects of the immunization information. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition ‘‘immunization information’’ certification criterion. We appreciate the feedback suggesting that this criterion is unnecessary as the ‘‘transmission to immunization registries’’ certification criterion addresses the functionality required by this criterion. We will consider this feedback for future rulemaking concerning an ‘‘immunization information’’ certification criterion. Transmission to Immunization Registries We proposed a ‘‘transmission to immunization registries’’ certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. We proposed to include in this criterion the updated IG for immunization messaging: HL7 Version 2.5.1: Implementation Guide for Immunization Messaging, Release 1.5. The updated IG 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. Comments. The majority of commenters supported adoption of the updated IG for immunization messaging. These commenters stated that the updated IG provides additional clarification and guidance for better interoperability between EHRs and immunization registries. Commenters in opposition to adopting the updated IG were concerned about needing to support two versions of an IG at the same time. Some commenters were also concerned about backwards compatibility with the version currently required in the 2014 Edition. PO 00000 Frm 00039 Fmt 4701 Sfmt 4700 54467 Commenters who were generally opposed to the proposed voluntary and more incremental rulemaking approach also contended that the updated IG did not offer much value for the work that would be required to update systems. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. We appreciate the feedback commenters provided regarding the updated IG and will consider the comments received for future rulemaking concerning a ‘‘transmission to immunization registries’’ certification criterion. Transmission of Reportable Laboratory Tests and Values/Results We proposed a ‘‘transmission of reportable laboratory tests and values/ results’’ certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. We proposed to include in this criterion the updated IG for reporting laboratory tests and values/results to public health agencies (HL7 Version 2.5.1: HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, DSTU, Release 2 (US Realm), 2013). The updated IG addresses technical corrections and clarifications for interoperability with laboratory orders and other laboratory domain IGs. To properly codify this proposal in regulation, we proposed to modify the regulatory text hierarchy in § 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 § 170.205(g)(1) instead of its current designation at § 170.205(g). Comments. We received mixed feedback on the proposal to adopt the updated IG for reporting laboratory tests and values/results to public health agencies. Some commenters were in favor of adopting the updated IG. Other commenters stated that many state public health agencies and EHR technology developers are still working to implement the version we adopted in the 2014 Edition, and thus contended it is too early to require compliance with an updated IG. A few commenters supported SNOMED-encoded observations values, where applicable, because of the E:\FR\FM\11SER2.SGM 11SER2 tkelley on DSK3SPTVN1PROD with RULES2 54468 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations potential value add to reportable laboratory results for public health. Two commenters stated that we incorrectly referenced the author of the updated IG in the preamble of the Proposed Rule. These commenters recommended that we correct the author reference from CDC to the HL7 Public Health and Emergency Response Workgroup. These commenters also recommended we update the title of the IG to ‘‘HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, R2, US Realm—Draft Standard for Trial Use’’ in order to encompass all current and subsequent releases. One commenter recommended we update the minimum code versions for LOINC® and SNOMED CT®. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. We agree with the correction of the author of the updated IG and believe that the CDC worked in conjunction with the HL7 Public Health Emergency Response Workgroup to develop the updated IG. For future rulemaking, we will consider the comments received regarding the maturity and version/ naming of the updated IG. Regarding the comments recommending that we adopt the updated LOINC® and SNOMED CT® standards, we will reassess whether newer versions of the minimum standards should be adopted in future rulemaking. As we stated in the 2014 Edition Final Rule, based on our experience, newer versions of the ‘‘minimum standards’’ code sets that we have adopted are issued more frequently than our current process can reasonably accommodate. We do not believe that permitting EHR technology to be upgraded and certified to newer versions of these code sets would normally pose an interoperability risk, and therefore we allow use of a newer version voluntarily for certification without adversely affecting the EHR technology’s certified status unless the Secretary specifically prohibits the use of a newer version (77 FR 54268). Thus, EHRs may be certified to newer versions of LOINC® and SNOMED CT®. Cancer Case Information We proposed a ‘‘cancer case information’’ certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 Edition certification criterion. We did not request any specific public comments on this certification criterion. Comments. The majority of commenters supported an unchanged criterion. One commenter suggested removing this criterion in future editions because they recommend a focus on privacy and security, interoperability, and quality reporting, and thus contended that this criterion is not necessary. Another commenter recommended that we consider privacy issues so that patients are not inappropriately penalized by insurance companies or employers for having cancer or a preexisting condition. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition ‘‘cancer case information’’ certification criterion. We will consider the feedback regarding the necessity of this criterion and privacy concerns for future rulemaking concerning a ‘‘cancer case information’’ certification criterion. Transmission to Cancer Registries We proposed a ‘‘transmission to cancer registries’’ certification criterion for the Proposed Voluntary Edition that was revised in comparison to the 2014 Edition certification criterion. We proposed to include in this criterion an updated 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. We also proposed to make a technical amendment to the regulation text for the 2014 Edition certification criterion so that it continues to point to the appropriate standard 44 in the regulatory text hierarchy at § 170.205(i), while accommodating our Proposed Voluntary 44 Standard. HL7 Clinical Document Architecture (CDA), Release 2.0, Normative Edition (incorporated by reference in § 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 § 170.299). PO 00000 Frm 00040 Fmt 4701 Sfmt 4700 Edition proposal. Specifically, we proposed to modify the 2014 Edition certification criterion to reference § 170.205(i)(1) to establish the regulatory text hierarchy necessary to accommodate the standard and IG referenced by the Proposed Voluntary Edition certification criterion. Comments. We received mixed feedback on the proposal to adopt the updated cancer transmission IG. Some commenters supported adopting the updated IG and also commented that they look forward to more generalizable CDA-based case reporting in the future. Other commenters were concerned about the differences in state requirements that lead to custom interface development before achieving bidirectional exchange. Some suggested we wait until the next edition to propose adopting the updated IG because there has not been sufficient time for implementation experience. Some commenters stated that, in their experience, the adoption of the cancer transmission IG required in the 2014 Edition is low, and therefore they did not foresee that many would adopt an updated version. One commenter noted that there is a proposed HL7 project to more closely align the CDA-based cancer reporting IG with the Consolidated CDA standard. We also received comments stating that we should consult with existing registries for guidance on the appropriate standards to adopt. One commenter recommended that the updated IG should include data elements for transmission of grade and pathological TNM Stage,45 as it is difficult to report to state cancer agencies if cancer synoptics are not in a structured data format and can be prone to manual data entry errors. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. We agree that we should evaluate the maturity of the updated IG, its required data elements, efforts to move to the Consolidated CDA standard, and standards used by current registries to inform our future rulemaking concerning a ‘‘transmission to cancer registries’’ certification criterion. 45 The TNM Classification of Malignant Tumours (TNM) is a cancer staging system that describes the extent of a person’s cancer. E:\FR\FM\11SER2.SGM 11SER2 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations tkelley on DSK3SPTVN1PROD with RULES2 Automated Numerator Recording We proposed to adopt an unchanged ‘‘automated numerator recording’’ certification criterion as compared to the 2014 Edition certification criterion. We did not request any specific public comments on this certification criterion. Comments. Commenters expressed support for the proposed unchanged certification criterion. Commenters also expressed concern over the burden involved in meeting MU measurement requirements (e.g., time consuming and affects efforts to improving clinical functionality and usability). One commenter suggested that this criterion either be removed or be made more granular and defined sufficiently. In terms of more granularity, the commenter suggested that each numerator recording requirement for a capability (e.g., CPOE or VDT) should be specified in the ‘‘automated numerator recording’’ certification criterion. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition ‘‘automated numerator recording’’ certification criterion. We will, however, consider whether additional specificity is appropriate for the ‘‘automated numerator recording’’ certification criterion and further evaluate the costs and benefits of this certification requirement for future rulemaking activity concerning an ‘‘automated numerator recording’’ certification criterion. Automated Measure Calculation We proposed to adopt an unchanged ‘‘automated numerator recording’’ certification criterion as compared to the 2014 Edition certification criterion. We proposed to apply guidance for certification to the 2014 Edition ‘‘automated measure calculation’’ certification criterion included in the 2014 Edition Final Rule to the proposed certification criterion (79 FR 10911). We also proposed that the interpretation of the 2014 Edition ‘‘automated measure calculation’’ certification criterion in FAQ 32 46 would apply to the proposed 46 https://healthit.gov/policy-researchersimplementers/32-question-11-12-032. VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 certification criterion. We did not request any specific public comments on this certification criterion. Comments. Commenters expressed support for the proposed certification criterion as unchanged. A couple of commenters stated this certification criterion helped providers and lessened their MU reporting burden. EHR technology developers stated that this criterion represents one of the largest areas of development investment of all of the MU certification requirements. The commenters noted that it is common to invest more effort in measuring a particular MU requirement than developing the associated capability. One commenter suggested that this criterion be made more granular. The commenter suggested that each measure requirement for a capability (e.g., CPOE or VDT) should be specified in the ‘‘automated measure calculation’’ certification criterion. Another commenter recommended making available different testing methods for this certification criterion, including scenario-based testing options. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition ‘‘automated measure calculation’’ certification criterion. We will, however, consider whether additional specificity is appropriate for ‘‘automated measure calculation’’ certification criteria, further evaluate the development effort associated with this certification criterion, and consider any potential alternative testing methods now and in relation to future rulemaking activity concerning an ‘‘automated measure calculation’’ certification criterion. Safety-Enhanced Design We proposed a ‘‘safety-enhanced design’’ (SED) certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did, however, solicit public comment regarding whether we should modify the certification criterion. Specifically, we requested comment regarding whether: PO 00000 Frm 00041 Fmt 4701 Sfmt 4700 54469 • The scope of SED should be expanded to include additional certification criteria; • Formative usability tests should be explicitly required, or used as substitutes for summative testing; • There are explicit usability tests that should be required in addition to summative testing; and • There should be a minimum number of test subjects explicitly required for usability testing. Comments. We received many comments in response to our request for comments. Commenters suggested expanding the certification criteria covered in this criterion to criteria covering laboratory exchange, problems, and other areas. Conversely, other commenters recommended not expanding the certification criteria covered by the SED criterion. Commenters were both for and against using actual formative usability tests with some suggesting testing to certain usability standards. Some commenters also suggested that there be a minimum number of test subjects, with a few commenters emphasizing that the test subjects and process should be objective. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition ‘‘safety-enhanced design’’ certification criterion. We will, however, consider all the thoughtful comments we received regarding expanding the scope and testing of the SED certification criterion in relation to future rulemaking activity concerning a SED certification criterion. We note that we have revised the 2014 Edition SED certification criterion (§ 170.314(g)(3)) to include the three optional CPOE certification criteria and the optional CIRI certification criterion. We discuss these revisions in further detail under the discussions of CPOE and CIRI in section III.A.2 of this preamble. Quality Management System We proposed a ‘‘quality management system’’ certification criterion for the Proposed Voluntary Edition that was unchanged as compared to the 2014 Edition certification criterion. We did E:\FR\FM\11SER2.SGM 11SER2 54470 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations tkelley on DSK3SPTVN1PROD with RULES2 not request any specific public comments on this certification criterion. Comments. Commenters expressed support for the proposed certification criterion as unchanged. One commenter suggested that we remove this certification criterion for the proposed edition and any future editions until the Food and Drug Administration Safety and Innovation Act (FDASIA) health care IT regulatory framework has been established and implemented. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As proposed, this certification criterion would offer no value as an optional 2014 Edition certification criterion because it would be the same as the current 2014 Edition ‘‘quality management system’’ certification criterion. As with all stakeholder feedback, we appreciate the comments submitted, including the recommendation to remove this certification criterion from future editions. We will consider the FDASIA Health IT Report,47 including a published final report, in future rulemaking activity concerning a ‘‘quality management system’’ certification criterion. Non-Percentage-Based Measures Report We proposed a new ‘‘non-percentagebased measures report’’ certification criterion for the Proposed Voluntary Edition. Specifically, we proposed to adopt a new certification criterion 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 for ‘‘nonpercentage-based measure use report,’’ but subsequently did not adopt the criterion in the 2014 Edition Final Rule based on commenters’ concerns that additional specificity would be needed to make the proposed criterion more effective. In the Proposed Rule, we stated that we continue to believe that EPs, EHs and CAHs could benefit from EHR technology that could electronically report non-percentage47 https://www.healthit.gov/sites/default/files/ fdasia_healthitreport_final.pdf. VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 based MU objectives and measures, and we have also received feedback from OIG and comments in response to a MU Stage 3 Request For Comment 48 echoing this need. Therefore, we proposed a new criterion that is more specific than the one proposed in the 2014 Edition NPRM and recognizes that certain aspects of ‘‘use’’ associated with non-percentagebased measures will occur in different ways based on the particular EHR capability involved. 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 requested 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 this final rule’s preamble to provide more examples of what evidence would be acceptable. If we were to make the regulatory text more specific, we proposed two options, but also solicited 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. We believe the proposed criterion provides EHR technology developers with substantial flexibility to create innovative approaches to document evidence of use. The proposed criterion would apply to only those nonpercentage-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 illustrate which certification criteria support one or more non-percentage-based measures, we provided a table (79 FR 10912) in the Proposed Rule. As described in the Proposed Rule, we also proposed not to 48 The Request for Comments is available at: https://www.healthit.gov/sites/default/files/hitpc_ stage3_rfc_final.pdf. PO 00000 Frm 00042 Fmt 4701 Sfmt 4700 include the proposed ‘‘drug-formulary checks’’ and ToC certification criteria within the scope of this criterion because the corresponding MU measures already provide evidence of use. We also proposed that all the proposed privacy and security certification criteria of the Proposed Voluntary Edition should not be included within the scope of this certification criterion because EHR technology would not 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 need to have new certification responsibilities if we were to adopt this proposed criterion. As a result, we also proposed to revise § 170.550. This proposed 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 proposed certification criterion. Comments. We received mixed comments regarding the proposal to adopt a new certification criterion to generate reports for non-percentagebased EHR capabilities. Some commenters supported the new criterion for all of the seven certification criteria we presented in the table (79 FR 10912).49 However, some commenters stated that this requirement would only be feasible or preferable for a subset of the proposed certification criteria. One commenter opined that this functionality was feasible for drug-drug, drug-allergy interaction checks and CDS, but for the rest of the certification criteria, it would be difficult to build this functionality on a user-level. Another commenter recommended adopting this functionality only to support CDS. One commenter recommended the requirement be that EHRs be able to perform this function for three out of the six proposed certification criteria to lessen the administrative burden. Commenters that opposed adopting the proposed criterion expressed that the reason for not adopting this criterion in the 2014 Edition still holds (i.e., 49 Drug-drug, drug-allergy interaction checks; clinical decision support; patient list creation; transmission to immunization registries; transmission of syndromic surveillance data to public health agencies; transmission of reportable lab tests and values/results to public health agencies; and transmission to cancer registries. E:\FR\FM\11SER2.SGM 11SER2 tkelley on DSK3SPTVN1PROD with RULES2 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations additional specificity is needed to make the proposed criterion more effective). Many commenters stated that providers can, and currently do, attest to the nonpercentage-based MU objectives without the EHR having to monitor or ‘‘police’’ the provider’s interactions with the EHR. Commenters were also concerned that building this functionality will be a major development undertaking and will have to be custom-built for each certification criterion. Commenters provided specific examples of the challenges in building this functionality for certain certification criteria. For example: • For CDS interventions, EHR systems vary in their configurations that determine how often interventions are seen. EHR developers who currently track this information note that the data volumes can be very large, and that retention of large volumes of data over extended periods of time can have performance and hardware implications. • For the public health certification criteria, it is possible that an EHR user is connected and submitting appropriate information but may not have submissions within a particular reporting period. Multiple transport methods and methodologies can introduce challenges to implementing this functionality in a standard way. What is defined as ‘‘ongoing submission’’ can vary and human judgment is required to make the determination (e.g., data is sent using different procedures like real-time or periodic uploads). Thus, some commenters were concerned that an auditor could review the ‘‘non-percentage-based measures report’’ and incorrectly conclude that the EP, EH, or CAH failed the CDS objective if none of the implemented CDS rules/interventions were triggered during the reporting period. Another commenter recommended changing the regulatory text that as proposed would require an EHR to ‘‘electronically record evidence that a user used or interacted with the capability . . .’’ The commenter stated that the use of the word ‘‘evidence’’ implies too strong of a legal ramification and that the EHR can only indicate when different features or options were triggered or activated within the EHR, but not that a user did or did not properly act upon the MU-related feature. A few commenters were opposed to Option 1, which would require EHR technology to record evidence of use each time a particular capability was used during the reporting period. One VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 commenter stated that there are no standards to support reporting of this type of information. Another commenter suggested that Option 1 would result in large amounts of data that would require additional storage space. One commenter supported Option 2 and agreed with the need to show that certain functionalities were enabled in the system during the reporting period. Response. There was mixed feedback on which certification criteria this functionality would be required to support. We agree with comments stating that this functionality would vary in support of different certification criteria, and believe that more work is needed to further refine our proposal. Since the overall scope of this final rule focuses on the adoption of a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and includes revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange, we do not believe it is appropriate to adopt this new certification criterion at this time. Our experience with the certification of EHR technology to the 2014 Edition suggests that EHR technology developers have already implemented or are in the process of implementing their certified software with providers and hospitals, and it is unlikely that EHRs would be updated with this new functionality in time to positively affect reporting for non-percentage-based functions. Thus, we will consider the comments received on feasibility, implementation, the regulatory text, and frequency of recording data on use of particular capabilities for future rulemaking concerning a ‘‘non-percentage-based measures report’’ certification criterion. Applicability Statement for Secure Health Transport and Delivery Notification in Direct We proposed to adopt a new certification criterion for electronic sending and receiving 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 § 170.202(a) and its companion implementation specification (Implementation Guide for Delivery Notification in Direct, Version 1.0, June 29, 2012 (Delivery Notification IG)).50 50 https://wiki.directproject.org/file/view/ Implementation+Guide+for+Delivery+Notification+ in+Direct+v1.0.pdf. PO 00000 Frm 00043 Fmt 4701 Sfmt 4700 54471 Comments. Some commenters supported the goal of acknowledging receipt of the documents by the intended recipient. Commenters also voiced concern that this was a new area of certification that lacked HIT developer feedback and recommended that we further consider this certification criterion before finalizing it. Other commenters stated that the depth of information required to be reported to the sender of information would cause significant burden on HIT developers to create the functionality and providers and health care organizations to use the functionality. One commenter noted that, as the market matured, demand for this kind of functionality would increase and HIT developers would design these functions without the need of a certification criterion. Response. We have not adopted this certification criterion because we have not adopted the Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. We will, however, consider comments regarding the Delivery Notification IG capabilities, the concerns expressed by commenters, and evaluate whether the market demand for this capability would moot the benefit that certification could provide for proof of a consistent implementation according to the IG as part of future rulemaking. B. 2014 Edition and Proposed Voluntary Edition Equivalency Table In the Proposed Rule, we provided an ‘‘equivalency table’’ (79 FR 10915–16) that identified the Proposed Voluntary Edition EHR certification criteria that were equivalent to the 2014 Edition certification criteria for the purposes of meeting the CEHRT definition. There is no longer a need for an ‘‘equivalency table’’ because we have not adopted the Proposed Voluntary Edition in this final rule. Therefore, we have not included an ‘‘equivalency table’’ in this final rule. C. HIT Definitions 1. CEHRT We proposed to revise the CEHRT definition for FY/CY 2014 and subsequent years to include reference to the Proposed Voluntary Edition as a means of giving EPs, EHs, and CAHs the flexibility to use EHR technology that has been certified to either the 2014 Edition or the Proposed Voluntary E:\FR\FM\11SER2.SGM 11SER2 54472 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations Edition, or a combination of both editions, to meet the CEHRT definition for FY/CY 2014 and subsequent years. Comments. We received many comments recommending that we do not adopt the Proposed Voluntary Edition. Response. We have not revised the CEHRT definition. In response to comments recommending that we not adopt the Proposed Voluntary Edition and for the other reasons discussed earlier in this preamble, we have not adopted the full Proposed Voluntary Edition. Rather, we have only adopted a small subset of the proposed certification criteria as optional 2014 Edition EHR certification criteria and made revisions to 2014 Edition EHR certification criteria that provide flexibility, clarity, and enhance health information exchange. As such, no revisions are necessary to the CEHRT definition to account for the additional optional 2014 Edition EHR certification criteria. 2. Common MU Data Set We proposed to revise the Common MU Data Set definition in § 170.102 by including the preferred language standard in the proposed ‘‘demographics’’ certification criterion solely for the purposes of certifying EHR technology to the Proposed Voluntary Edition EHR certification criteria that referenced the Common MU Data Set. Comments. We received comments recommending that we not adopt a new preferred language standard as well as comments on each of the standards we proposed as the potential new preferred language standard. Response. We have not adopted a revised or new demographics certification criterion or a new preferred language standard consistent with our reasons for not adopting the Proposed Voluntary Edition and for the reasons discussed in more detail under the ‘‘demographics’’ certification criterion in section IV.A. Accordingly, we have not finalized our proposal to revise the Common MU Data Set definition. C. ONC HIT Certification Program tkelley on DSK3SPTVN1PROD with RULES2 1. Non-MU EHR Technology Certification We proposed to establish an ‘‘MU EHR Module’’ definition and a ‘‘nonMU EHR Module’’ definition under the main ‘‘EHR Module’’ definition at § 170.102. We proposed to define an ‘‘MU EHR Module’’ as any service, component, or combination thereof that is designed for purposes of the Medicare and Medicaid EHR Incentive Programs and can meet the requirements of at VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 least one certification criterion adopted by the Secretary. We proposed to define a ‘‘non-MU EHR Module’’ as any service, component, or combination thereof that is designed for any purpose other than the Medicare and Medicaid EHR Incentive Programs and can meet the requirements of at least one certification criterion adopted by the Secretary. Correspondingly, we proposed to revise § 170.550 to require the certification of only MU EHR Modules, as applicable, to the Proposed Voluntary Edition ‘‘automated numerator recording’’ certification criterion, the ‘‘automated measure calculation’’ certification criterion, and the ‘‘non-percentage-based measure use report’’ certification criterion. We stated that these proposals would ensure that EHR technology designed for MU purposes and certified to certification criteria that include capabilities that support percentagebased and/or non-percentage-based MU measures are capable of electronically performing the associated recording and calculation of measure activities for MU purposes, while permitting EHR technology that is designed for non-MU purposes (e.g., broad electronic health information exchange or behavioral health settings staffed mainly by MU ineligibles) to be certified without having to include capabilities that support percentage-based and/or nonpercentage-based MU measures. These proposals were based on our belief that EHR technology developers who design EHR technology for non-MU purposes and settings find that the MU measurement certification criteria requirements are unnecessary burdens and resource investments (i.e., to have to program MU-specific rules into their software just to get certified). Similarly, we noted that because of the specific ways in which MU measures are structured non-MU health care providers would find little benefit in receiving EHR utilization reports showing MU performance. In the Proposed Rule, we specifically requested comment on these assumptions and on how best to implement our proposed approach if we were to adopt it in this final rule (e.g., requested comments on what processes we should use for testing and certification and distinguishing MU and non-MU EHR Modules on the CHPL) (79 FR 10919–20). Overall, as stated in the Proposed Rule, we saw these proposals as a first step towards the expansion of the ONC HIT Certification Program to accommodate other types of HIT (79 FR 10930). To note, as stated in the Proposed Rule, we did not propose to PO 00000 Frm 00044 Fmt 4701 Sfmt 4700 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. Comments. We received comments supporting our proposal not to require ‘‘non-MU’’ technologies to be certified to certification criteria designed to support MU measurement. We also received a significant number of comments expressing concern that our proposals would cause confusion. Commenters suggested that designations and concepts such as ‘‘MU,’’ ‘‘non-MU,’’ and ‘‘beyond MU purposes’’ would add complexity and confusion to an already strained marketplace. A few commenters stated that we need to also account for non-EHR technologies. Another commenter suggested that we not rely on assumptions about the differences in technology needs between providers that are eligible for MU incentive payments and those that are ineligible. As an example, the commenter suggested that the numerator and denominator calculations may, in fact, be useful to providers that are not eligible for MU incentive payments for patient safety tracking and other purposes. Response. In consideration of comments and our overall goal to expand the ONC HIT Certification Program to accommodate other types of HIT, we have decided not to adopt any of these proposals. Upon further reflection, we believe these proposals may not clearly and appropriately move us away from a certification program currently focused on MU. By using terminology such as ‘‘MU’’ and ‘‘nonMU,’’ we only reinforce the MU-aspect of the ONC HIT Certification Program. Further, as noted by commenters, our proposals could confuse providers and may not be based on sound assumptions such as MU-ineligible providers not finding value in some of the capabilities that support MU measurement as noted by a commenter. Accordingly, with consideration of comments that supported our stated goal and recommended that we address non-EHR technologies, we will further consider how best to restructure the ONC HIT Certification Program to move it beyond MU in preparation for our next rulemaking. To reaffirm, as our request for comment indicated in the Proposed Rule (79 FR 10929–30), we intend to propose changes to the ONC HIT E:\FR\FM\11SER2.SGM 11SER2 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations tkelley on DSK3SPTVN1PROD with RULES2 Certification Program that will permit the certification of other types of HIT and the certification of HIT for other specific types of health care settings (i.e., beyond the general ambulatory and general inpatient settings). For now, we direct stakeholders to our guidance for EHR technology developers serving providers ineligible for the EHR Incentive Programs titled ‘‘Certification Guidance for EHR Technology Developers Serving Health Care Providers Ineligible for Medicare and Medicaid EHR Incentive Payments.’’51 2. ‘‘Certification Packages’’ for EHR Modules We proposed to establish the concept of predefined ‘‘certification packages’’ that would reflect groupings of certification criteria. We stated that our proposal was intended to improve the ease with which our regulatory concepts could be communicated to the general public and to EHR Module purchasers. More specifically, we stated that this concept would make it easier for stakeholders to communicate and understand the functionality an EHR Module includes and the certification criteria to which it is certified. We proposed to define ‘‘certification package’’ in § 170.502 as an identified set of certification criteria adopted by the Secretary in subpart C of part 170 that represent a specific grouping of capabilities. For EHR Modules certified to the Proposed Voluntary Edition, we proposed definitions in § 170.502 for ‘‘2015 Edition Care Coordination Package’’ and ‘‘2015 Edition Patient Engagement Package’’ that each identified the set of specific certification criteria to which an EHR Module would need 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. We further sought comment on what certification criteria should be included in the care coordination and patient engagement packages. We also clarified that if an EHR Module were certified to the certification criteria included in a proposed 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. However, to ensure that certification packages would be represented accurately to potential purchasers and users of EHR Modules, we proposed to modify § 170.523(k)(1) to require ONC–ACBs to ensure that an 51 https://www.healthit.gov/sites/default/files/ generalcertexchangeguidance_final_9-9-13.pdf. VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 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. We further clarified 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 satisfied the certification criteria included in each of the proposed certification packages and was also certified to other certification criteria, it could be so indicated by the EHR Module developer to its customers. Comments. We received only three comments that supported our proposals. However, the commenters submitting these comments misconstrued our proposals as either a new required type of certification for EHR Modules to the Proposed Voluntary Edition or as an additional requirement beyond initial certification, such as specifically requiring additional functionality for ‘‘care coordination.’’ All other commenters did not support our proposals. These commenters disagreed with our rationale that our approach would provide clarity for stakeholders. Rather, commenters stated that our approach would cause more confusion than it would solve. Commenters noted that one individual’s definition of ‘‘care coordination’’ may not be the same as another, which could lead to misunderstandings about what is or is not included in the EHR technology. Commenters also noted that there are a large number of possible combinations of certification criteria and associated capabilities that could plausibly be called ‘‘care coordination’’ (e.g., inclusion of lab exchange certification criteria and capabilities) and patient engagement (e.g., inclusion of the ‘‘clinical summary’’ certification criterion). The commenters opined that the certification criteria included in the proposed packages seemed arbitrary and not applicable to all providers. Commenters suggested that we focus on educating providers, particularly those ineligible for the EHR Incentive Programs, as to what types of certified capabilities providers should look for in a certified technology. In this regard, one commenter suggested that we rely PO 00000 Frm 00045 Fmt 4701 Sfmt 4700 54473 on and educate more providers on our guidance titled ‘‘Certification Guidance for EHR Technology Developers Serving Health Care Providers Ineligible for Medicare and Medicaid EHR Incentive Payments.’’ 52 A few commenters also mentioned that certified technologies should be properly labeled as to the certification criteria and associated capabilities they include. Response. We have not finalized our proposals for the ‘‘care coordination’’ and ‘‘patient engagement’’ packages. We clarify that our ‘‘certification packages’’ proposals did not require a new type of certification or additional functionality for EHR Modules. Under the proposals, an EHR Module would not have been required to be certified to the certification criteria specified in a certification package, and an EHR Module could have been certified to more certification criteria than were included in a certification package. Our proposal was designed such that an EHR Module developer could assert (e.g., for communications and marketing purposes) that its EHR Module met a certification package if the EHR Module had been certified to all of the certification criteria included in a certification package without any additional determination made by an ONC–ACB. However, given the comments received from commenters that clearly understood our proposals, we have not adopted ‘‘certification package’’ as a concept and definition in § 170.502 nor have we finalized a requirement under § 170.523(k)(1) that an ONC–ACB ensure that an EHR Module developer accurately represents the certification packages its EHR Module meets. We agree with commenters that our proposed ‘‘certification packages’’ could have ended up creating more confusion than they solved, and that there are no definitive certification criteria that meet the concept of ‘‘care coordination’’ and ‘‘patient engagement’’ for all providers. As recommended by commenters, we will try to further educate providers on the capabilities included in certification criteria, the means for determining what capabilities a certified EHR Module includes (e.g., utilizing the CHPL and reviewing an EHR technology developer’s communications and marketing materials, which should include a list of the certification criteria and CQMs that the EHR Module was certified to), and on the ‘‘Certification Guidance for EHR Technology Developers Serving Health Care Providers Ineligible for Medicare and 52 https://www.healthit.gov/sites/default/files/ generalcertexchangeguidance_final_9-9-13.pdf. E:\FR\FM\11SER2.SGM 11SER2 54474 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations Medicaid EHR Incentive Payments’’ guidance we issued in 2013. V. Comments Beyond the Scope of This Final Rule In response to the Proposed Rule, some commenters chose to raise issues that are beyond the scope of our proposals such as encouraging us to amend our certification criteria to include EHR accessibility for users with disabilities. We do not summarize or respond to those comments in this final rule. However, we will review the comments and consider whether other actions may be necessary, such as addressing the comments in future rulemakings. VI. Collection of Information Requirements This final rule contains no new collections of information under the Paperwork Reduction Act nor does it revise any current collection of information approved by OMB. VII. Regulatory Impact Statement A. Statement of Need Consistent with EO 13563, we have completed a retrospective review of our 2014 Edition Final Rule and the certification criteria we adopted in that final rule. Further, consistent with EO 13563, we have only adopted the proposed certification criteria as part of the 2014 Edition that provide regulatory flexibility and reduce regulatory burden for stakeholders. tkelley on DSK3SPTVN1PROD with RULES2 B. Overall Impact We have examined the impact of this final rule as required by EO 12866 on Regulatory Planning and Review (September 30, 1993), EO 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 EO 13132 on Federalism (August 4, 1999). 1. Executive Orders 12866 and 13563— Regulatory Planning and Review Analysis EOs 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 VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 this final rule is not an economically significant rule. Related costs to prepare EHR technology and other HIT to be tested and certified are estimated to be far less than $100 million per year. Nevertheless, because of the public interest in this final rule, we have prepared an RIA that to the best of our ability presents the costs and benefits of this final rule. a. Costs This final rule adopts new optional certification criteria and revised certification criteria as part of the 2014 Edition. Our analysis focuses on the direct effects of the provisions of this final 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 to certify to the new optional certification criteria and revised certification criteria and for developing new EHR technology to meet the new optional certification criteria and revised certification criteria. The costs for testing and certification of EHR technologies to the certification criteria adopted in this final rule were captured in the RIA of the Permanent Certification Program final rule as we discuss in more detail below (VI.B.1.a.ii ‘‘Testing and Certification Costs for the 2014 Edition Release 2’’). The costs that EPs, EHs, and CAHs will incur in adopting and implementing EHR technology certified to the certification criteria adopted in this final rule are not within the scope of this final rule. i. Development and Preparation Costs for the 2014 Edition Release 2 In the Proposed Rule (79 FR 10932– 36), we estimated the development and preparation costs for the Proposed Voluntary Edition. We categorized proposed certification criteria based on their gap certification status (i.e., new, revised, and unchanged). We used the total number of unique 53 2011 Edition Complete EHRs and EHR Modules that were used for MU Stage 1 attestation as reported at the end of FY 2013.54 Using 53 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. 54 For the Proposed Voluntary Edition certification criteria that did 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. PO 00000 Frm 00046 Fmt 4701 Sfmt 4700 the unique number of 2011 Edition EHR technologies used for MU Stage 1 attestation we established a range of between 20% and 40% of unique EHR technologies used for MU Stage 1 that we believed would be developed and prepared to meet each of the certification criteria of the Proposed Voluntary Edition. This range accounted for 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 reorganizations (e.g., mergers and acquisitions) as well as the loss of market share for some EHR technologies. The range also took into account any potential non-MU-focused EHR technologies that will be developed and prepared to meet the Proposed Voluntary Edition, but not designed for MU purposes. We identified three levels of effort to associate with the development and preparation of EHR technology to meet the requirements of the Proposed Voluntary Edition.55 We based the effort levels on the hours necessary for a software developer to develop and prepare the EHR technology for testing and certification and calculated the average software developer’s wage with benefits at $61 per hour.56 We calculated a low cost estimate, high cost estimate, and average cost estimate for each proposed certification criterion and then estimated the totals equally split between 2014 and 2015.57 Comments. We received very limited comments on our proposed impact analysis, all of which came from EHR technology developers and reiterated the detailed comment that came from the Electronic Health Record Association (EHRA). In its comments, the EHRA presented average hourly burden estimates that would be incurred by an EHR technology developer per proposed certification criterion. The EHRA indicated that its estimates presumed a product was already certified to 2014 Edition certification criteria and included ‘‘research, planning and design, development, testing, usability testing, documentation, release, and certification effort.’’ Additionally, a follow-up request for clarification and fact finding indicated that these hourly estimates included an average of 2.5 products per EHR technology developer that would be certified to the certification criteria of the Proposed Voluntary Edition. Overall, the EHRA 55 79 FR 10932–33. FR 10933. 57 79 FR 10933–36. 56 79 E:\FR\FM\11SER2.SGM 11SER2 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations generally concluded that we had, in most cases, significantly underestimated the hourly burden associated with the proposed certification criteria and provided a detailed chart identifying the potential discrepancies. Response. We appreciate the detailed response provided by the EHR technology developer community. In reviewing the provided comments, it became clear that the way in which we were presenting the calculation of our impacts in the preamble and the way in which EHR technology developers think about the impacts were different. In other words, our approach in the Proposed Rule was to assign burden hours to each certified product listed on the CHPL by certification criterion and we never provided a ‘‘per EHR technology developer’’ estimate. However, in contrast, the EHRA estimates were burden hours by EHR technology developer for each certification criterion. On face value, for example, if one were to compare the ‘‘Level 2 range’’ we included in the Proposed Rule of 100– 300 hours without multiplying by the number of products on the CHPL attributable to a particular EHR technology developer it would appear that we did significantly underestimate the burden. However, if one were to multiply that 100–300 hour range by the number of products attributable to a particular EHR technology developer and that were certified to the certification criterion in question a potentially narrower gap in the estimates could result. After considering these comments, we believe that a more direct way for this final rule and for future rulemakings to identify burden will be to identify hourly burden estimates for each certification criterion by EHR technology developer. Given the reduced scope of this final rule, we do not include hourly cost estimates for certification criteria that we are not finalizing. Table 4 indicates only the regulatory changes we have finalized for the adopted certification criteria and our hourly burden estimate range for each of the changes by EHR technology developer. We also include an estimated number of EHR technology developers that we believe will seek certification to these certification criteria (and built into this assumption is that they would be presenting on average 3 products for certification, similar to EHRA’s number). To arrive at this estimate, we analyzed available CHPL data from mid- 54475 May of this year for 2014 Edition certifications. From this data, we determined how many EHR technology developers had at least one product certified to the adopted 2014 Edition. From the group of EHR technology developers with a product certified to the 2014 Edition, we estimate that no more than 20% of those developers will seek certification because of the reduced and specific scope of this final rule. We also believe that for some certification criteria the 20% estimate could be a substantial overestimation. We provide a more detailed criterion-by-criterion explanation of our estimates below in Table 4. Additionally, despite the specificity included in the EHRA estimates, we have found from past experience that at times EHR technology developers have misinterpreted what we have proposed. The EHRA’s comments noted this kind of discrepancy by stating for certain certification criteria that some of its members interpreted the burden to be reasonably low while others very high. Given that we have no other comments by which to compare the EHRA estimates, we have generally used the EHRA estimate as our ‘‘high average’’ rounded up or down to the nearest hundred hours. TABLE 4—DEVELOPMENT AND PREPARATION COSTS FOR EHR TECHNOLOGY DEVELOPERS FOR ADOPTED CERTIFICATION CRITERIA Item # 1 2 3 4 5 6 7 ................... ................... ................... ................... ................... ................... ................... CFR Text Certification criterion name § 170.314(a)(18) .. § 170.314(a)(19) .. § 170.314(a)(20) .. § 170.314(b)(8) .... § 170.314(b)(9) .... § 170.314(e)(1) .... § 170.314(f)(7) ..... § 170.314(g)(1) § 170.314(g)(3) § 170.314(h)(1) § 170.314(h)(2) 12 ................. tkelley on DSK3SPTVN1PROD with RULES2 8 ................... 9 ................... 10 ................. 11 ................. § 170.314(h)(3) .... .... .... .... .... CPOE—medications ........................................................ CPOE—laboratory ........................................................... CPOE—diagnostic imaging ............................................. Transitions of care ........................................................... Clinical information reconciliation and incorporation ....... View, download, and transmit to 3rd party ...................... Transmission to public health agencies—syndromic surveillance. Automated numerator recording ...................................... Safety-enhanced design .................................................. Applicability Statement for Secure Health Transport ...... Applicability Statement for Secure Health Transport & XDR/XDM for Direct Messaging. SOAP Transport and Security Specification & XDR/ XDM for Direct Messaging. • Items #1 through #3: With the exception of splitting out the three CPOE order type functionalities, there are no new requirements as part of any of these three certification criteria in this final rule. As a result, we provided a low range estimate. • Item #4: For this certification criterion, the only substantial new VerDate Mar<15>2010 19:03 Sep 10, 2014 Number of EHR developers who develop product(s) for certification to criterion Jkt 232001 development change between it and the 2014 Edition certification criteria at § 170.314(b)(1) and (2) is the addition of the Direct Edge Protocols IG. The EHRA estimates did not clearly identify whether the hourly range of 1,380 hours was to implement all four edge protocols or some number of them. Regardless, given that we only require PO 00000 Frm 00047 Fmt 4701 Sfmt 4700 Hourly development effort by EHR developer Low avg High avg 33 33 33 29 27 33 25 0 0 0 400 0 400 0 100 100 100 600 100 600 100 N/A 77 33 33 N/A 0 300 200 N/A 100 500 300 33 200 300 one for certification, we have more than halved the EHRA estimate to fall into a range that we believe would be more reflective of the burden imposed by the final certification criterion. • Item #5: The EHRA did not provide any hourly estimate for new development, nor does this criterion substantively differ from already E:\FR\FM\11SER2.SGM 11SER2 54476 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations required capabilities in the 2014 Edition. As a result, we provided a low estimate. • Item #6: For this certification criterion, the only substantial new development change between it and the original 2014 Edition version is the addition of the IG for Direct Edge Protocols. As a result, our estimates are the same as for Item #4. • Item #7: Given the adoption of this more general certification criterion, we have provided a low estimate. • Item # 8: This certification criterion was simply changed to an ‘‘optional’’ designation to provide regulatory clarity for Complete EHR certification to the 2014 Edition. There should be no new cost estimates related to certification as this regulatory change simply implements ONC Regulation FAQ 28 as discussed in section III.B.3 of the preamble. • Item # 9: This certification criterion now includes the adopted optional CPOE and CIRI certification criteria. We have estimated a low cost range because we anticipate that EHR technology developers will use the same SED practices they used for certification to the CPOE (§ 170.314(a)(1)) and CIR (§ 170.314(b)(4)) certification criteria. Additionally, we note that we do not believe that there will be 99 different EHR technology developers that will get certified to the three CPOE criteria (i.e., 33 + 33 + 33). We expect that there will be overlap (i.e., multiple EHR technology developers getting certified to more than one CPOE certification criterion) and that some EHR technology developers will only get certified to one CPOE certification criterion such as CPOE—medications or CPOE— laboratory. Therefore, we estimate that there will be no more than 50 EHR technology developers that are certified to the SED certification criterion based on certification to the new optional CPOE certification criteria. We have combined this estimated number with the number of EHR technology developers we have estimated for the CIRI certification criterion to get an estimated total for this certification criterion. • Items #10–12: We provide estimates reasonably close to the EHRA estimates. Table 5 includes an overall 2-year cost estimate for each criterion. We retain the 2-year cost estimate period (CY 2014 and CY 2015) for the reason provided in the Proposed Rule as they would similarly apply to the adopted optional and revised 2014 Edition certification criteria. Additionally, we retain and use the estimate of $61 per hour (with benefits) as the average software developer’s wage. TABLE 5—DISTRIBUTED TOTAL DEVELOPMENT AND PREPARATION COSTS FOR EHR TECHNOLOGY DEVELOPERS (TWOYEAR PERIOD)—TOTALS ROUNDED Item # 1 2 3 4 5 6 7 .......................... .......................... .......................... .......................... .......................... .......................... .......................... Certification criterion name § 170.314(a)(18) § 170.314(a)(19) § 170.314(a)(20) § 170.314(b)(8) .. § 170.314(b)(9) .. § 170.314(e)(1) .. § 170.314(f)(7) ... ............................ ............................ ............................ 12 ........................ § 170.314(h)(3) .. .. .. .. .. tkelley on DSK3SPTVN1PROD with RULES2 iii. Testing and Certification Costs for the 2014 Edition Release 2 In the RIA 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.58 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 FR 1318. VerDate Mar<15>2010 Total average cost estimate ($M) $0 0 0 .71 0 .81 0 $.2 .2 .2 1.0 .16 1.22 .15 $.1 .1 .1 .89 .081 1.0 .077 N/A 0 .6 .4 N/A .47 1.0 .6 N/A .235 .8 .5 .4 .6 .5 2.92 1.46 5.80 2.90 4.38 2.19 1.46 2.90 2.19 ..................................................................................... § 170.314(g)(1) § 170.314(g)(3) § 170.314(h)(1) § 170.314(h)(2) 2-Year Total 2014 total (50%). 2015 total (50%). Total high cost estimate ($M) CPOE—medications ................................................... CPOE—laboratory ...................................................... CPOE—diagnostic imaging ........................................ Transitions of care ...................................................... Clinical information reconciliation and incorporation .. View, download, and transmit to 3rd party ................ Transmission to public health agencies—syndromic surveillance. Automated numerator recording ................................ Safety-enhanced design ............................................. Applicability Statement for Secure Health Transport Applicability Statement for Secure Health Transport & XDR/XDM for Direct Messaging. SOAP Transport and Security Specification & XDR/ XDM for Direct Messaging. ..................................................................................... ..................................................................................... 8 .......................... 9 .......................... 10 ........................ 11 ........................ 58 76 Total low cost estimate ($M) CFR Text 19:03 Sep 10, 2014 Jkt 232001 actual testing and certification of EHR technologies to both the 2014 Edition and the certification criteria we have adopted as part of the 2014 Edition Release 2. This assessment is based on the number of EHR technologies currently certified to the 2014 Edition and our projections for the number of EHR technology developers that would likely have their EHR technologies tested and certified to the optional and revised 2014 Edition certification criteria adopted in this final rule. Further, we note that the estimated costs in the Permanent Certification Program final rule included costs for surveillance of EHR technologies and also estimated PO 00000 Frm 00048 Fmt 4701 Sfmt 4700 the costs for testing and certification above what we understand are the cost ranges charged by ONC–ACBs today. b. Benefits The regulatory flexibility the 2014 Edition Release 2 certification criteria provide will offer several significant benefits to patients, health care providers, and HIT developers. The 2014 Edition Release 2 incorporates stakeholder feedback on particular 2014 Edition issues identified as unnecessarily impeding innovation and causing undue burden. The 2014 Edition Release 2 also seeks to continue to improve EHR technology’s interoperability and electronic health E:\FR\FM\11SER2.SGM 11SER2 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations tkelley on DSK3SPTVN1PROD with RULES2 information exchange. Specifically, the separating out of the ‘‘content’’ and ‘‘transport’’ capabilities in the optional 2014 Edition ToC certification criterion (compared to the 2014 Edition ToC certification criteria adopted at § 170.314(b)(1) and (2)) and adoption of the Edge Protocol IG is aimed at improving the market availability of electronic health information exchange services. The new certification flexibilities offered by the optional ‘‘CPOE’’ and optional ‘‘syndromic surveillance’’ certification criteria are designed to enhance innovation and offer providers enhanced functionality and options for meeting applicable MU measures. The new flexibility in the VDT certification criterion is designed to further facilitate the exchange of patient health information between provider and patient. The optional CIRI criterion is designed to align better with clinical workflows and reduce regulatory burden found in certification to the current ToC certification criterion at § 170.314(b)(1). 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 final 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 59 which ‘‘indicates the maximum allowed for a concern and its affiliates to be considered small entities.’’ 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 59 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. VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 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 optional 2014 Edition Release 2 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. We estimate that this final 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 final rule. We note that this final rule does not impose the costs cited in the RIA as compliance costs, but rather as investments which these EHR technology developers voluntarily take on and expect to recover with an appropriate rate of return. Accordingly, we do not find that this final rule will create a significant impact on a substantial number of small entities. Additionally, the Secretary certifies that this final 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 PO 00000 Frm 00049 Fmt 4701 Sfmt 4700 54477 otherwise has federalism implications. Nothing in this final 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 certification criteria or other proposals we have adopted in this final rule. 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 final rule will not impose an unfunded mandate on state, local, and tribal governments or on the private sector that will reach the threshold level. Regulation Text 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 recordkeeping requirements, Public health, Security. For the reasons set forth in the preamble, 45 CFR subtitle A, subchapter D, part 170, is amended as follows: PART 170—HEALTH INFORMATION TECHNOLOGY STANDARDS, IMPLEMENTATION SPECIFICATIONS, AND CERTIFICATION CRITERIA AND CERTIFICATION PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY 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. 2. Section 170.102 is amended by revising the definition for ‘‘Base EHR’’ to read as follows: ■ § 170.102 Definitions. * * * * * 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; E:\FR\FM\11SER2.SGM 11SER2 54478 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations (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: (i) For at least one of the four criteria adopted at § 170.314(a)(1), (a)(18), (a)(19), or (a)(20); (ii) At § 170.314(a)(3); (iii) At § 170.314(a)(5) through § 170.314(a)(8); (iv) Both § 170.314(b)(1) and (2); or, both § 170.314(b)(8) and § 170.314(h)(1); or § 170.314(b)(1) and (2) combined with either § 170.314(b)(8) or § 170.314(h)(1), or both § 170.314(b)(8) and § 170.314(h)(1); (v) At § 170.314(b)(7); (vi) At § 170.314(c)(1) through § 170.314(c)(3); (vii) At § 170.314(d)(1) through § 170.314(d)(8); (4) Has been certified to the certification criteria at § 170.314(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. * * * * * § 170.102 [Amended] 3. Section 170.102 is further amended, effective March 1, 2015, by removing the definitions of ‘‘2011 Edition EHR certification criteria’’ and ‘‘Complete EHR, 2011 Edition.’’ ■ 4. Section 170.202 is amended by adding paragraph (d) to read as follows: ■ § 170.202 Transport standards. tkelley on DSK3SPTVN1PROD with RULES2 * * * * * (d) Standard. ONC Implementation Guide for Direct Edge Protocols (incorporated by reference in § 170.299). § 170.205 [Amended] 5. Section 170.205 is amended, effective March 1, 2015, by removing and reserving paragraphs (b)(1), (c), (d)(1), (e)(1) and (2), and (f). ■ VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 § 170.207 [Amended] 6. Section 170.207 is amended, effective March 1, 2015, by removing and reserving paragraphs (a)(1) and (2), (b)(1), (c)(1), (d)(1), and (e)(1). ■ § 170.210 [Amended] 7. Section 170.210 is amended, effective March 1, 2015, by removing and reserving paragraphs (a)(2) and (b). ■ 8. Section 170.299 is amended by adding paragraph (k)(4) to read as follows: ■ § 170.299 Incorporation by reference. * * * * * (k) * * * (4) ONC Implementation Guide for Direct Edge Protocols, Version 1.1, June 25, 2014, IBR approved for § 170.202; available at https://www.healthit.gov/ sites/default/files/implementationguide fordirectedgeprotocolsv1_1.pdf. * * * * * § 170.302 [Removed and Reserved] 9. Section 170.302 is removed and reserved, effective March 1, 2015. ■ § 170.304 [Removed and Reserved] 10. Section 170.304 is removed and reserved, effective March 1, 2015. ■ § 170.306 [Removed and Reserved] 11. Section 170.306 is removed and reserved, effective March 1, 2015. ■ 12. Section 170.314 is amended by: ■ a. Revising paragraph (a)(1)(iii); ■ b. Adding paragraphs (a)(18) through (20) and (b)(8) and (9); ■ c. Revising paragraphs (e)(1)(i)(C)(1) and (2); ■ d. Adding paragraph (f)(7); ■ e. Revising paragraphs (g)(1) and (3); and ■ f. Adding paragraph (h). The revisions and additions read as follows: ■ § 170.314 2014 Edition electronic health record certification criteria. * * * * * (a) * * * (1) * * * (iii) Diagnostic imaging. * * * * * (18) Optional—computerized provider order entry—medications. Enable a user to electronically record, change, and access medication orders. (19) Optional—computerized provider order entry—laboratory. Enable a user to electronically record, change, and access laboratory orders. (20) Optional—computerized provider order entry—diagnostic imaging. Enable a user to electronically record, change, and access diagnostic imaging orders. PO 00000 Frm 00050 Fmt 4701 Sfmt 4700 (b) * * * (8) Optional—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 § 170.202(d) and that leads to such summaries being processed by a service that has implemented the standard specified in § 170.202(a); and (B) Receive transitions of care/referral summaries through a method that conforms to the standard specified at § 170.202(d) from a service that has implemented the standard specified in § 170.202(a). (ii)(A) Display. 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: § 170.205(a)(1) through (3). (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 § 170.205(a)(3). (iii) Create. Enable a user to electronically create a transition of care/ referral summary formatted according to the standard adopted at § 170.205(a)(3) that includes, at a minimum, the Common MU Data Set and the following data expressed, where applicable, according to the specified standard(s): (A) Encounter diagnoses. The standard specified in § 170.207(i) or, at a minimum, the version of the standard specified § 170.207(a)(3); (B) Immunizations. The standard specified in § 170.207(e)(2); (C) Cognitive status; (D) Functional status; (E) Ambulatory setting only. The reason for referral; and referring or transitioning provider’s name and office contact information; and (F) Inpatient setting only. Discharge instructions. (9) Optional—clinical information reconciliation and incorporation—(i) Correct patient. Upon receipt of a transition of care/referral summary formatted according to the standard adopted at § 170.205(a)(3), 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. E:\FR\FM\11SER2.SGM 11SER2 tkelley on DSK3SPTVN1PROD with RULES2 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations (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 § 170.207(d)(2); (2) Problems. At a minimum, the version of the standard specified in § 170.207(a)(3); (3) Medication allergies. At a minimum, the version of the standard specified in § 170.207(d)(2). * * * * * (e) * * * (1) * * * (i) * * * (C) * * * (1) Electronically transmit 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 at least one of the following: (i) The standard specified in § 170.202(a). (ii) Through a method that conforms to the standard specified at § 170.202(d) and that leads to such summary being processed by a service that has implemented the standard specified in § 170.202(a). (2) 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 at least one of the following: (i) The standard specified in § 170.202(a). (ii) Through a method that conforms to the standard specified at § 170.202(d) and that leads to such summary being processed by a service that has implemented the standard specified in § 170.202(a). * * * * * VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 (f) * * * (7) Optional—Ambulatory setting only—Transmission to public health agencies—syndromic surveillance. EHR technology must be able to electronically create syndrome-based public health surveillance information for electronic transmission. (i) Optional. That contains the following data: (A) Patient demographics; (B) Provider specialty; (C) Provider address; (D) Problem list; (E) Vital signs; (F) Laboratory test values/results; (G) Procedures; (H) Medication list; and (I) Insurance. (ii) [Reserved] (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. * * * * * (3) Safety-enhanced design. Usercentered design processes must be applied to each capability an EHR technology includes that is specified in the following certification criteria: § 170.314(a)(1), (2), (6) through (8), (16) and (18) through (20) and (b)(3), (4), and (9). * * * * * (h) Transport methods—(1) Optional—Applicability Statement for Secure Health Transport. Enable health information to be electronically sent and electronically received in accordance with the standard specified in § 170.202(a). (2) Optional—Applicability Statement for Secure Health Transport and XDR/ XDM for Direct Messaging. Enable health information to be electronically sent and electronically received in accordance with the standards specified in § 170.202(a) and (b). (3) Optional—SOAP Transport and Security Specification and XDR/XDM for Direct Messaging. Enable health information to be electronically sent and electronically received in accordance with the standards specified in § 170.202(b) and (c). PO 00000 Frm 00051 Fmt 4701 Sfmt 4700 54479 Subpart D—[Removed and Reserved] 13. Remove and reserve subpart D, consisting of §§ 170.400 through 170.499. ■ 14. Section 170.501 is amended by designating the existing text as paragraph (a) and by adding paragraph (b) to read as follows: ■ § 170.501 Applicability. * * * * * (b) References to the term Complete EHR and Complete EHR certification throughout this subpart do not apply to certification in accordance with any edition of certification criteria that is adopted by the Secretary under subpart C after the 2014 Edition EHR certification criteria. ■ 15. Section 170.503 is amended by revising paragraphs (b)(1) and (e)(1) and (2) to read as follows: § 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 § 170.599) and experience evaluating the conformance of certification bodies to ISO/IEC 17065 (incorporated by reference in § 170.599). * * * * * (e) * * * (1) Maintain conformance with ISO/ IEC 17011 (incorporated by reference in § 170.599); (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 § 170.599); and (ii) For fiscal year 2016 and subsequent years, ISO/IEC 17065 (incorporated by reference in § 170.599). * * * * * ■ 16. Section 170.523 is amended by adding paragraph (l) to read as follows: § 170.523 Principles of proper conduct for ONC–ACBs. * * * * * (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 E:\FR\FM\11SER2.SGM 11SER2 54480 Federal Register / Vol. 79, No. 176 / Thursday, September 11, 2014 / Rules and Regulations and Terms of Use for the ONC Certified HIT Certification and Design Mark. 17. Section 170.550 is amended by revising paragraph (f)(1) to read as follows: ■ § 170.550 EHR Module certification. * * * * (f) * * * (1) Section 170.314(g)(1) or (2) if the EHR Module has capabilities presented for certification that would support a meaningful use objective with a percentage-based measure; * * * * * tkelley on DSK3SPTVN1PROD with RULES2 * VerDate Mar<15>2010 19:03 Sep 10, 2014 Jkt 232001 § 170.550 [Amended] 18. Section 170.550 is further amended, effective March 1, 2015, by removing and reserving paragraph (e). ■ 19. Section 170.599 is amended by revising paragraphs (b)(1) and (2) and adding paragraph (b)(3) to read as follows: ■ § 170.599 Incorporation by reference. * * * * * (b) * * * (1) ISO/IEC 17011:2004 Conformity Assessment—General Requirements for Accreditation Bodies Accrediting Conformity Assessment Bodies (Corrected Version), February 15, 2005, PO 00000 Frm 00052 Fmt 4701 Sfmt 9990 ‘‘ISO/IEC 17011,’’ IBR approved for § 170.503. (2) ISO/IEC GUIDE 65:1996—General Requirements for Bodies Operating Product Certification Systems (First Edition), 1996, ‘‘ISO/IEC Guide 65,’’ IBR approved for § 170.503. (3) ISO/IEC 17065:2012(E)— Conformity assessment—Requirements for bodies certifying products, processes and services (First Edition), 2012, ‘‘ISO/ IEC 17065,’’ IBR approved for § 170.503. Dated: August 20, 2014. Sylvia M. Burwell, Secretary. [FR Doc. 2014–21633 Filed 9–10–14; 8:45 am] BILLING CODE 4150–45–P E:\FR\FM\11SER2.SGM 11SER2

Agencies

[Federal Register Volume 79, Number 176 (Thursday, September 11, 2014)]
[Rules and Regulations]
[Pages 54429-54480]
From the Federal Register Online via the Government Printing Office [www.gpo.gov]
[FR Doc No: 2014-21633]

[[Page 54429]]

Vol. 79

Thursday,

No. 176

September 11, 2014

Part IV

Department of Health and Human Services

-----------------------------------------------------------------------

Office of the Secretary

-----------------------------------------------------------------------

45 CFR Part 170

2014 Edition Release 2 Electronic Health Record (EHR) Certification
Criteria and the ONC HIT Certification Program; Regulatory
Flexibilities, Improvements, and Enhanced Health Information Exchange;
Final Rule

Federal Register / Vol. 79 , No. 176 / Thursday, September 11, 2014 /
Rules and Regulations

[[Page 54430]]

-----------------------------------------------------------------------

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Office of the Secretary

45 CFR Part 170

RIN 0991-AB92

2014 Edition Release 2 Electronic Health Record (EHR)
Certification Criteria and the ONC HIT Certification Program;
Regulatory Flexibilities, Improvements, and Enhanced Health Information
Exchange

AGENCY: Office of the National Coordinator for Health Information
Technology (ONC), Department of Health and Human Services.

ACTION: Final rule.

-----------------------------------------------------------------------

SUMMARY: This final rule introduces regulatory flexibilities and
general improvements for certification to the 2014 Edition EHR
certification criteria (2014 Edition). It also codifies a few revisions
and updates to the ONC HIT Certification Program for certification to
the 2014 Edition and future editions of certification criteria as well
as makes administrative updates to the Code of Federal Regulations.

DATES: This rule is effective October 14, 2014, except for the
amendments to the amendatory instruction number 3 amendment to Sec.
170.102, the amendments to Sec. Sec. 170.205, 170.207, 170.210,
170.302, 170.304, 170.306, and the amendatory instruction number 18
amendment to Sec. 170.550, which are effective on March 1, 2015.
The incorporation by reference of certain publications listed in
the rule is approved by the Director of the Federal Register as of
October 14, 2014.

FOR FURTHER INFORMATION CONTACT: Michael Lipinski, Office of Policy,
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
FDA Food and Drug Administration
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
1. New Approach
2. Edition Naming Convention
B. Summary of Major Provisions
1. Overview of the 2014 Edition Release 2 EHR Certification
Criteria
2. ONC HIT Certification Program
C. Costs and Benefits
II. Background
A. Statutory Basis
1. Standards, Implementation Specifications, and Certification
Criteria
2. HIT Certification Programs
B. Regulatory History
1. Standards, Implementation Specifications, and Certification
Criteria Rules
2. ONC HIT Certification Programs Rules
III. Adopted Proposals
A. 2014 Edition Release 2 EHR Certification Criteria
1. National Technology Transfer and Advancement Act (NTTAA) of
1995
2. Certification Criteria
3. Gap Certification Eligibility Table for 2014 Edition Release
2
4. Base EHR Definition
B. ONC HIT Certification Program
1. Discontinuation of the Complete EHR
2. Applicability
3. ONC Regulations FAQ 28
4. Patient List Creation Certification Criteria
5. ISO/IEC 17065
6. ONC Certification Mark
C. Removal of the 2011 Edition EHR Certification Criteria From
the CFR
D. Removal of the Temporary Certification Program From the CFR
IV. Not Adopted Proposals
A. Not Adopted EHR Certification Criteria and Certification
Criteria Proposals
B. 2014 Edition and Proposed Voluntary Edition Equivalency Table
C. HIT Definitions
1. CEHRT
2. Common MU Data Set
C. ONC HIT Certification Program
1. Non-MU EHR Technology Certification
2. ``Certification Packages'' for EHR Modules
V. Comments Beyond the Scope of This Final Rule
VI. Collection of Information Requirements
VII. 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

I. Executive Summary

A. Purpose of Regulatory Action

1. New Approach
In the notice of proposed rulemaking titled ``Voluntary 2015
Edition Electronic Health Record (EHR) Certification Criteria;
Interoperability Updates and Regulatory Improvements; Proposed Rule''
(79 FR 10880) (the ``Proposed Rule''), we gave many reasons for the
adoption of the proposed ``2015 Edition EHR certification criteria'' or
``2015 Edition'' (henceforth the ``Proposed Voluntary Edition'' (79 FR
10880)).\1\ We still believe that many of these reasons remain valid.
However, upon consideration of public comment, further reflection of
ONC goals and timelines, and a desire to adhere to the administration's
principles embodied in Executive Order (EO) 13563, we have not adopted
the Proposed Voluntary Edition. Rather, we have adopted a small subset
of our original proposals in the Proposed Voluntary Edition as optional
2014 Edition EHR certification criteria and made revisions to 2014
Edition EHR certification criteria (also referred to as the ``2014
Edition Release 2'' or ``2014 Edition Release 2 EHR certification
criteria'') that provide flexibility, clarity, and enhance health
information exchange; and administrative proposals (i.e., removal of
regulatory text from the Code of Federal Regulations) and proposals for
the ONC HIT Certification Program that provide improvements. The
certification criteria we have adopted in this final rule are
consistent with the principles and instructions for retrospective
review of regulations embodied in EO 13563 to make our program more
effective and less burdensome in achieving regulatory objectives. This
final rule introduces multiple means to reduce regulatory burden,
increase regulatory flexibility for stakeholders, and promote further
innovation.
---------------------------------------------------------------------------

\1\ 79 FR 10881-82.

---------------------------------------------------------------------------

[[Page 54431]]

We note that EHR technology developers do not have to update and
recertify their products to the 2014 Edition Release 2 nor do eligible
professionals (EPs), eligible hospitals (EHs), and critical access
hospitals (CAHs) have to upgrade to EHR technology certified to the
2014 Edition Release 2. However, we encourage EHR technology developers
and the EPs, EHs, and CAHs that they support to consider whether the
2014 Edition Release 2 offers any opportunities that they might want to
pursue.
2. Naming Conventions
In the Proposed Rule, we proposed to call the Proposed Voluntary
Edition the ``2015 Edition.'' \2\
---------------------------------------------------------------------------

\2\ 79 FR 10885.
---------------------------------------------------------------------------

Comments. Commenters indicated that attributing years to the
certification criteria editions creates unrealistic expectations for
providers and other potential ``users'' of the certification program
that vendors will develop products ready to be used by the designated
edition year.
Response. In the July 28, 2010 final rule entitled ``Health
Information Technology: Initial Set of Standards, Implementation
Specifications, and Certification Criteria for Electronic Health Record
Technology (75 FR 44590) and referred to as the ``2011 Edition Final
Rule,'' the Secretary adopted certification criteria in title 45, part
170, Sec. Sec. 170.302, 170.304, and 170.306 of the Code of Federal
Regulations (CFR). In March 2012, to make a clear distinction between
the certification criteria adopted in Sec. Sec. 170.302, 170.304, and
170.306 and the certification criteria proposed for adoption in Sec.
170.314 (the notice of proposed rulemaking with request for comments
titled, ``Health Information Technology: Standards, Implementation
Specification and Certification Criteria for Electronic Health Record
Technology, 2014 Edition; Revisions to the Permanent Certification
Program for Health Information Technology'' (77 FR 13832)), we
discussed that we would be using an ``edition'' naming approach for the
sets of certification criteria subsequently adopted by the Secretary.
We stated that we would refer to the certification criteria adopted in
the 2011 Edition Final Rule and included in Sec. Sec. 170.302,
170.304, and 170.306 collectively as the ``2011 Edition EHR
certification criteria'' and that the certification criterion adopted
in Sec. 170.314 would be referred to as the ``2014 Edition EHR
certification criteria.'' We finalized this approach and adopted a
``2014 Edition'' in the September 4, 2012 final rule we issued entitled
``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) (the ``2014
Edition Final Rule'').
These two years ``2011'' and ``2014'' were purposefully chosen
because they coincided with the first year in which compliance with
that edition of EHR certification criteria would be required for use
under the Medicare and Medicaid EHR Incentive Programs (``EHR Incentive
Programs''). This approach was meant to simplify the communication
related to the certification criteria editions and enabled generalized
statements like ``an EP needs to be using 2014 Edition CEHRT when they
demonstrate meaningful use (MU) in CY 2014.'' In retrospect, it appears
that this approach unintentionally linked certification criteria
editions solely to MU to many stakeholders, while the certification
criteria editions already support and are referenced by other HHS
programs (e.g., the CMS and HHS Office of Inspector General (OIG) final
rules to modify the Physician Self-Referral Law exception and Anti-
kickback Statute safe harbor for certain EHR donations (78 FR 78751)
and (78 FR 79202), respectively).\3\
---------------------------------------------------------------------------

\3\ 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). OIG final rule ``Medicare and State Health Care Programs:
Fraud and Abuse; Electronic Health Records Safe Harbor Under the
Anti-Kickback Statute'' (78 FR 79202).
---------------------------------------------------------------------------

We and CMS recently issued a final rule (79 FR 52910) that
demonstrated linking a certification criteria edition's year to any
other program's compliance date could confuse the original intent of
the edition's year selection (due to the final rule pushing back the
compliance requirement of using EHR technology certified only to the
2014 Edition to fiscal year (FY) and calendar year (CY) 2015 for EPs,
EHs, and CAHs). Accordingly, we believe that a simpler approach will be
for future certification criteria editions to be named by the year in
which the final rule is published, and other rulemakings like this
final rule (which include additional criteria or alternatives to
previously adopted certification criteria) would be added to the most
current edition of certification criteria. To further clarify, a
rulemaking like this one that does not adopt an edition of
certification criteria would be referred to as ``[current edition year]
Release X.''
For example, we expect that the final rule for the next edition of
certification criteria we adopt will be an edition of certification
criteria and will be published in 2015. Thus, that edition of
certification criteria would be called the ``2015 Edition'' because it
will be an edition of certification criteria and its final rule would
be published in 2015. If we were to subsequently issue a final rule in
2016 with seven certification criteria to support another HHS program
or to make revisions to the adopted 2015 Edition certification
criteria, we would refer to that rulemaking as the ``2015 Edition
Release 2'' rulemaking and ultimately make modifications to the 2015
Edition certification criteria at its CFR location and regulation text.
Importantly, this provides stakeholders with a consistent and
predictable naming approach for future editions and also supports ONC's
broader interests to have the ONC HIT Certification Program be
generally accessible to other programs either within or outside
government. Stakeholders that seek to leverage the ONC HIT
Certification Program would then be able to choose which edition of
certification criteria (or subset of criteria within an edition) is
most relevant and appropriate for their program needs.

B. Summary of Major Provisions

1. Overview of the 2014 Edition Release 2 EHR Certification Criteria
The 2014 Edition Release 2 EHR certification criteria we have
adopted in this final rule include ten optional and two revised
certification criteria for inclusion in the 2014 Edition.\4\ Each of
these certification criteria originate with the current 2014 Edition.
The optional certification criteria include the splitting of the
``computerized provider order entry'' (CPOE) criterion into three
certification criteria based on capabilities (medications, laboratory,
and diagnostic imaging); a ``transitions of care'' (ToC) certification
criterion that is decoupled from the transport method; three separate
transport method certification criteria (corresponding to the three
transport standards found in Sec. 170.314(b)(1) and (2)); a ``clinical
information reconciliation and incorporation certification'' (CIRI)
certification criterion that moves

[[Page 54432]]

``incorporation'' from the ToC certification criterion; and a
``transmission to public health agencies--syndromic surveillance''
certification criterion that permits any electronic method for creating
syndromic surveillance information for exchange. Additionally, the
``automated numerator recording'' certification criterion (Sec.
170.314(g)(1)) has been changed to be designated ``optional'' for the
purposes of excluding it from the 2014 Edition Complete EHR definition
as discussed in more detail in the ONC HIT Certification Program
section below.
---------------------------------------------------------------------------

\4\ As we explained in the Proposed Rule (79 FR 10918), the
designation of ``optional'' for certification criteria (in this
case, the 2014 Edition) was developed to accommodate the Complete
EHR definition. If a certification criterion is not designated
``optional,'' an EHR technology designed for the ambulatory setting
or inpatient setting would need to be certified to the criterion in
order to satisfy the Complete EHR definition and be issued a
Complete EHR certification.
---------------------------------------------------------------------------

The two revised certification criterion include a revised ``view,
download, and transmit to 3rd party'' (VDT) certification criterion
(Sec. 170.314(e)(1)) that permits the same optionality provided in the
new optional ToC certification criterion as it relates to transport
methods, and a revised ``safety-enhanced design'' (SED) certification
criterion that includes the optional CPOE certification criteria and
the optional CIRI certification criterion. We discuss the revisions to
SED under the discussions of CPOE and CIRI in section III.A.2 of this
preamble.
Table 1 below specifies the 2014 Edition Release 2 EHR
certification criteria.

Table 1--2014 Edition Release 2 EHR Certification Criteria
----------------------------------------------------------------------------------------------------------------
Optional certification criteria Revised certification criteria
----------------------------------------------------------------------------------------------------------------
Title of regulation Title of regulation
Regulation section paragraph Regulation section paragraph
----------------------------------------------------------------------------------------------------------------
Sec. 170.314(a)(18)........... Optional--computerize Sec. 170.314(e)(1)............ View, download, and
d provider order transmit to 3rd
entry--medications. party.
Sec. 170.314(a)(19)........... Optional--computerize Sec. 170.314(g)(3)............ Safety-enhanced
d provider order design.
entry--laboratory.
Sec. 170.314(a)(20)........... Optional--computerize
d provider order
entry--diagnostic
imaging.
Sec. 170.314(b)(8)............ Optional--transitions
of care.
Sec. 170.314(b)(9)............ Optional--clinical
information
reconciliation and
incorporation.
Sec. 170.314(f)(7)............ Optional--ambulatory
setting only--
Transmission to
public health
agencies--syndromic
surveillance.
Sec. 170.314(g)(1)............ Optional--automated
numerator recording.
Sec. 170.314(h)(1)............ Optional--Applicabili
ty Statement for
Secure Health
Transport.
Sec. 170.314(h)(2)............ Optional--Applicabili
ty Statement for
Secure Health
Transport and XDR/
XDM for Direct
Messaging.
Sec. 170.314(h)(3)............ Optional--SOAP
Transport and
Security
Specification and
XDR/XDM for Direct
Messaging.
----------------------------------------------------------------------------------------------------------------

2. ONC HIT Certification Program
We proposed several modifications to the ONC HIT Certification
Program, some of which we have finalized in this final rule. We are
discontinuing the ``Complete EHR'' certification concept, including the
definition, starting with the next certification criteria edition that
we adopt in a subsequent final rule. This decision has no effect on
certification to the 2014 Edition. We have adopted an updated standard
(ISO/IEC 17065) for the accreditation of ONC-Authorized Certification
Bodies (ACBs) to maintain alignment with industry practices. We have
adopted the ``ONC Certified HIT'' certification and design mark for
required use by ONC-ACBs, which we believe will provide clarity for the
market as it relates to EHR technology certified under the program. We
have designated the 2014 Edition ``automated numerator recording''
certification criterion (Sec. 170.314(g)(1)) as optional for the
purposes of excluding it from Complete EHR certification (it still
applies for EHR Module certification) and revised Sec. 170.550(f) to
clearly require and permit EHR Module certification to either Sec.
170.314(g)(1) or (g)(2) (``automated measure calculation''). Last, we
have provided clarifying guidance for certification to the 2014 Edition
``patient list creation'' certification criterion.

C. Costs and Benefits

Our estimates indicate that this final rule is not an economically
significant rule as its overall costs are significantly below $100
million in any one year. We have, however, estimated the costs and
benefits of this final 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 adopted
optional and revised 2014 Edition certification criteria (and the
standards and implementation specifications they include) are
represented in monetary terms in Table 2 below. We believe a small
number of EHR technology developers and other health information
technology (HIT) developers will seek to be tested and certified to the
certification criteria adopted in this final rule. We estimate that
development and preparation efforts for the optional and revised 2014
Edition certification criteria adopted in the final rule will be split
evenly over CYs 2014 and 2015 and will be confined to these years
because we expect to issue a 2015 Edition final rule in 2015 and expect
that the majority of EHR development and preparation efforts at that
time will shift towards meeting the 2015 Edition. The dollar amounts
expressed in Table 2 are expressed in 2014 dollars.

[[Page 54433]]

Table 2--Distributed Total Development and Preparation Costs for EHR Technology Developers (2-Year Period)--
Totals Rounded
----------------------------------------------------------------------------------------------------------------
Total
Total low Total high average
Year Ratio cost cost cost
(percent) estimate estimate estimate
($M) ($M) ($M)
----------------------------------------------------------------------------------------------------------------
2014........................................................ 50 $1.46 $2.90 $2.19
2015........................................................ 50 1.46 2.90 2.19
2-Year Totals............................................... ........... 2.92 5.80 4.38
----------------------------------------------------------------------------------------------------------------

While we believe only a small number of EHR technology developers
and other HIT developers will seek testing and certification to the
optional and revised 2014 Edition certification criteria adopted in the
final rule, the regulatory flexibility these certification criteria
provide will offer several significant benefits to patients, health
care providers, and HIT developers. The 2014 Edition Release 2
incorporates stakeholder feedback on particular 2014 Edition issues
identified as impacting innovation and causing undue burden. The 2014
Edition Release 2 also seeks to continue to improve EHR technology's
interoperability and electronic health information exchange.
Specifically, the separating out of the ``content'' and ``transport''
capabilities in the optional 2014 Edition ToC certification criterion
we have adopted in this final rule (compared to the 2014 Edition ToC
certification criteria adopted at Sec. 170.314(b)(1) and (2)) and the
adoption of the Implementation Guide (IG) for Direct Edge Protocols
(Direct Edge Protocols IG) is aimed at improving the market
availability of electronic health information exchange services for
transitions of care. The new certification flexibilities offered by the
optional ``CPOE'' and optional ``syndromic surveillance'' certification
criteria are designed to enhance innovation and offer providers
enhanced functionality and options for meeting applicable MU measures.
The new flexibility in the VDT certification criterion is designed to
further facilitate the exchange of patient health information between
provider and patient. The optional CIRI criterion is designed to better
align with clinical workflows than the process in the ToC certification
criterion at Sec. 170.314(b)(1).

II. Background

A. Statutory Basis

The Health Information Technology for Economic and Clinical Health
(HITECH) Act, Title XIII of Division A and Title IV of Division B of
the American Recovery and Reinvestment Act of 2009 (the Recovery Act)
(Pub. L. 111-5), was enacted on February 17, 2009. The HITECH Act
amended the Public Health Service Act (PHSA) and created ``Title XXX--
Health Information Technology and Quality'' (Title XXX) to improve
health care quality, safety, and efficiency through the promotion of
HIT and electronic health information exchange.
1. Standards, Implementation Specifications, and Certification Criteria
The HITECH Act established two new federal advisory committees, the
HIT Policy Committee (HITPC) and the HIT Standards Committee (HITSC)
(sections 3002 and 3003 of the PHSA, respectively). Each is responsible
for advising the National Coordinator for Health Information Technology
(National Coordinator) on different aspects of standards,
implementation specifications, and certification criteria. The HITPC is
responsible for, among other duties, recommending priorities for the
development, harmonization, and recognition of standards,
implementation specifications, and certification criteria. Main
responsibilities of the HITSC include recommending standards,
implementation specifications, and certification criteria for adoption
by the Secretary under section 3004 of the PHSA consistent with the
ONC-coordinated Federal Health IT Strategic Plan.
Section 3004 of the PHSA identifies a process for the adoption of
health IT standards, implementation specifications, and certification
criteria and authorizes the Secretary to adopt such standards,
implementation specifications, and certification criteria. As specified
in section 3004(a)(1), the Secretary is required, in consultation with
representatives of other relevant federal agencies, to jointly review
standards, implementation specifications, and certification criteria
endorsed by the National Coordinator under section 3001(c) and
subsequently determine whether to propose the adoption of any grouping
of such standards, implementation specifications, or certification
criteria. The Secretary is required to publish all determinations in
the Federal Register.
Section 3004(b)(3) of the PHSA titled ``Subsequent Standards
Activity'' provides that the ``Secretary shall adopt additional
standards, implementation specifications, and certification criteria as
necessary and consistent'' with the schedule published by the HITSC. We
consider this provision in the broader context of the HITECH Act to
grant the Secretary the authority and discretion to adopt standards,
implementation specifications, and certification criteria that have
been recommended by the HITSC and endorsed by the National Coordinator,
as well as other appropriate and necessary HIT standards,
implementation specifications, and certification criteria. Throughout
this process, the Secretary intends to continue to seek the insights
and recommendations of the HITSC.
2. HIT Certification Programs
Section 3001(c)(5) of the PHSA provides the National Coordinator
with the authority to establish a certification program or programs for
the voluntary certification of HIT. Specifically, section 3001(c)(5)(A)
specifies that the ``National Coordinator, in consultation with the
Director of the National Institute of Standards and Technology, shall
keep or recognize a program or programs for the voluntary certification
of health information technology as being in compliance with applicable
certification criteria adopted under this subtitle'' (i.e.,
certification criteria adopted by the Secretary under section 3004 of
the PHSA).
The certification program(s) must also ``include, as appropriate,
testing of the technology in accordance with section 13201(b) of the
[HITECH] Act.'' Overall, section 13201(b) of the HITECH Act requires
that with respect to the development of standards and implementation
specifications, the Director of the National Institute of Standards and
Technology (NIST), in coordination with the HITSC, ``shall support the
establishment of a

[[Page 54434]]

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 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).
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''). 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 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. The
interim final rule also revised the EHR Incentive Programs by adding an
alternative measure for the MU Stage 2 objective for hospitals to
provide structured electronic laboratory results to ambulatory
providers, corrected the regulation text for the measures associated
with the objective for hospitals to provide patients the ability to
view online, download, and transmit information about a hospital
admission, and made the case number threshold exemption policy for
clinical quality measure (CQM) reporting applicable for eligible
hospitals and CAHs beginning with FY 2013. The rule also provided
notice of CMS's intent to issue technical corrections to the electronic
specifications for CQMs released on October 25, 2012 (77 FR 72985).
On November 4, 2013, the Secretary published an interim final rule
with a request for comment, 2014 Edition Electronic Health Record
Certification Criteria: Revision to the Definition of ``Common
Meaningful Use (MU) Data Set'' (78 FR 65884), to make a minor revision
to the Common MU Data Set definition. This revision was intended to
allow more flexibility with respect to the representation of dental
procedures data for EHR technology testing and certification.
On February 26, 2014, the Secretary issued the Proposed Rule. The
Proposed Rule proposed voluntary certification criteria that would
enable a more efficient and effective response to stakeholder feedback,
incorporate ``bug fixes'' to improve on 2014 Edition in ways designed
to make ONC's rules clearer and easier to implement, and reference
newer standards and implementation specifications. A correction notice
was published for the Proposed Rule on March 19, 2014, entitled
``Voluntary 2015 Edition Electronic Health Record (EHR) Certification
Criteria; Interoperability Updates and Regulatory Improvements;
Correction'' (79 FR 15282). This correction notice corrected the
preamble text and gap certification table for four certification
criteria that were omitted from the list of certification criteria
eligible for gap certification for the 2015 Edition EHR certification
criteria.
On May 23, 2014, CMS and ONC jointly published the ``Medicare and
Medicaid Programs; Modifications to the Medicare and Medicaid
Electronic Health Record Incentive Programs for 2014; and Health
Information Technology: Revisions to the Certified EHR Technology
Definition'' proposed rule (79 FR 29732). The rule proposed to update
the MU Stage 2 and Stage 3 participation timeline. It proposed to
revise the CEHRT definition to permit the use of EHR technology
certified to the 2011 Edition to meet the CEHRT definition for FY/CY
2014. It also proposed to allow EPs, EHs, and CAHs that could not fully
implement EHR technology certified to the 2014 Edition for an EHR
reporting period in 2014 due to delays in the availability of such
technology to continue to use EHR technology certified to the 2011
Edition or a combination of EHR technology certified to the 2011
Edition and 2014 Edition for the EHR reporting periods in CY 2014 and
FY 2014. On September 4, 2014, a final rule (``MU Flexibility Final
Rule'') was published (79 FR 52910) adopting these proposals.
2. 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

[[Page 54435]]

``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.
The Proposed Rule included proposals that focused on improving
regulatory clarity, simplifying the certification of EHR Modules that
are designed for purposes other than achieving MU, and discontinuing
the use of the Complete EHR definition starting with the ``Proposed
Voluntary Edition.''

III. Adopted Proposals

A. 2014 Edition Release 2 EHR Certification Criteria

We proposed to adopt the Proposed Voluntary Edition, which included
a full set of certification criteria (57 certification criteria) for
the ambulatory and inpatient settings.
Comments. We received both positive and negative comments on the
Proposed Voluntary Edition. Commenters that supported the Proposed
Voluntary Edition stated that it was responsive to stakeholder
feedback, permitted certification to new functionality and standards in
a timely manner, and appropriately raised the bar on interoperability.
Commenters that did not support the Proposed Voluntary Edition stated
that the scope was too large, some standards were too immature for
adoption, additional certification would be too costly (after just
preparing EHR technology for certification to the 2014 Edition), and
that it set an unrealistic expectation among providers and patients
that EHR technology developers could have products certified to the
Proposed Voluntary Edition in a timely manner (shortly after the 2014
Edition and while preparing for the next edition that would directly
support MU Stage 3).
Response. We thank commenters for their support of the Proposed
Voluntary Edition. We also appreciate the constructive feedback offered
by other commenters. As stated in the Executive Summary, we have only
adopted a small subset of our original proposals in the Proposed
Voluntary Edition as optional 2014 Edition EHR certification criteria
and made revisions to 2014 Edition EHR certification criteria (also
referred to as the ``2014 Edition Release 2'' or ``2014 Edition Release
2 EHR certification criteria'') that provide flexibility, clarity and
enhance health information exchange. While we believe there are many
valid reasons for the adoption of the Proposed Voluntary Edition,
including those mentioned by commenters, we believe that our approach
in this final rule is the most appropriate at this time. This approach
addresses commenters' concerns and introduces multiple means to reduce
regulatory burden, increase regulatory flexibility for stakeholders,
and promote further innovation.
1. National Technology Transfer and Advancement Act (NTTAA) of 1995
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 \5\ require the use of, 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
final rule, we have adopted ISO/IEC 17065, which is a voluntary
consensus standard. We have also adopted the ONC Implementation Guide
for Direct Edge Protocols, Version 1.1. This standard was not developed
by a voluntary consensus standards body, but was developed by a group
of industry stakeholders committed to advancing the Direct Project,\6\
which started as an initiative under the Standards and Interoperability
(S&I) Framework.\7\ This group used a consensus process similar to
those used by other industry stakeholders and voluntary consensus
standards bodies. We are aware of no voluntary consensus standard that
would serve as an alternative to this standard for the purposes that we
have identified in this final rule.
---------------------------------------------------------------------------

\5\ https://www.whitehouse.gov/omb/circularsa119.
\6\ https://www.healthit.gov/policy-researchers-implementers/direct-project.
\7\ https://www.healthit.gov/policy-researchers-implementers/standards-interoperability-si-framework.
---------------------------------------------------------------------------

2. Certification Criteria
Computerized Provider Order Entry
Section 3000 of the PHSA, as added by section 13101 of the HITECH
Act, requires that computerized provider order entry (CPOE)
capabilities be included in CEHRT. We included CPOE capabilities in the
Base EHR definition, which is part of the CEHRT definition, under 45
CFR 170.102. Within the 2011 and 2014 Editions, we adopted CPOE
certification criteria that require EHR technology to be capable of
performing CPOE for medication, laboratory, and radiology/imaging
orders. In the Proposed Rule, we stated that based on stakeholder
feedback since the 2014 Edition Final Rule, we understood that this
approach can prevent EHR technology developers from creating more
efficient, provider-specific ``adaptations'' of EHR technology that
support CPOE.\8\ For example, a mobile adaptation of CPOE currently
must include all of the capabilities listed in the 2014 Edition CPOE
certification

[[Page 54436]]

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.
---------------------------------------------------------------------------

\8\ Please see 77 FR 54267-68 for a discussion of adaptations.
---------------------------------------------------------------------------

Similarly, we noted that some providers could interpret our
approach to CPOE certification as inconsistent with the flexibility
provided in the FY/CY 2014 CEHRT definition under Sec. 170.102. As one
example, we noted that 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). As another
example, we stated that 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. As one final example, we
explained that 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 proposed 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.
For the reasons above, we proposed to split the CPOE certification
criterion for the Proposed Voluntary Edition into three separate
certification criteria with each criterion focused on one of the three
order types, reasoning that 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.
In the Proposed Rule, we also stated that the proposed ``CPOE''
certification criteria would omit the ``at a minimum'' language
included in the 2014 Edition and 2011 Edition CPOE certification
criteria. We noted that the ``at a minimum'' language was included in
prior editions to indicate that EHR technology developers could include
capabilities that support other types of orders. We stated that this
language is extraneous because we have consistently maintained that
certification criteria (and certification in general) serve as minimum
requirements or a baseline.
Comments. We received universal support for adopting three separate
CPOE certification criteria based on medications, laboratory, and
radiology/imaging orders. We also received support for the elimination
of the ``at a minimum'' language found in the 2011 and 2014 Edition
criteria with commenters stating that elimination of the language would
remove redundancy from the criteria and reduce confusion.
Response. We have adopted these three certification criteria as
2014 Edition optional certification criteria based on stakeholder
feedback and for the reasons we cited in the Proposed Rule. We clarify
and emphasize that there are no standards included in the optional
certification criteria, unlike the proposed CPOE--laboratory
certification criterion. We have also omitted the ``at a minimum''
language in these certification criteria for the reasons proposed and
supported by commenters.
We have changed the title of the certification criterion that
supports CPOE for ``radiology/imaging'' (Sec. 170.314(a)(20)) to
``CPOE--diagnostic imaging'' and changed the relevant regulation text
of this certification criterion from ``radiology and imaging orders''
to ``diagnostic imaging orders.'' We have also made a similar revision
to Sec. 170.3014(a)(1)(iii) by replacing ``radiology/imaging'' with
``diagnostic imaging.'' We have made these revisions to eliminate any
potential confusion as to the type of orders we are referencing. We
note, however, that these revisions in no way alter the required
capability.
We have adopted the optional certification criteria at Sec.
170.314(a)(18) through (20) and included them in the Base EHR
definition. We have also revised the ``safety-enhanced design'' (SED)
certification criterion at Sec. 170.314(g)(3) to include the three
optional CPOE certification criteria. These optional CPOE certification
criteria included the same ``patient safety-related'' capabilities
included in the CPOE certification criterion at Sec. 170.314(a)(1) and
thus the same ``patient safety risk'' rationale for their inclusion in
the SED certification criterion at Sec. 170.314(g)(3) applies.\9\
---------------------------------------------------------------------------

\9\ Please see the 2014 Edition Final Rule (77 FR 54187) for a
discussion of the capabilities and certification criteria that we
believe present a risk to patient safety and thus are included in
the SED certification criterion.
---------------------------------------------------------------------------

As we noted in the Proposed Rule (79 FR 10886), we caution that
this additional flexibility comes with potential risk for EPs who
expect to qualify for one or more of the exclusions from the CPOE
measures, 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. Therefore, 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.
We note that we discuss comments received on each of the three
proposed CPOE certification criteria that suggested changes to the
criteria under section IV.A ``Not Adopted EHR Certification Criteria
and Certification Criteria Proposals.'' This includes a discussion of
our reasons for not adopting the HL7 Laboratory Orders Interface (LOI)
standard and the Clinical Laboratory Improvement Amendments (CLIA)-
related requirements for the proposed ``CPOE--laboratory''
certification criterion.
Transitions of Care
We proposed to make several changes to the ``transitions of care''
(ToC) certification criterion, including decoupling content and
transport capabilities, the inclusion of the Direct Edge Protocols IG
Version 1.0, and shifting the ``incorporation'' requirements into an
updated ``clinical information reconciliation and incorporation''
(CIRI). We included several other proposals in the ToC certification
criterion that we have not finalized. These proposals are discussed in
section IV.A of this preamble.
``Decoupling'' Content and Transport
In the Proposed Rule, we recited specific stakeholder feedback
stating that 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. We also recited stakeholder
feedback indicating that we had incorrectly imposed the coupling of
technical capabilities that

[[Page 54437]]

can be adequately performed by two different systems. More
specifically, stakeholders 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. In this regard, we illustrated how the ``binding'' of the
transport and content capabilities within the scope of a single
criterion has led, in some cases, to the intertwining of EHR and health
information service provider (HISP) functionality (i.e., HISP
functionality being built into an EHR or EHR functionality being built
into a HISP) solely for the purposes of certification. As a result, we
proposed to decouple content and transport capabilities and adopt a
single ToC criterion that focused on content capabilities and EHR
technology's capability to connect to a service that is conformant with
the primary Direct Project specification through the use of the Direct
Edge Protocols IG Version 1.0.
Comments. We received significant public comment on this proposal
from associations representing providers, consumers, and HIT developers
as well as comments from numerous HIT developers. The vast majority of
the commenters supported decoupling content and transport capabilities,
with some voicing concerns about the proposed Edge Protocol IG Version
1.0. Specifically, commenters noted that the decoupling represented a
much-needed flexibility for HIT developers and a workflow update that
reflected implementations already widely used. One commenter, an ONC-
ACB, noted that ToC and HISP functionality was already separated for
most EHRs across different systems. Other commenters voiced concerns
that the decoupling would create a greater burden on providers and
hospitals as they assemble their certified systems. Finally, comments
from the EHR technology developer community stated that the change was
proposed too late to provide flexibility, noting that they had already
complied with the 2014 Edition requirements and combined the
functionality.
Response. We have decided to finalize our proposal to decouple
content and transport capabilities. We have also decided to adopt an
updated version of the Direct Edge Protocols IG, which we discuss in
more detail below. We appreciate the support for this proposal and
agree with commenters that the decoupling will achieve much needed
flexibility and allow for continued innovation in the market. While
this flexibility may be considered too late by some stakeholders, we
believe that the potential benefits of its availability for the 2015
EHR reporting period outweigh the negatives. Accordingly, we have
adopted an optional ToC certification criterion at Sec. 170.314(b)(8)
that focuses on content creation and edge protocol capabilities. We do
not believe the optional ToC certification criterion will cause
additional burden or complexity for EPs, EHs, and CAHs because it is
voluntary and if pursued by an EHR technology developer will be done so
to provide additional flexibility and options for an EP, EH, or CAH to
choose their HISP.
Edge Protocol for EHR to HISP Connectivity for Direct Transmissions
Comments. Commenters voiced support for decoupling the content and
transport requirements under the ToC criterion, however, many voiced
concern about the Direct Edge Protocols IG Version 1.0 (``Version
1.0''). Commenters stated the protocol optionality in Version 1.0
provided the potential for interoperability incompatibilities.
Commenters also noted that this level of optionality would require
technology developers to support all four protocols in Version 1.0 in
order to support the variety of valid protocol implementations in ToC.
Commenters recommended ONC choose a minimum set of edge protocols that
would be mandatory, instead of allowing all four. Other commenters
noted that Version 1.0 was never intended to be part of a regulatory
framework. Commenters also voiced concern that Version 1.0 did not have
widespread development and implementation experience and it that it was
premature to adopt it. Finally, commenters noted that the Direct Edge
Protocols IG Version 1.1 (``Version 1.1'') would be finalized shortly
and urged us to include that version instead of Version 1.0 if we
decided to adopt the Direct Edge Protocol IG.
Response. We appreciate the diverse and specific feedback on our
proposal to adopt the Version 1.0. In addition to the comments we
received on the Proposed Rule, stakeholders who helped develop Version
1.0 provided feedback (through the IG development process) that the
edge protocol specifications and message tracking guidance needed to be
clarified and refined based upon their experiences in the field. We
agree that some of the ambiguities in Version 1.0 could introduce
interoperability and implementation challenges for technology
developers. Version 1.0 represented a first attempt toward a consistent
and uniform approach for HISPs and EHR technology (and other so-called
``edge'' systems in the IG) to implement the most common protocols
(described as ``edge protocols'' in the IG) between these systems.
In response to feedback, the stakeholder community (comprised of
several HISPs and EHR technology developers) released an updated
version of the IG for Direct Edge Protocols, Version 1.1 through the
stakeholder lead Direct Project.\10\ Version 1.1, as discussed in more
detail below, builds on and improves Version 1.0 with consistent
implementation and interoperability in mind because it includes more
thoroughly documented technical constraints for the edge protocols it
references. Version 1.1 addresses many stakeholder concerns because it
minimizes variability between implementations.
---------------------------------------------------------------------------

\10\ https://www.healthit.gov/sites/default/files/
implementationguidefordirectedgeprotocolsv11.pdf.
---------------------------------------------------------------------------

As outlined in the Proposed Rule, we believe it is important to
adopt a Direct Edge Protocols IG in order to support the separation of
content and transport related to ToC. If we were to not adopt a Direct
Edge Protocols IG, HIT developers would likely first implement
inconsistent approaches to edge protocols and then need to spend
additional resources later to reconcile those inconsistencies.
Providing for certification to Version 1.1 can enable greater certainty
and assurance to HIT developers that products certified to this IG have
implemented the IG's edge protocol(s) in a consistent manner. The
availability of certification should also enhance HIT developers'
ability to reliably connect their products without the need for
customized interfaces and, ultimately, enable health care providers a
greater ability to choose or switch HISP services.
Therefore, in consideration of public comments and our proposal to
permit content and transport capabilities to be separately tested and
certified, we have decided to adopt Version 1.1 as part of this
optional ToC certification criterion. EHR technology presented for
certification to the criterion adopted at Sec. 170.314(b)(8) would
need to demonstrate compliance with Version 1.1.
The following explains the context and reasons for our decision to
adopt Version 1.1 as a standard at Sec. 170.202(d) and reference it
within the optional ToC certification criterion at Sec. 170.314(b)(8).
For clarity, we note that the optional ToC certification criterion
adopted at Sec. 170.314(b)(8) would be only applicable to EHR
technology in the role of the ``edge system'' identified in Version
1.1. We also note that this

[[Page 54438]]

policy only applies for the purposes of EHR technology to be certified
and is not meant to impose a ``ceiling'' or limit the use of other edge
protocols if so implemented in order to enable electronic exchange for
the purposes of meeting the MU transitions of care objective and
measures.
Version 1.1 includes two key improvements upon Version 1.0:
Version 1.1 clarifies the permissible combinations of edge
protocols and their applicability within the scope of the IG. For
example, two of the edge protocols within the IG (Post Office Protocol
(POP) and Internet Message Access Protocol (IMAP)) are unidirectional,
meaning they must be paired with another protocol to enable two-way
communication between an ``edge system'' and its HISP. Version 1.0 did
not clearly specify what the other protocols should be paired with POP
and IMAP. Thus, implementers found this guidance incomplete and
unclear. Version 1.1 addresses that ambiguity and instructs Edge
systems to pair POP and IMAP with Simple Mail Transfer Protocol (SMTP).
Version 1.1 clarifies technical constraints for Cross-
Enterprise Document Reliable Interchange (XDR), SMTP, POP, and IMAP.
Implementers of Version 1.0 noted that the IG's level of specification
for edge protocols left room for too much variation in implementations,
impacting interoperability by creating interface incompatibilities in
some instances. In this case, Version 1.0's ambiguities and inherent
variability proved problematic and, from a consistent implementation
perspective, demonstrated that a more tightly constrained specification
would be beneficial. Version 1.1 improves the specificity around XDR,
SMTP, POP, and IMAP in areas such as security and authentication to
minimize variability and increase interoperability.
Version 1.1 references the same four edge protocols that were
referenced in Version 1.0:
1. Integrating the Healthcare Enterprise (IHE) XDR profile for
Limited Metadata Document Sources;
2. SMTP;
3. Internet Message Access Protocol version 4rev1 (IMAP4); and
4. Post Office Protocol version 3 (POP3).
However, with respect to the edge system specifications identified
in Version 1.1, such edge systems are expected to support either the
``IHE XDR profile for Limited Metadata Document Sources'' edge protocol
or an SMTP-focused edge protocol (SMTP alone or SMTP in combination
with either IMAP4 or POP3). Thus, for the purposes of testing and
certification, compliance with this specific capability within the
certification criterion can be demonstrated in one of two ways: Using
the specific IHE XDR approach or one of the SMTP approaches.
For this final rule, we evaluated whether to adopt a single edge
protocol (of the four available) and decided to conduct fact finding
with several HISPs and EHR technology developers to understand what
edge protocol(s) they had implemented in the absence of any specific
edge protocol requirements as part of the 2014 Edition. Our fact
finding identified that EHR technology developers (for the ambulatory
and inpatient settings) have already started implementing the two edge
protocol approaches identified in Version 1.1 and used either an IHE
XDR-based or SMTP-based edge protocol approach to connect to HISPs, and
that HISPs were supporting both IHE XDR and SMTP-based edge protocol
approaches in order to accommodate different customer needs. We also
learned that smaller EHR technology developers were more likely to have
implemented an SMTP-based edge protocol approach because the IHE XDR
edge protocol approach would have been too resource-intensive. Given
this additional information, we determined that requiring the adoption
of a single edge protocol would be unwise since such an approach could
disadvantage certain EHR technology developers in addition to not
providing any commensurate downstream benefit to their customers (EPs,
EHs and CAHs).
Overall, we believe that the adoption of Version 1.1 will further
support efforts already underway by the community by enabling EHR
technology developers to demonstrate through testing and certification
that they have implemented an edge protocol in a manner consistent with
Version 1.1. Without this consistency, interoperability could be
impacted and make it difficult for any specific EHR technology to
reliably connect to any HISP. It could also lead to greater costs to
providers for continued customized interfaces for the edge connectivity
to a HISP and, thus, make it more likely that the provider would be
``locked-in'' to that HISP instead of being able to pair with/subscribe
to a HISP of their choosing.
Shifting ``Incorporation'' From ToC to Clinical Information
Reconciliation
In response to stakeholder feedback indicating that the inclusion
of ``incorporation'' capabilities in the 2014 Edition ToC criterion
(Sec. 170.314(b)(1)(iii)) was not aligned with typical clinical
workflows, we proposed to include ``incorporation'' capabilities in a
proposed ``clinical information reconciliation and incorporation''
(CIRI) certification criterion. The ``incorporation'' capabilities
require EHR technology, upon receipt of a transition of care/referral
summary formatted according to the Consolidated CDA Release 1.1, to
demonstrate that the transition of care/referral summary received is or
can be properly matched to the correct patient and it can
electronically incorporate medications, problems, and medication
allergies according to specified vocabulary standards.
Comments. We received comments from several EHR developers on this
proposal. Commenters overwhelmingly supported including the
incorporation functionality in a CIRI criterion instead of a ToC
criterion. Commenters stated that this was a better fit for the
capabilities and more appropriate for clinical workflow. One commenter
stated that we should change the language in the CIRI criterion to
clarify ambiguities around the ``extract'' term and its associated
requirements.
Response. Given the comments in support, we have finalized our
proposal to ``move'' the incorporation requirements into an updated
CIRI criterion as proposed. We have adopted the updated CIRI criterion
as an optional 2014 Edition certification criterion at Sec.
170.314(b)(9). We agree with commenters that this approach will clarify
the interplay between the ToC and CIRI certification criteria and will
clear up any misconceptions about anticipated workflow. We decline to
change the term ``extract'' at this time because: 1) It is not part of
the CIRI criterion; and 2) the same term is used in the 2014 Edition
ToC certification criterion at Sec. 170.314(b)(1) as well as the new
optional 2014 Edition ToC criterion at Sec. 170.314(b)(8), and the
term's meaning and context is discussed in the 2014 Edition Final Rule
(77 FR 54219).
Clinical Information Reconciliation and Incorporation
We proposed a CIRI certification criterion for the Proposed
Voluntary Edition that was revised in comparison to the 2014 Edition
certification criterion. As discussed in more detail under the ToC
certification criterion above, we proposed a CIRI criterion that
included the same type of incorporation capabilities that we previously
adopted as part of the ToC certification criterion at Sec.
170.314(b)(1).
Comments. As noted in the ToC certification criterion above, we
received widespread support for ``moving'' the incorporation
capabilities

[[Page 54439]]

into a CIRI certification criterion. One commenter suggested that we
make this certification criterion eligible for gap certification.
Response. We have adopted a new optional 2014 Edition CIRI
certification criterion that includes the incorporation capability. We
appreciate the comments in support of this proposal and believe it will
more align with clinical workflow. This certification criterion is not
eligible for gap certification because the change in capabilities
required to meet this optional CIRI certification criterion make it a
``revised'' certification criterion as compared to the current 2014
Edition ``clinical information reconciliation'' (CIR) certification
criterion and thus ineligible for gap certification.
We have also revised the SED certification criterion at Sec.
170.314(g)(3) to include this optional CIRI certification criterion.
The optional CIRI certification criterion includes the same ``patient
safety-related'' capabilities included in the CIR certification
criterion at Sec. 170.314(b)(4) and thus the same ``patient safety
risk'' rationale for its inclusion in the SED certification criterion
at Sec. 170.314(g)(3) applies.\11\
---------------------------------------------------------------------------

\11\ Please see the 2014 Edition Final Rule (77 FR 54187) for a
discussion of the capabilities and certification criteria that we
believe presented a risk to patient safety and thus included in the
SED certification criterion.
---------------------------------------------------------------------------

View, Download, and Transmit to 3rd Party (VDT)
The Proposed Rule summary in this section only summarizes and
includes the ``comments'' and ``response'' for the proposal that we
have adopted as part of this final rule. We included several other
proposals in the proposed VDT certification criterion that we have not
finalized. These proposals are discussed in section IV.A of this
preamble.
Decoupling Transport and Content
For the reasons we provided in the Proposed Rule for the separation
of content capabilities and transport capabilities (79 FR 10896-97,
10906) and recited under the ToC certification criterion discussed
previously in this preamble section, we proposed to ``decouple'' the
transport and content capabilities of the VDT certification criterion.
We noted that similar to the proposed ToC revisions, the certification
criterion would focus on content requirements and EHR technology's
ability to demonstrate conformance with the Direct Edge Protocols IG
Version 1.0 and enable a successful transmission. We further specified
that this would require EHR technology to enable a patient to
accomplish a transmission that conforms to the Direct Edge Protocols IG
Version 1.0 and is used by a service that has implemented the primary
Direct Project specification.
We clarified that ``accomplish'' was intended to convey our
expectation and that our anticipated approach through testing would be
to assess whether the transmitted Consolidated Clinical Document
Architecture (CDA) arrived at its destination. We emphasized that under
this proposed revision EHR technology developers seeking testing and
certification would be permitted to demonstrate compliance with the
transport requirement without having to be a HISP (or be bound to a
single HISP through certification). However, we indicated that
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 (sent and received) in accordance with
the primary Direct Project specification (under our new proposal for
this to be a separate certification criterion).
Comments. Given the parallels between this proposal and the
proposal we made for the ToC criterion, the vast majority of commenters
expressed the same general support for the ``decoupling.'' Commenters
also expressed similar concerns about the proposed Edge Protocol IG
Version 1.0 interoperability incompatibilities and the need for HIT
developers to support all four protocols in order to support the
variety of valid protocol implementations. In general, commenters
stated that the decoupling of content and transport represented a much-
needed flexibility for developers and a workflow update that reflected
implementations already widely used.
Response. For the same reasons we provide in response to the ToC
certification criterion related to the decoupling of content and
transport as well as the Direct Edge Protocols IG Version 1.1, we have
adopted Version 1.1 for the purposes of the VDT certification
criterion. In light of our overall approach for this final rule's
scope, we have determined that the best and simplest approach to
include this new flexibility is to modify the existing VDT
certification criterion at Sec. 170.314(e)(1). This modification would
add an alternative pathway for EHR technology developers to demonstrate
compliance with the certification criterion. The modification would do
so in a way that recognizes the content and transport separation we
discussed in the Proposed Rule. Specifically, we have modified Sec.
170.314(e)(1)(i)(C)(1) and (2) to include the alternative ``decoupled''
approach. This revised regulatory text expresses that compliance with
the specific transport capability requirement can be demonstrated in
one of two ways. One way is the original approach adopted as part of
the 2014 Edition Final Rule (certification to the ONC Applicability
Statement for Secure Health Transport (Direct)).\12\ The other way is
the new approach adopted in this final rule (certification to the Edge
Protocol IG Version 1.1). We note that this optionality is specified
with regulatory text that states ``at least one of the following'' to
more clearly convey that both transport approaches do not need to be
supported for the purposes of certification nor would an EHR technology
developer customers need the other approach certified if the
alternative was demonstrated for the purposes of certification.
---------------------------------------------------------------------------

\12\ 77 FR 54182.
---------------------------------------------------------------------------

Transmission to Public Health Agencies--Syndromic Surveillance
We proposed to revise the 2014 Edition ``syndromic surveillance''
certification criterion and adopt a parallel ``syndromic surveillance''
certification criterion for the Proposed Voluntary Edition.
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 HL7 2.5.1 IG
available at the time of the final rule's publication (77 FR 54025).
CMS also noted, however, 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.
We stated in the Proposed Rule that only a few public health
agencies are currently accepting syndromic surveillance data from the
ambulatory setting using HL7 2.5.1. We stated that due to lack of
demand, the CDC no longer planned to develop an HL7 2.5.1 IG for
ambulatory reporting of syndromic surveillance data and that without
such an IG most public health agencies would not have enough specific
guidance to build systems to receive syndromic surveillance data from
the ambulatory setting formatted to HL7 2.5.1. Further, we noted that
the MU Stage 2 final rule permits an EP, EH, or CAH to claim an
exclusion if the public health agency does not have the

[[Page 54440]]

capacity to accept reporting (77 FR 54021) and, therefore, 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 proposed to
revise the current 2014 Edition certification criterion to 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 indicated that
syndromic surveillance data was being sent to public health agencies
through new query-based models, including the QueryHealth
initiative.\13\ Query-based models take patient level data, de-identify
it, and aggregate it for population health use. In the Proposed Rule,
we also noted that we understood that the query-based models use HL7
CDA and QRDA Category III (``QRDA III'') standards, and did not
necessarily use the HL7 2.5.1 standard. Further, we stated that CDA and
QRDA III standards were adopted and referenced by 2014 Edition
certification criteria and, as a result, had become more widely
implemented.
---------------------------------------------------------------------------

\13\ 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 noted that we sought 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
proposed to specifically 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.
For EHR technology certification to the inpatient setting, we
proposed to revise the 2014 Edition certification criterion by
replacing the adopted version of the HL7 2.5.1 IG with a newer version
of the IG that incorporates an addendum clarifying conformance guidance
(PHIN Messaging Guide for Syndromic Surveillance: Emergency Department,
Urgent Care, and Inpatient Settings, Release 1.9 (April 2013)).
We proposed the same ambulatory and inpatient setting requirements
in a parallel ``syndromic surveillance'' certification criterion for
the Proposed Voluntary Edition.
We solicited comment on whether public health agencies are using
the QRDA Category I standard to receive query-based syndromic
surveillance data, and whether we should consider adopting the standard
for the ambulatory setting.
Comments. We received a range of comments on the use of the CDA and
QRDA III standards in addition to the HL7 2.5.1 standard for ambulatory
setting certification. Some commenters stated that the added
flexibility of allowing alternate standards would increase the exchange
of syndromic surveillance data. Commenters stated that the lack of a
HL7 2.5.1 IG for the ambulatory setting has led to variation across
EHRs. Other commenters opined that the absence of an HL7 2.5.1 IG for
the ambulatory setting has also resulted in reluctance from EHR
developers to build custom interfaces to enable public health agencies
to receive ambulatory syndromic surveillance. One public health agency
commented that they have built the infrastructure to receive CDA and
QRDA III through their HIE and related partners. This public health
agency stated that CDA and QRDA III standards could represent
significant advances for timely and efficient ambulatory syndromic
surveillance data collection and supported the proposal to allow
alternate standards for certification.
Commenters in opposition to the proposal to allow use of CDA and
QRDA III standards for certification stated that ONC should promote a
single standard for ambulatory syndromic surveillance rather than allow
multiple standards. Others commented that despite the proposed
regulation text permitting use of HL7 2.5.1, CDA, ``or'' QRDA III
standards, the ``or'' would really be implemented as an ``and'' if the
EHR technology developer's customers want to use CDA or QRDA III
because an EHR developer would have to offer any and all options
desired by their customers. Some commenters expressed concern that
public health agencies are not ready to develop the infrastructure to
receive CDA and QRDA III data if they had not previously done so.
Commenters noted that, without specific IGs for the use of CDA and QRDA
III for ambulatory syndromic surveillance, the standards are not
constrained enough to reach uniform submission of the data. Likewise,
commenters indicated that the CDA and QRDA III standards have not been
piloted or tested for syndromic surveillance purposes.
The majority of commenters supported adoption of the proposed
updated IG for inpatient certification. However, many commenters stated
that since the IG Release 1.9 publication numerous errors have been
identified with Release 1.9. For example, many commenters pointed to
the report issued by the International Society for Disease Surveillance
identifying issues and errors with Release 1.9.\14\ Commenters opined
that those issues and errors should be addressed before requiring
compliance with Release 1.9. A few commenters noted that stakeholders
are working toward Release 2.0 of the IG, which they noted would
include more substantive updates relative to Release 1.8 in comparison
to the updates included in Release 1.9. Therefore, the commenters
recommended waiting to adopt Release 2.0 to avoid redundant and
unnecessary work for EHRs and public health agencies as well as to get
the maximum benefit for updated systems.
---------------------------------------------------------------------------

\14\ The ISDS Issue Report is available at https://docs.google.com/spreadsheet/ccc?key=0AlhELG407-6OdFVPa0ZjZXFjYnNVd0tPSHRCRGF0WXc&usp=sharing.
---------------------------------------------------------------------------

A few commenters stated that QRDA Category I is not being used for
query-based syndromic surveillance in ambulatory settings and opined
that Category I is not appropriate as it includes patient-level results
rather than aggregate results which are more suitable for syndromic
surveillance.
Response. We proposed revisions to the 2014 Edition version of this
criterion and a ``syndromic surveillance'' certification criterion for
the Proposed Voluntary Edition to permit alternate standards for the
transmission of ambulatory syndromic surveillance data as a means of
providing additional flexibility for EHR technology certification and
for EPs attempting to meet the syndromic surveillance MU objective and
measure. Since publication of the Proposed Rule we have heard from the
CDC that some public health agencies have requested that the CDC
reconsider developing an IG for HL7 2.5.1 as the HL7 2.5.1 standard is
used by some public health agencies.
With consideration of the request to CDC, our overall approach to
this final rule as described in the Executive Summary, and to provide
the most clarity for certification as possible, we are not removing or
revising the current 2014 Edition ``syndromic surveillance''
certification criterion (Sec. 170.314(f)(3)) nor adopting a separate
``syndromic surveillance'' certification criterion for the Proposed
Voluntary Edition. Rather, we have adopted an optional 2014 Edition
``syndromic surveillance'' certification criterion (Sec.
170.314(f)(7)) for the ambulatory setting. The optional

[[Page 54441]]

certification criterion permits EHR technology, for the purposes of
certification, to use any method or standard to electronically create
syndrome-based public health surveillance information for electronic
transmission. Consistent with the intent of our proposal, this will
provide additional certification flexibility for EHR technology
developers and flexibility for EPs attempting to achieve MU. We note
that this approach does not affect the corresponding MU Stage 2
objective and measure.\15\
---------------------------------------------------------------------------

\15\ MU2 Measure: Successful ongoing submission of electronic
syndromic surveillance data from certified EHR technology to a
public health agency for the entire EHR reporting period.
---------------------------------------------------------------------------

We agree with commenters that without specific IGs for the use of
CDA and QRDA III for the transmission of ambulatory syndromic
surveillance data, the standards are not constrained enough on their
own to enable interoperable submissions. However, even before
publication of the Proposed Rule, query-based standards were piloted
and demonstrated in a few cases for ambulatory syndromic surveillance
data, including through the QueryHealth initiative. These efforts and
the use of query-based models continue and we expect the use of query-
based models to grow among public health agencies. Therefore, we
concluded that the best approach at this time was to adopt an optional
``syndromic surveillance'' certification criterion that permits EHR
technology designed for the ambulatory setting to simply demonstrate
that it can electronically create syndrome-based public health
surveillance information for electronic submission (using any method or
standard) to be certified to this criterion. This provides
certification flexibility and potential EP flexibility as mentioned
above, while also providing a path forward as described below.
Because there is no current IG that supports ambulatory syndromic
surveillance data submission using query-based standards, we have also
included an optional set of data elements within this optional
certification criterion to provide some additional specificity and to
which EHR technology developers may choose to have their EHR technology
certified. These data elements are: Patient demographics, provider
specialty, provider address, problem list, vital signs, laboratory
results, procedures, medications, and insurance. While the
aforementioned data elements are optional for the purposes of
demonstrating compliance to this certification criterion, if an EHR
technology developer wishes to certify its EHR technology to this
criterion as a whole, including the optional data set, the EHR
technology would need to demonstrate that it can electronically produce
syndromic surveillance information that contains all of the data
elements. In other words, an EHR technology that could only produce
half of the data elements would not be able to be certified to this
optional portion of the criterion. The public health agencies and
stakeholders that have piloted and continue to pilot query-based models
for transmitting ambulatory syndromic surveillance data send all of the
data elements identified above. Therefore, by identifying these data
elements for certification, EHR technology developers will have clarity
as to the data elements they should focus on for creating syndrome-
based public health information submissions and will need to include to
support query-based models now and in the future, including any
potential certification requirements introduced through future
rulemaking.
The use of the QRDA III standard represents the response portion of
a query-response model, but there currently are no mature standards for
the query portion of the model of which we are aware. We intend to
continue working with stakeholders on standards for both the query and
response portions to support the electronic transmission of ambulatory
syndromic surveillance data. We intend to gather more information
regarding the implementation guidance provided by stakeholders that are
currently piloting or using CDA or constrained QRDA III for ambulatory
syndromic surveillance data transmissions to inform our consideration
of what standards to propose in the future. This work will include
confirming which data elements are commonly transmitted through these
and other query-based models, such as the ones identified above and any
other data elements that may also be typically sent using query-based
approaches.
Given our approach to this final rule as stated in the Executive
Summary, we have not adopted the IG Release 1.9 for inpatient
certification to either the current ``syndromic surveillance''
certification criterion or the optional ``syndromic surveillance''
certification criterion we have adopted in this final rule. We agree
with comments that any issues or errors identified in Release 1.9
should be remedied before requiring the IG for adoption. We also
recognize that the industry is working on Release 2.0 of the IG.
Therefore, we will consider this feedback for future rulemaking
concerning a ``syndromic surveillance'' certification criterion.
We also thank commenters for the input on the usefulness of QRDA
Category I for query-based ambulatory syndromic surveillance and will
consider this feedback for future rulemaking.
Transport Methods (Formerly ``Transmission'') Certification Criteria
As a result of our proposal to decouple content and transport
capabilities from the ToC certification criteria and VDT certification
criterion, we proposed to adopt three separate transport certification
criteria. These three proposed transport certification criteria
mirrored the specific transport capabilities identified within the 2014
Edition ToC certification criteria at Sec. 170.314(b)(1) and (2). The
first criterion mirrored the capability expressed at Sec.
170.314(b)(1)(i)(A) and Sec. 170.314(b)(2)(ii)(A) (i.e., Direct); the
second mirrored the ``optional'' capability expressed at Sec.
170.314(b)(1)(i)(B) and Sec. 170.314(b)(2)(ii)(B) (i.e., Direct and
XDR/XDM for Direct Messaging); and the third mirrored the ``optional''
capability expressed at Sec. 170.314(b)(1)(i)(C) and Sec.
170.314(b)(2)(ii)(C) (i.e., SOAP RTM and XDR/XDM for Direct Messaging).
We stated for all three proposed certification criteria that we
expected them to be tested similarly to how they are tested today
except that only these capabilities would be tested.
Comments. Commenters generally supported the separation of content
and transport (as outlined in more detail under the ToC certification
criterion above) and the inclusion of independent transport
certification criteria in order to support our overall approach to
decoupling content and transport capabilities. Some commenters believed
the first three transport criteria (i.e., Direct, Direct and XDR/XDM
for Direct Messaging, and SOAP RTM and XDR/XDM for Direct Messaging)
should be eligible for gap certification because each capability could
be tested as part of the 2014 Edition ToC criteria. One commenter asked
for clarification regarding the grouping of the proposed certification
criteria. Specifically, the commenter asked if the transport criteria
were separate and could be individually tested and certified.
Response. We have revised the title of this category of
certification criteria for clarity. We now refer to this category of
certification criteria (Sec. 170314(h)) as ``transport methods''
instead of ``transmission.'' We believe this provides better
attribution to the type of criteria and functionality that are included
in this category.

[[Page 54442]]

We appreciate the widespread support and feedback regarding the
decoupling of content and transport requirements. We believe finalizing
three, independent transport criteria will allow technology developers
to build in the transport capabilities suited to their customers'
needs. Therefore, consistent with our earlier discussion related to the
optional ToC certification criterion (Sec. 170.314(b)(8)), we have
decided to adopt all three of the proposed transport capabilities
(previously contained within the ToC certification criteria) in three
separate certification criteria that can be individually tested and
certified. For all three adopted criteria, we have removed the term
``transmit'' from the title of criteria and replaced the regulation
text ``electronically transmitted'' in each criterion with
``electronically sent and electronically received.'' These changes
provide clarity in two ways. They eliminate any confusion with the use
of the term ``transmit'' (or ``transmitted''), which we used in the
2014 Edition Final Rule to mean only ``send from one point to another''
(77 FR 54168). Equally important, the changes clearly specify how these
standards will be tested and certified, which is consistent with how
these standards are currently tested and certified. The changes are
also consistent with our expectations expressed in the Proposed Rule
and recited above about testing and certification.
As noted in the following section (III.A.3 ``Gap Certification
Eligibility Table for 2014 Edition Release 2''), the certification
criteria for Direct, Direct and XDR/XDM for Direct Messaging, and SOAP
RTM and XDR/XDM for Direct Messaging are eligible for gap
certification. We discuss each certification criterion in more detail
in the following comments and responses.
Comments. Some commenters asked that we identify one transport
criterion as the minimum required for transport. The commenters noted
that if one method of transmission were not required, vendors would be
forced to support all transport methods.
Response. As we explained in the preamble of the Proposed Rule, we
seek to maintain the same policy we included in the 2014 Edition Final
Rule--that in order for EPs, EHs, and CAHs to have EHR technology that
met the CEHRT definition they would need to have EHR technology capable
of performing transmissions in accordance with the primary Direct
Project specification. We accentuated this policy by proposing to
modify the Base EHR definition to ensure that it reflected this policy,
which we have finalized in this final rule. Thus, in response to these
comments, we reiterate that the primary Direct Project specification is
still the minimum required transport capability EPs, EHs, and CAHs will
need to meet the CEHRT definition.
Applicability Statement for Secure Health Transport
Comments. Commenters widely supported the adoption of this
certification criterion. One commenter noted that in the case of
immunization information, Direct is a suboptimal transport method.
Response. We appreciate the comments received on this certification
criterion and have adopted this criterion as a new optional
certification criterion at Sec. 170.314(h)(1). We recognize that the
primary Direct Project specification may not be the best fit for every
type of transmission. However, we note that the standard is not
required for public health transmissions.
Applicability Statement for Secure Health Transport and XDR/XDM for
Direct Messaging
Comments. We did not receive any comments suggesting we not adopt
this specific criterion.
Response. We have adopted this criterion as a new optional
certification criterion at Sec. 170.314(h)(2). We note that the
proposed regulation text in the Proposed Rule was not consistent with
the Proposed Rule preamble in that it did not mirror the ``optional''
capability expressed at Sec. 170.314(b)(1)(i)(B) andSec.
170.314(b)(2)(ii)(B) (i.e., Direct and XDR/XDM for Direct Messaging).
Rather, it only referenced the XDR/XDM for Direct Messaging standard.
In what we are adopting in this final rule, we have now aligned the
regulation text with our proposal by including references to both the
XDR/XDM for Direct Messaging (Sec. 170.202(b)) and the Direct standard
(Sec. 170.202(a)).
SOAP Transport and Security Specification and XDR/XDM for Direct
Messaging
Comments. Commenters supported the adoption of this certification
criterion. One commenter noted that this criterion would best support
immunization information transmissions.
Response. We appreciate the comments we received on this criterion
and have adopted this criterion as a new optional certification
criterion at Sec. 170.314(h)(3). We note that the proposed regulation
text in the Proposed Rule was not consistent with the Proposed Rule
preamble in that it did not mirror the ``optional'' capability
expressed at Sec. 170.314(b)(1)(i)(C) and Sec. 170.314(b)(2)(ii)(C)
(i.e., SOAP RTM and XDR/XDM for Direct Messaging). Rather, it only
referenced the SOAP RTM standard. In what we are adopting in this final
rule, we have now aligned the regulation text with our proposal by
including references to both the SOAP RTM standard (Sec. 170.202(c))
and the XDR/XDM for Direct Messaging (Sec. 170.202(b)).
3. Gap Certification Eligibility Table for 2014 Edition Release 2
``Gap certification'' is defined 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. 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.
In the Proposed Rule, we included a table (79 FR 10916) that
provided a crosswalk of unchanged Proposed Voluntary Edition EHR
certification criteria to the corresponding 2014 Edition EHR
certification criteria. We provided corrections to this table in a
notice published in the Federal Register on March 19, 2014 (79 FR
15282). We have provided a new table (Table 3) in this final rule
because we have not adopted the full Proposed Voluntary Edition and
have also made revisions to a proposed certification criterion that we
are including in the 2014 Edition as part of Release 2 (i.e., ``CPOE--
laboratory'' Sec. 170.314(a)(19)). The table below provides a
crosswalk of 2014 Edition Release 2 certification criteria that are
eligible for gap certification using the test results of EHR technology
previously certified to the 2014 Edition and 2011 Edition.

[[Page 54443]]

Table 3--Gap Certification Eligibility for 2014 Edition, Release 2 EHR Certification Criteria
----------------------------------------------------------------------------------------------------------------
2014 edition release 2 2014 Edition 2011 Edition
----------------------------------------------------------------------------------------------------------------
Title of Title of Title of
Regulation section regulation Regulation regulation Regulation section regulation
paragraph section paragraph paragraph
----------------------------------------------------------------------------------------------------------------
Sec. Optional--computeri
170.314(a)(18). zed physician
order entry--
medications.
Sec. Optional--computeri Sec. Computerized Sec. 170.304(a); Computeriz
170.314(a)(19). zed physician 170.314(a)(1). physician order Sec. 170.306(a). ed
order entry-- entry. physician
laboratory. order
entry.
Sec. Optional--computeri
170.314(a)(20). zed physician
order entry--
diagnostic
imaging.
Sec. Optional--ambulator Sec. Transmission to Sec. 170.302(1). Public
170.314(f)(7)*. y setting only-- 170.314(f)(3). public health health
transmission to agencies--syndrom surveillan
public health ic surveillance ce
agencies--syndromi (ambulatory (ambulator
c surveillance. setting only). y setting
only).
Sec. Optional--Applicabi Sec. Transitions of Not applicable.... Not
170.314(h)(1). lity Statement for 170.314(b)(1)(i)( care--receive, applicable
Secure Health. A) and Sec. display, and .
170.314(b)(2)(ii) incorporate
(A). transition of
care/referral
summaries.Transit
ions of care--
create and
transmit
transition of
care/referral
summaries..
Sec. Optional--Applicabi Sec. Transitions of Not applicable.... Not
170.314(h)(2). lity Statement for 170.314(b)(1)(i)( care--receive, applicable
Secure Health B) and Sec. display, and .
Transport and XDR/ 170.314(b)(2)(ii) incorporate
XDM for Direct (B). transition of
Messaging. care/referral
summaries
Transitions of
care--create and
transmit
transition of
care/referral
summaries..
Sec. Optional--SOAP Sec. Transitions of Not applicable.... Not
170.314(h)(3). Transport and 170.314(b)(1)(i)( care--create and applicable
Security C) and Sec. transmit .
Specification and 170.314(b)(2)(ii) transition of
XDR/XDM for Direct (C). care/referral
Messaging. summaries.
----------------------------------------------------------------------------------------------------------------
* Gap certification does not apply for the optional data elements listed in Sec. 170.314(f)(7).

4. Base EHR Definition
We proposed to include in the Base EHR definition (a foundational
part of the CEHRT definition) the Proposed Voluntary Edition EHR
certification criteria that corresponded 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, clinical decision support (CDS), CQMs, transitions of
care, data portability, and privacy and security).
Comments. We received a comment that supported the inclusion of the
proposed CPOE certification criteria in the Base EHR definition because
it would provide the potential for more flexibility and less burden for
EPs, EHs, and CAHs in meeting the Base EHR definition.
Response. We have not revised the Base EHR definition as proposed.
However, we have revised the Base EHR definition to include the
optional CPOE, ToC, and the Direct transport (Sec. 170.314(h)(1))
certification criteria adopted in this final rule. The inclusion of
these certification criteria in the Base EHR definition will, as noted
by the commenter in relation to the CPOE certification criteria, offer
flexibility and reduced burden in meeting the Base EHR definition for
some EPs, EHs, and CAHs.

B. ONC HIT Certification Program

1. Discontinuation of the Complete EHR
We proposed to discontinue use of the Complete EHR definition as a
regulatory concept and the certification of Complete EHRs beginning
with the Proposed Voluntary Edition. As an alternative to the proposal,
if we were to keep the Complete EHR concept and definition for editions
of certification criteria beyond the 2014 Edition, we proposed to
either continue the same policy of adopting an edition-specific
Complete EHR (e.g., ``2015 Edition'' Complete EHR) or 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.'' For the latter,
we noted that ONC-ACBs would be responsible for issuing Complete EHR
certifications that specify the edition the Complete EHR was certified
to and that the information would be evident through listing on the
Certified HIT Product List (CHPL).
Comments. We received many comments from associations representing
providers, consumers, and HIT developers as well as comments from
numerous HIT developers. The overwhelming majority supported our
proposal to discontinue the Complete EHR definition and Complete EHR
certification for the reasons we specified in the Proposed Rule
(recited below in the response). One association was neither for nor
against our proposal, but was more concerned that providers have a
clear understanding of what they are purchasing. In particular, the
association stated that information outlining the product's criteria
should be readily apparent when purchasing the product and also
available on ONC's Web site. A few commenters suggested that we retain
Complete EHR certification as an option for EHR technology developer
and consumer purchasing. One of these commenters recommended that we
tailor a Complete

[[Page 54444]]

EHR certification by the MU Stage it would be associated with, while
another suggested calling it a ``Comprehensive EHR.''
Response. We have finalized our proposal to discontinue the
Complete EHR definition and Complete EHR certification. While we have
not adopted the Proposed Voluntary Edition, this approach will apply
for all future adopted editions of certification criteria as specified
in Sec. 170.501(b) (discussed in more detail under section III.B.2
``Applicability'' of this preamble). To be clear, the discontinuation
of the Complete EHR definition and Complete EHR certification will have
no impact on current 2014 Edition Complete EHR certifications or in
using a 2014 Edition Complete EHR to meet the current CEHRT definition.
In regard to additional 2014 Edition Release 2 certification criteria,
we have adopted them all as optional criteria and thus they do not
impact the 2014 Edition Complete EHR definition.
In the Proposed Rule (79 FR 10917-10918), we explained our
rationale for discontinuing the Complete EHR definition. We are
reciting our rationale again here as we still believe these reasons
hold true. Following the recitation of these reasons, with minor
modifications due to the MU Flexibility Final Rule (79 FR 52910), we
offer further rationale and responses to comments.
(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. The CEHRT definition based on EHR technology certification
to the 2014 Edition (2014 Edition CEHRT definition) and Complete EHR
definition no longer share the same symmetry. In fact, the 2014 Edition
Complete EHR definition now exceeds the 2014 Edition 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. However, some stakeholders believe incorrectly that their
only regulatory option to meet the CEHRT definition is to adopt a
certified Complete EHR when, under the CEHRT definition for FY/CY 2014
and subsequent years in Sec. 170.102, they can use EHR technology (EHR
Module(s)) 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, and 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 2014
Edition CEHRT definition. Consequently, by discontinuing the
availability of the Complete EHR certification, the EHR technology
market could be driven by EHR technology developers competing on the
capabilities included in their EHR technology rather 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 new edition 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 following the structure of the 2014 Edition Complete EHR 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 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).
As stated in the Proposed Rule, discontinuation of Complete EHR
definition and certification does not affect EHR Module certification.
In fact, as it stands now with 2014 Edition certification, an EHR
Module certificate can be issued to an EHR technology that includes
every certification criterion that is included in a Complete EHR
certificate issued to an EHR technology (and even with the EHR Module
certificate, the capabilities can be integrated in the same
manner),\16\ but would not be given the ``Complete EHR'' designation.
The discontinuation of the Complete EHR definition and certification
will also help to address commenters' concerns about clearly knowing
what certification criteria an EHR technology is certified to because,
unlike Complete EHR developers for their Complete EHRs, an EHR Module
developer is required by regulation to specifically list in
communications and marketing materials all the certification criteria
to which the EHR technology was certified and for which it was issued
an EHR Module certificate.

[[Page 54445]]

Therefore, with only EHR Module certificates on the market, we believe
it will be easier to know and compare the certification criteria to
which they have been certified. Last, while we do not believe the use
of the terms ``Complete'' or ``Comprehensive'' are appropriate for
``labeling'' EHR technology going forward, we will consider for our
next rulemaking whether any other ``labeling'' for certified
technologies could continue to make the scope of certification clearer.
---------------------------------------------------------------------------

\16\ To note, the ONC HIT Certification Program does not include
integration testing and certification of Complete EHRs or EHR
Modules as that is left to the EHR technology developer and its
customers.
---------------------------------------------------------------------------

2. Applicability
We proposed 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 Proposed Voluntary
Edition and any subsequent edition of certification criteria adopted by
the Secretary under subpart C. This proposal was consistent with our
proposal to discontinue the use of the Complete EHR concept and
Complete EHR certification beginning with the Proposed Voluntary
Edition.
Comments. We received two comments expressing agreement with our
proposal.
Response. We have finalized our proposal consistent with our
decision to finalize the proposals to discontinue use of the Complete
EHR concept and Complete EHR certification for any subsequent adopted
edition of certification criteria. We have, however, finalized this
proposal in a manner that accounts for our decision not to adopt the
Proposed Voluntary Edition. Specifically, we have revised Sec.
170.501(b) to read: ``References to the term Complete EHR and Complete
EHR certification throughout this subpart do not apply to certification
in accordance with any edition of certification criteria that is
adopted by the Secretary under subpart C after the 2014 Edition EHR
certification criteria.''
3. ONC Regulations FAQ 28
In ONC regulations FAQ 28,\17\ we provide guidance on the
application of Sec. 170.314(g)(1) and (g)(2) to the certification of
Complete EHRs and EHR Modules. We state in FAQ 28 and in the 2014
Edition Final Rule (77 FR 54186) that 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.
---------------------------------------------------------------------------

\17\ https://www.healthit.gov/policy-researchers-implementers/28-question-11-12-028.
---------------------------------------------------------------------------

To provide regulatory clarity, we proposed to revise Sec.
170.550(f)(1) to specify this flexibility for the certification of EHR
Modules to the 2014 Edition and proposed the same flexibility in Sec.
170.550(g)(1) for MU EHR Modules certified to the Proposed Voluntary
Edition ``automated numerator recording'' certification criterion and
the ``automated measure calculation'' certification criterion. We also
clarified that an EHR Module (or proposed ``MU EHR Module'' with regard
to the Proposed Voluntary 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)). We noted that 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, we stated that Sec. 170.550(f)(1) or (g)(1) would not be
implicated or need to be applied.
We proposed 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, which would
implement the 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 too was 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).
We proposed that if were to retain the Complete EHR concept for the
Proposed Voluntary Edition, we would take the same approach for
Complete EHRs as specified in FAQ 28 and in our proposed regulatory
changes to Sec. 170.314(g)(1).
Comments. We received a few comments supporting the continued
requirement for Complete EHRs to be certified to the ``automated
measure calculation'' certification criterion (Sec. 170.314(g)(2)). We
received one comment supporting our proposal 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.
Response. We have not finalized the proposals related to the
Proposed Voluntary Edition because we have not adopted the Proposed
Voluntary Edition. We have, however, finalized the proposals related to
the 2014 Edition. We have designated the ``automated numerator
recording'' certification criterion at Sec. 170.314(g)(1) as an
optional certification criterion, which will provide greater regulatory
clarity for ONC-ACBs as they determine whether EHR technology meets the
2014 Edition Complete EHR definition and therefore must be certified to
Sec. 170.314(g)(2). Certification to Sec. 170.314(g)(2) is required
to meet the 2014 Complete EHR definition as it is a mandatory
certification criterion. This approach is also supported by commenters.
We have revised Sec. 170.550(f)(1) to require ONC-ACBs to certify EHR
Modules to either Sec. 170.314(g)(1) or (2), rather than just
requiring certification to Sec. 170.314(g)(1). This will implement FAQ
28 guidance and flexibility as well as provide regulatory clarity.
We also maintain our clarification and guidance included in the
Proposed Rule related to an EHR Module being able to be certified to
only the ``automated measure calculation'' certification criterion
(Sec. 170.314(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.
4. Patient List Creation Certification Criteria
In the Proposed Rule, we discussed how the 2014 Edition (and
Proposed Voluntary Edition) ``patient list creation'' certification
criterion includes 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

[[Page 54446]]

reminders'') \18\ and ``generate lists of patients by specific
conditions to use for quality improvement, reduction of disparities,
research, or outreach,'' respectively). We clarified that in situations
where EHR technology is presented for certification to the 2014 Edition
(and Proposed Voluntary Edition) ``patient list creation''
certification criterion and does not include a capability to support
``patient reminders,'' it would not need to be certified to the
``automated numerator recording'' certification criterion (Sec.
170.314(g)(1)) nor the ``automated measure calculation'' certification
criterion (Sec. 170.314(g)(2)) for ``patient reminders'' percentage-
based measure capabilities.
---------------------------------------------------------------------------

\18\ The MU measure for this objective is: More than 10 percent
of all unique patients who have had 2 or more office visits with the
EP within the 24 months before the beginning of the EHR reporting
period were sent a reminder, per patient preference when available.
---------------------------------------------------------------------------

Comments. We received a few comments supporting our clarification
and guidance. An ONC-ACB further noted that, in its experience, there
are only a ``handful'' of EHR technologies presented for certification
for which this type of scenario would be applicable.
Response. We appreciate commenters' support and agreement with our
clarification and guidance. While we have not adopted the proposed
``patient list creation'' certification criterion, our clarification
and guidance remains applicable for the certification of EHR technology
to the 2014 Edition ``patient list creation'' certification criterion
(Sec. 170.314(a)(14)). As noted by the ONC-ACB, the clarification and
guidance will be helpful in facilitating the proper certification of at
least some EHR technology to the 2014 Edition ``patient list creation''
certification criterion.
5. 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
International Organization for Standardization/International
Electrotechnical Commission (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, Guide 65. The ISO issued ISO/IEC 17065: 2012 \19\ (ISO 17065),
which cancels and replaces Guide 65.
---------------------------------------------------------------------------

\19\ https://www.iso.org/iso/
cataloguedetail.htm?csnumber=46568. ISO slide presentation
on 17065: https://www.iso.org/iso/
pptpresentation17065.ppt.
---------------------------------------------------------------------------

Because ISO has replaced Guide 65 with ISO/IEC 17065, we proposed
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), we proposed that the
change would be effective as of the effective date of this final rule.
We noted that we anticipated that the effective date of this final rule
would occur after we select an accreditation body as the ONC-AA for the
next three-year term as ANSI's \20\ initial term expired in June 2014.
Because of this, we noted that we would next need to assess applicants
for ONC-AA status in early 2017 and by then we expected that any
applicant would have experience evaluating the conformance of
certification bodies to ISO 17065. For Sec. 170.503(e)(2), we proposed
to require compliance with ISO 17065 beginning in FY 2016 (in other
words, as of October 1, 2015). We stated that 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.
---------------------------------------------------------------------------

\20\ American National Standards Institute, the ONC-AA.
---------------------------------------------------------------------------

We also proposed 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 we received from the Office of the
Federal Register.
Comments. We received comments from the ONC-AA and ONC-ACBs. The
comments from these organizations specifically supported our proposals
transition from Guide 65 to ISO 17065 and to remove the date reference
for each standard.
Response. We appreciate the comments of support for our proposals
and also note that, as anticipated, an accreditation organization
(ANSI) was selected to serve as the ONC-AA for a 3-year term that began
in June 2014.\21\ Based on comments received and the rationale cited in
the Proposed Rule, we have finalized revisions to Sec. 170.503(b)(1)
and (e)(2) as proposed. We have also removed the date references for
the standards in Sec. 170.503 as proposed. In regard to removing the
dates, we have also revised Sec. 170.599(b) to provide clear
attribution to the version of the ISO/IEC standards we are referring to
in Sec. 170.503. More specifically, we identify in Sec. 170.599 that
the ISO/IEC standards will be referred to as ``ISO/IEC 17011,'' ISO/IEC
Guide 65,'' and ISO/IEC 17065'' when used in subpart E of Part 170.
This approach is consistent with guidance from the Office of the
Federal Register.
---------------------------------------------------------------------------

\21\ https://www.hhs.gov/news/press/2014pres/05/20140513c.html.
---------------------------------------------------------------------------

6. ONC Certification Mark
ONC has developed and administers the ``ONC Certified HIT''
certification and design mark (the ``Mark'').\22\ 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 part 170, Subpart C; and
has met all other required conditions of the ONC HIT Certification
Program at 45 CFR part 170, Subpart E.
---------------------------------------------------------------------------

\22\ https://www.healthit.gov/policy-researchers-implementers/onc-hit-certification-program.
---------------------------------------------------------------------------

We proposed to require ONC-ACBs to use the Mark in connection with
HIT they certify under the ONC HIT Certification Program. More
specifically, we proposed 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'').\23\ In
addition, we proposed 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. We noted that, in the event that the Terms of Use are
revised or updated, compliance with the most recent version would be
required.
---------------------------------------------------------------------------

\23\ https://www.healthit.gov/sites/default/files/
hitcertificationtermsofusefinal.p
df.
---------------------------------------------------------------------------

Comments. Commenters expressed agreement with our proposals citing
to the consistency and clarity that a standard mark would provide in
terms of identifying HIT certified under the ONC HIT Certification
Program. One commenter requested clarification as to whether ONC-ACBs
may also use their own mark in conjunction with the Mark, while another
commenter requested clarity as to whether a HIT developer would be
required to use the Mark.
Response. We thank commenters for their support. We have finalized
the revisions to Sec. 170.523 as proposed. As noted by commenters and
in the

[[Page 54447]]

Proposed Rule, the required use of a singular identifying mark will
provide consistency in the recognition of HIT certified under the ONC
HIT Certification Program and mitigate any potential market confusion
for purchasers between HIT products certified under the ONC HIT
Certification Program and those certified under any other program.
While every ONC-ACB will be required to display the Mark on all
certifications issued under the ONC HIT Certification Program in a
manner that complies with the Terms of Use, they will also be able to
use their own marks in conjunction with the Mark as specified in the
Terms of Use under the ``Accompanying Marks, Logos, and Symbols''
section. This would also hold true for a HIT developer that chose to
use the Mark. To this point and to address the requested commenter
clarification, an HIT developer is not required to use the Mark.
However, if they choose to use the Mark, then the ONC-ACB that issued
the certification to the HIT developer would be required to ensure that
the use of the Mark by the HIT developer is compliant with the Terms of
Use. Our expectation is that HIT developers will want to use the Mark
as a way of clearly and easily identifying that their product was
certified under the ONC HIT Certification Program.

C. Removal of the 2011 Edition EHR Certification Criteria From the CFR

We proposed to remove the 2011 Edition EHR Certification Criteria
and related standards, terms, and requirements from the CFR.
Specifically, we proposed to remove 45 CFR 170.302, 170.304, and
170.306. We also proposed to remove the standards and implementation
specifications found in 45 CFR 170.205, 170.207, 170.210, and 170.299
that are only referenced in the 2011 Edition EHR certification
criteria. In regard to terms, we proposed to retire the definitions
found in 45 CFR 170.102 related to the 2011 Edition, including ``2011
Edition EHR certification criteria'' and ``Complete EHR, 2011
Edition.'' In regard to requirements, we proposed 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.
Comments. We received one comment supporting this ``administrative
update.''
Response. In the Proposed Rule, we stated that EHR technology
certified to 2011 Edition no longer meets the CEHRT definition. We also
referenced recent rulemakings by the HHS Office of Inspector General
and CMS around donations of EHR items and services that cited our
expectations to retire old/no longer applicable certification criteria
editions.\24\ As noted in the Proposed Rule, we believe this approach
will streamline our requirements and ensure there is no regulatory
confusion involving administration of ONC's rules and the rules of
other agencies' such as CMS's Physician Self-Referral Law exception and
OIG's Anti-kickback Statute safe harbor for certain EHR donations.
Therefore, 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
removing the 2011 Edition EHR certification criteria and related
standards, terms, and requirements from the CFR.
---------------------------------------------------------------------------

\24\ 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).OIG final rule ``Medicare and State Health Care Programs:
Fraud and Abuse; Electronic Health Records Safe Harbor Under the
Anti-Kickback Statute'' (78 FR 79202).
---------------------------------------------------------------------------

Since publication of our Proposed Rule, we and CMS jointly issued a
final rule entitled ``Medicare and Medicaid Programs; Modifications to
the Medicare and Medicaid Electronic Health Record Incentive Programs
for 2014; and Health Information Technology: Revisions to the Certified
EHR Technology Definition'' (79 FR 52910). The final rule permits EPs,
EHs, and CAHs to use EHR technology certified to the 2011 Edition or a
combination of EHR technology certified to the 2011 Edition and 2014
Edition to meet the CEHRT definition in CY 2014 and FY 2014. To account
for the permitted use of EHR technology certified to the 2011 Edition
to meet the CEHRT definition in 2014 and the potential certification of
EHR technology to the 2011 Edition through the end of CY 2014, the
effective date for the removal of the 2011 Edition EHR certification
criteria and related standards, terms, and requirements from the CFR
will be March 1, 2015.

D. Removal of the Temporary Certification Program From the CFR

The temporary certification program sunset on October 4, 2012, and
is no longer in existence (77 FR 54268). Accordingly, we proposed to
remove from the CFR the associated regulations, consisting of subpart D
(Sec. Sec. 170.400 through 170.499).
Comments. We received no comments on this proposal.
Response. We are removing the temporary certification program
regulations from the CFR on the effective date of this final rule.

IV. Not Adopted Proposals

This section of the preamble discusses proposals from the Proposed
Rule that we have not adopted, including comments received on those
proposals and our response to those comments. As noted in the Executive
Summary, we have not adopted the Proposed Voluntary Edition. Rather, we
have only adopted a small subset of the proposed certification criteria
as optional 2014 Edition EHR certification criteria and made revisions
to 2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange; and administrative
proposals (i.e., removal of regulatory text from the CFR) and proposals
for the ONC HIT Certification Program that provide improvements.

A. Not Adopted EHR Certification Criteria and Certification Criteria
Proposals Applicability--Sec. 170.300

Section 170.300 establishes the applicability of subpart C--
Certification Criteria for Health Information Technology. We proposed
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.
Comments. We did not receive any comments on this specific
proposal.
Response. As noted in the Executive Summary, we have not adopted
the Proposed Voluntary Edition. Rather, we have only adopted a small
subset of the proposed certification criteria as optional 2014 Edition
EHR certification criteria and made revisions to 2014 Edition EHR
certification criteria that provide flexibility, clarity, and enhance
health information exchange. Therefore, we have not revised paragraph
(d) of Sec. 170.300 to add in a reference to Sec. 170.315. The
optional certification criteria that we have adopted in this final rule
will be part of the 2014 Edition and are included in Sec. 170.314,
which is already referenced in paragraph (d) of Sec. 170.300.
Computerized Provider Order Entry--Medications
We proposed to adopt for the Proposed Voluntary Edition a CPOE

[[Page 54448]]

certification criterion specific to medication ordering. The proposed
criterion was structured substantially similar to the 2014 Edition CPOE
certification criterion, except it did not reference laboratory and
radiology/imaging orders. We did not request any specific public
comments on this certification criterion.
Comments. One commenter recommended that we add functionality that
would allow health care providers to electronically report adverse
events related to medications directly to manufacturers and the Food
and Drug Administration (FDA). Another commenter suggested that when
providers order medication, labs and radiology that providers
electronically send a CDA formatted document to the patient, where the
capability exists.
Response. We appreciate these comments, but they are outside the
scope of the proposed criterion. We have not adopted this certification
criterion as part of the Proposed Voluntary Edition because we have not
adopted the Proposed Voluntary Edition. Rather, we have only adopted a
small subset of the proposed certification criteria as optional 2014
Edition EHR certification criteria and made revisions to 2014 Edition
EHR certification criteria that provide flexibility, clarity, and
enhance health information exchange. As discussed under section III.A.2
of this preamble, we have adopted this certification criterion without
modification as a 2014 Edition optional certification criterion.
Computerized Provider Order Entry--Laboratory
We proposed to adopt for the Proposed Voluntary Edition a CPOE
certification criterion specific to laboratory ordering. We proposed 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 (LOI).\25\ We also proposed
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 proposed that laboratory orders must include all the
information for a test requisition as specified at 42 CFR
493.1241(c)(1) through (c)(8). We stated that 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 the Clinical
Laboratory Improvements Amendments (CLIA).
---------------------------------------------------------------------------

\25\ https://www.hl7.org/special/committees/projman/searchableprojectindex.cfm?action=edit&ProjectNumber=922.
---------------------------------------------------------------------------

Comments. Commenters were generally supportive of adoption of
interoperable laboratory standards, particularly the LOI IG, and
aligning requirements with CLIA. Commenters did, however, express
concern with the LOI IG, the use of LOINC[supreg] for all orders, and
the lack of a proposal to adopt the Electronic Directory of Services
(eDOS) IG. Commenters stated that the LOI IG was new, likely
incomplete, and will require substantial updates over the next 12-18
months. Commenters suggested waiting for a more complete version of the
LOI IG, including pilot testing of the IG. Commenters expressed
considerable concern that without the eDOS IG it would be difficult to
achieve optimal interoperability. Commenters stated that LOINC[supreg]
does not cover all orderable tests and that testing and certification
would need to accommodate this fact. Commenters suggested additional
guidance was necessary for compliance with the proposed CLIA
requirements.
Response. We have not adopted this certification criterion as part
of the Proposed Voluntary Edition because we have not adopted the
Proposed Voluntary Edition. Rather, we have only adopted a small subset
of the proposed certification criteria as optional 2014 Edition EHR
certification criteria and made revisions to 2014 Edition EHR
certification criteria that provide flexibility, clarity, and enhance
health information exchange. As discussed under section III.A.2 of this
preamble, we have adopted this certification criterion without
modification as a 2014 Edition optional certification criterion. We
first note that we did not propose to adopt the eDOS IG because it was
our understanding that the eDOS IG was still undergoing revisions at
the time the Proposed Rule was being drafted. We also understood that
the LOI IG was fairly new and we appreciate the stakeholder feedback on
potential concerns with the LOI IG. We also thank commenters for their
insight related to the use of LOINC[supreg] for all laboratory orders.
While we have not adopted the LOI IG at this time, we plan to
reconsider it for adoption in our next rulemaking along with the eDOS
IG. We believe the time between now and our next final rule will permit
many of the concerns with these IGs to be sufficiently addressed.
Overall, the work towards laboratory interoperability and electronic
exchange shows great promise, including the work on the Lab Results
Interface (LRI) IG, Electronic Laboratory Reporting to Public Health
(ELR) IG and harmonization of all laboratory IGs. The adoption of these
standards for the ONC HIT Certification Program could help facilitate
laboratory interoperability and electronic exchange among providers,
assist laboratories with CLIA compliance. and reduce provider burden
with respect to the availability and use of the eDOS IG. As such, we
plan to revisit these standards in future rulemaking.
Computerized Provider Order Entry--Radiology/Imaging
We proposed to adopt for the Proposed Voluntary Edition a CPOE
certification criterion specific to radiology/imaging. The proposed
criterion was structured substantially similar to the 2014 Edition CPOE
certification criterion, except it did not reference medications and
laboratory orders. We did not request any specific public comments on
this certification criterion.
Comments. A few commenters questioned the value of this
certification criterion as is, while other commenters suggested that an
appropriate IG be developed and adopted for this certification
criterion.
Response. We have not adopted this certification criterion as part
of the Proposed Voluntary Edition because we have not adopted the
Proposed Voluntary Edition. Rather, we have only adopted a small subset
of the proposed certification criteria as optional 2014 Edition EHR
certification criteria and made revisions to 2014 Edition EHR
certification criteria that provide flexibility, clarity, and enhance
health information exchange. As discussed under section III.A.2 of this
preamble, we have adopted this certification criterion without
modification as a 2014 Edition optional certification criterion. We
will consider comments on the value of the certification criterion
without any associated standards or IGs and whether there are any
appropriate standards or IGs to adopt as part of future rulemaking.
Drug-Drug, Drug-Allergy Interaction Checks
We proposed a ``drug-drug, drug-allergy interaction checks''
certification criterion for the Proposed Voluntary Edition that was
unchanged as compared to the 2014 Edition certification criterion.
However, we solicited comment on whether drug-drug interaction (DDI) or
drug-allergy interaction (DAI) checks-capable EHR technology should be
able to track

[[Page 54449]]

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 sought
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. In addition, we sought 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. Last, we sought comment on what factors, definitions,
standards, and existing consensus should be considered in determining
whether a likely DDI/DAI reaction should be considered severe.
Comments. Responses from commenters varied. Some commenters
expressed strong support for response tracking for DDI and DAI, and
suggested that a certification criterion also include response tracking
for other interactions, such as drug/lab, drug/diagnosis, food allergy,
drug-gene, therapeutic duplication, and environmental allergy
interactions. One commenter suggested that response tracking
certification exist for CDS interventions in general.
Of those commenters that opposed the inclusion of response tracking
as a certification criterion, several themes surfaced. Some commenters
noted that response tracking would be burdensome, require significant
time and investment, and could conflict with existing system
configuration settings already designed for tracking DDI/DAI provider
responses. Other commenters noted that response tracking functionality
should not be included in a certification criterion and should be
developed in the private sector according to the needs of individual
providers and their health IT developers. A few commenters noted that
response tracking could add an additional layer of alerting and impact
provider workflow. A few others noted that response tracking should
apply specifically to active alerts and should not apply to passive
alerts.
A few commenters noted that response tracking is not appropriate
for an EHR system and that such information is stored and tracked
within Risk Management Information Systems (RMIS) for liability
purposes and for analysis related to efforts to minimize the risk of
future adverse events.
We received a number of specific comments on the scope of response
tracking. Commenters who supported response tracking noted the value
such tracking provides to quality measurement, the improved usefulness
of a DDI/DAI alert criterion that would result from response tracking,
and the importance of such tracking being automated. One commenter
noted that response tracking should track whether the DAI/DAI alert is
``displayed'' and not whether it is ``viewed,'' which the commenter
suggested would impact the provider workflow by requiring provider
action. Others noted that in addition to tracking the response of a
provider, the factors that may have impacted a provider response would
be important to track--such as relevant patient factors or system
construction factors that can influence a provider's reaction to a
specific alert. A similar concern was raised by another commenter who
stated that provider response only provides part of the information
needed, and noted that whether the provider is a seasoned health care
professional or less experienced is an example of corollary information
that could impact whether an ignored DDI/DAI alert is a concern.
We received a variety of comments on who should be able to review
the responses of providers and who should be able to adjust tracking
configuration. Some commenters noted that in order for this proposal to
be operational and, if not already part of existing security protocols,
EHR vendors may need to implement new security classes to control
viewing privileges related to alerts. Some commenters noted that
adjustment of the tracking configuration should be done by the care
team and members of the ordering team, while other commenters noted
that the ability to adjust configuration or review the response
tracking results should be limited to a select few. Many commenters
stated that the decision on who should be able to adjust the tracking
configuration should be determined by the provider or the organization.
One commenter stated that EHR systems also should allow an
administrator to modify the workflow that a provider must take when
certain DDI/DAI alerts appear.
As part of the request for comment, we asked whether EHR systems
should be able to track when an adverse event occurs for a DDI/DAI
alert that is ignored. Many commenters expressed concern regarding
adverse event tracking. Some commenters stated that significant
development would be required to enable this capability in EHR systems.
Other commenters stated that the number of factors that can contribute
to an adverse event would inhibit the usefulness of such a criterion.
Conversely, we heard from several commenters that adverse event
reporting related to DDI/DAI alerts plays an important role. Some
commenters noted that providers should be able to make reports directly
to manufacturers and the FDA about adverse events associated with
medications. One commenter stated that in order for this criterion to
be useful, an approach to adverse events similar to the Vaccine Adverse
Event Reporting System would be needed.
Regarding what factors, definitions, standards, and existing
consensus should be considered in determining whether a likely DDI/DAI
reaction should be considered severe, some commenters noted that
standard vocabularies should be used for exchanging drug-allergy
information and that the DDI/DAI terminology should be standardized.
Other commenters opposed limiting tracking to only DDI/DAI that are
considered severe and suggested that the proposed tracking should apply
to all DDI/DAI because there is little consensus on what characterizes
a severe reaction. Another commenter stated that in lieu of defining
the term ``severe,'' the EHR technology developer or DDI/DAI content
provider should define the term. Another commenter stated that any life
threatening interaction should be considered severe.
A few commenters stated that in the case of medication allergies,
an assessment of severity would not be appropriate. Rather, a
``criticality assessment'' should be used.
We also received several comments on how to improve any future
response tracking certification criterion. One commenter stated that we
should consider how to leverage patient-generated health data to inform
drug interaction and intolerance-related notifications (including over-
the-counter medications). Another commenter suggested that compendia
information should be updated monthly to ensure the efficacy of DDI/DAI
alerts, which the commenter suggested would help ensure that providers
are accessing up-to-date information about allergies and warnings, and
would ensure that the list of FDA-approved treatments is current.
A few commenters stated that pharmacists can play an important role
in DDI/DAI functionality. These

[[Page 54450]]

commenters stated that pharmacists should be able to review data
collected by DDI/DAI response tracking, noting that pharmacists can
help improve the DDI/DAI alert workflow by minimizing provider alert
fatigue as well as mitigate against future adverse events through
review of adverse outcomes. One commenter stated that pharmacy
standards development organizations should be involved in the
development of standards for any future response tracking certification
criterion.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``drug-drug interaction, drug-allergy
interaction'' certification criterion. We will, however, consider all
comments regarding response tracking of DDI/DAI alerts for future
rulemaking concerning a ``drug-drug interaction, drug-allergy
interaction'' certification criterion.
Demographics
We proposed a ``demographics'' certification criterion for the
Proposed Voluntary Edition that was revised in comparison to the 2014
Edition certification criterion. The criterion included a requirement
that EHR technology designed for the inpatient setting be capable of
enabling a user to electronically record, change, and access the ``date
of death.'' We previously included the capability to access the date of
death as part of the 2011 Edition ``demographics'' certification
criterion and inadvertently omitted it from the 2014 Edition. We also
proposed to adopt a new preferred language standard because 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, we noted that 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 proposed three options for which we
solicited public comments: The full ISO 639-2, ISO 639-3, or Request
for Comments (RFC) 5646 to be the preferred language standard for the
proposed ``demographics'' certification criterion. To implement this
proposal, we proposed to modify the regulatory text hierarchy in Sec.
170.207(g) to designate the standard referenced by the 2014 Edition
``demographics'' certification criterion at Sec. 170.207(g) to be at
Sec. 170.207(g)(1).
Comments. We received a few comments on our proposal related to
``date of death'' stating that there was value in such information, but
that commenters were unaware of any EHR technology developers certified
to the 2011 Edition who removed this capability. We received comments
on the preferred language for the ``demographics'' certification
criterion advocating for: No change in the standard, the full ISO 639-
2, ISO 639-3, and RFC 5646. Commenters representing consumer groups and
patients advocated for the inclusion of a standard that covered all
languages and dialects. A commenter noted that, in California, both
Hmong and Cantonese are Medicaid ``threshold languages,'' requiring
additional language assistance services from Medicaid providers. Many
commenters questioned the relative benefit of changing the standard (a
few more languages) in relation to the cost and burden of switching
standards. Commenters also emphasized the need for standards to have
backwards compatibility with already adopted standards and not conflict
with industry standards already adopted for the same purpose, such as
those included in the Consolidated CDA and National Council for
Prescription Drug Programs (NCPDP) standards.
Response. We have not adopted a ``demographics'' certification
criterion. The insightful comments we received on the preferred
language standard necessitate further evaluation of whether the
preferred language standard should be changed, including assessment of
the compatibility and alignment of alternative standards with already
adopted standards and additional cost-benefit analysis of any potential
change in the adopted preferred language standard. Further, based on
comments, there appears to be no need to adopt a revised
``demographics'' certification criterion that simply includes the
``date of death'' functionality. In future rulemaking that may address
the ``demographics'' certification criterion, we will reconsider the
need for specifically including functionality related to ``date of
death.'' We will also consider comments we received on preferred
language standards and our subsequent research on the matter.
Vital Signs, Body Mass Index (BMI), and Growth Charts
We proposed a ``vital signs, body mass index, and growth charts''
certification criterion for the Proposed Voluntary Edition that was
unchanged as compared to the 2014 Edition certification criterion.
However, we solicited comment on whether to require EHR technology to
record vital signs in standardized vocabularies (e.g., LOINC[supreg],
Systemized Nomenclature of Medicine Clinical Terms (SNOMED CT[supreg]),
and The Unified Code of Units of Measure (UCUM)). We also solicited
comments on two approaches if EHR technology were to be required to
record vital signs in standardized vocabularies:
Option 1: Require EHR technology to record vital signs in
standardized vocabularies natively within the EHR;
Option 2: Require EHR technology to record vital signs in
standardized vocabularies only when data was exchanged.
Comments. The majority of commenters supported leaving this
certification criterion unchanged and suggested waiting until the next
edition to propose any changes. A commenter recommended linking weight
information to drug formularies in order to assist licensed clinicians
in selecting the appropriate dosage. Commenters also suggested that the
calculation for creatinine clearance should appear in the header along
with the BMI for the purposes of patient safety and proper dosing of
medications. Another commenter recommended standardizing the use of
international BMI as risk of health conditions may vary by race or
ethnicity.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``vital signs, body mass index, and growth
charts'' certification criterion. We will, however, consider comments
regarding support for medication dosing and use of international BMI
references for future rulemaking concerning a ``vital signs, body mass
index, and growth charts'' certification criterion. We clarify that the
comment solicitation regarding standardized vocabularies and

[[Page 54451]]

options for recording vital signs within the EHR was intended to inform
a future edition of certification criteria, not the Proposed Voluntary
Edition. Therefore, we will also consider the comments received on this
topic as we develop proposals for future rulemaking.
Problem List
We proposed a ``problem list'' certification criterion for the
Proposed Voluntary Edition that was unchanged as compared to the 2014
Edition certification criterion. We did not request any specific public
comments on this certification criterion.
Comments. The majority of commenters supported an unchanged
criterion. One commenter suggested removing this criterion in future
editions because lists in of themselves have no value, but the
commenter noted that lists are useful within the context of CQMs, ToC,
and VDT certification criteria. A few commenters stated that they
support the use of SNOMED CT[supreg] coding for this criterion and not
the use of International Classification of Diseases-10 (ICD-10) as an
additional coding system because its use would require more mappings
and added complexity when using the Consolidated CDA templates. One
commenter recommended adopting the most recent releases of SNOMED
CT[supreg] (International July 2013 and US Extension September 2013).
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``problem list'' certification criterion. We will,
however, consider feedback suggesting that this criterion is
unnecessary in of itself for future rulemaking.
In regard to comments on ICD-10, as we stated in the 2014 Edition
Final Rule, we believe SNOMED CT[supreg] is more appropriate than ICD-
10 for clinical purposes and provides greater clinical accuracy (77 FR
54210). Therefore, it was adopted for the 2014 Edition ``problem list''
certification criterion.
We confirm that the 2014 Edition ``problem list'' certification
criterion requires the use of the SNOMED CT[supreg] July 2012
International Release and March 2012 US Extension as a minimum
standard. Regarding the comment recommending that we adopt the updated
SNOMED CT[supreg] versions, we will reassess whether a newer version of
the minimum standard should be adopted in future rulemaking. As we
stated in the 2014 Edition Final Rule, based on our experience, newer
versions of the ``minimum standards'' code sets that we have adopted
are issued more frequently than our current process can reasonably
accommodate. We do not believe that permitting EHR technology to be
upgraded and certified to newer versions of these code sets would
normally pose an interoperability risk, and therefore we allow use of a
newer version voluntarily for certification without adversely affecting
the EHR technology's certified status unless the Secretary specifically
prohibits the use of a newer version (77 FR 54268). Thus, EHR
technology may be certified to newer versions of SNOMED CT[supreg].
Medication List
We proposed a ``medication list'' certification criterion for the
Proposed Voluntary Edition that was unchanged as compared to the 2014
Edition certification criterion. We did not request any specific public
comments on this certification criterion.
Comments. The majority of commenters supported an unchanged
criterion. One commenter suggested removing this criterion in future
editions because lists in of themselves have no value, but the
commenter noted that lists are useful within the context of CQMs, ToC,
and VDT certification criteria. A few commenters stated that
medications can come from a number of sources, including over-the-
counter, samples, and alternative medicines. These commenters
recommended that a medication list include the most complete list
possible to help minimize patient safety risks.
One commenter stated that the FDA is working to implement
requirements in the Drug Supply Chain Security Act regarding standards
for the interoperable exchange of information for tracing human,
finished, and/or prescription drugs. The commenter recommended that we
be aware of these efforts and align current and future EHR requirements
with any future FDA requirements for standards-based identification of
prescription drugs. Another commenter recommended that EHR technology
be able to track DDI/DAI checks based on a patient's medication list.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``medication list'' certification criterion. We
will consider feedback suggesting that this criterion is unnecessary in
of itself for future rulemaking. We will also consider comments
regarding the FDA's work to implement requirements in the Drug Supply
Chain Security Act, EHR support of DDI/DAI checks, and the definition
and inclusion of types of medications for future rulemaking.
Medication Allergy List
We proposed a ``medication allergy list'' certification criterion
for the Proposed Voluntary Edition that was unchanged as compared to
the 2014 Edition certification criterion.
Comments. The majority of commenters supported an unchanged
criterion. One commenter suggested removing this criterion in future
editions because lists in of themselves have no value, but the
commenter noted that lists are useful within the context of CQMs, ToC,
and VDT certification criteria. Many commenters recommended that the
medication allergy list should include other types of allergies and
intolerances, including food and environmental allergies.
One commenter stated that the FDA is working to implement
requirements in the Drug Supply Chain Security Act regarding standards
for the interoperable exchange of information for tracing human,
finished, and/or prescription drugs. The commenter recommended that we
be aware of these efforts and align current and future EHR requirements
with any future FDA requirements for standards-based identification of
prescription drugs. Another commenter recommended that EHR technology
be able to track DDI/DAI checks based on a patient's medication allergy
list.
One commenter recommended the development of an ``idealized''
interoperable allergy value set that would encompass the same
terminology code base and support documenting patient allergies and
drug sensitivities. This commenter was concerned that currently active
patient medication allergy and drug sensitivities are dominated by the
use of multiple proprietary code sets. The commenter

[[Page 54452]]

stated that codified allergy and drug sensitivity information is
commonly exchanged as free-text or when converted to interoperable code
sets, the original meaning of the documented allergy is lost. The
commenter stated that the National Library of Medicine (NLM)'s RxNorm
source vocabulary concepts and cross-referenced vocabulary terms best
meet the characteristics of the ``idealized'' allergy value set.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``medication allergy list'' certification
criterion. We will consider feedback suggesting that this criterion is
unnecessary in of itself and comments regarding the FDA's work to
implement requirements in the Drug Supply Chain Security Act for future
rulemaking. We note that we solicited specific feedback on vocabularies
to code medication allergies and intolerances for a future edition of
certification criteria and thank the commenters for their detailed
feedback and recommendations on these topics. We will take these
comments into consideration for future rulemaking.
Clinical Decision Support (CDS)
We proposed a ``clinical decision support'' certification criterion
for the Proposed Voluntary Edition that was revised in comparison to
the 2014 Edition certification criterion in several ways. First, we
proposed to incorporate the guidance we provided in FAQ 39 \26\ that
EHR technology certified to the CDS criterion must demonstrate the
capability to use at least one of the more specific data categories
included in the ``demographics'' certification criterion (Sec.
170.315(a)(5)) (e.g., the sex or date of birth). We also proposed to
incorporate guidance we provided in FAQ 34 \27\ to clarify that the CDS
criterion would not require compliance with the Infobutton-enabled
capability for vital signs or medication allergies data. Additionally,
we proposed to discontinue referencing ``laboratory values/results''
data as stakeholder feedback indicated that the Infobutton standard
cannot support this specific data.
---------------------------------------------------------------------------

\26\ https://www.healthit.gov/policy-researchers-implementers/39-question-04-13-039.
\27\ https://www.healthit.gov/policy-researchers-implementers/34-question-12-12-034.
---------------------------------------------------------------------------

We proposed to include and 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 place of the older version referenced by the
2014 Edition certification criterion.
We proposed to adopt two new IGs from the Health eDecisions (HeD)
S&I Framework initiative that support shareable CDS. The first IG
defines requirements for the contents of ``CDS Knowledge Artifacts''
\28\ for event condition action rules, order sets, and documentation
templates (HL7 Implementation Guide: Clinical Decision Support
Knowledge Artifact Implementation Guide, Release 1 (January 2013)
(``HeD standard'')). In addition to proposing to adopt this IG, we
proposed to require EHR technology be able to electronically process a
CDS artifact in the HeD standard. The second IG defines SOAP and REST
web interface requirements needed to send patient data and receive CDS
guidance when a request for clinical guidance is made to a CDS guidance
supplier (HL7 Decision Support Service Implementation Guide, Release 1,
Version 1 (December 2013)). We also proposed 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.
---------------------------------------------------------------------------

\28\ 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.
---------------------------------------------------------------------------

To supplement the HeD proposals, we solicited comment on what we
should focus on for testing and certification of CDS Knowledge
Artifacts, decision support services, and user experience to-date with
implementing the HeD standards.
Comments. Commenters overwhelmingly supported our proposed approach
in FAQ 39 to require that EHR technology certified to a CDS criterion
must demonstrate the capability to use at least one of the more
specific data categories included in the ``demographics'' certification
criterion (Sec. 170.315(a)(5)) (e.g., the sex or date of birth). Some
commenters noted that our FAQs have been previously issued and that
most EHR technology developers have already implemented the policy
clarifications offered by the FAQs. Therefore, the commenters stated
that there is no added value in codifying the FAQs.
Commenters also overwhelmingly supported the proposed approach in
FAQ 34 to not require adherence to the Infobutton standard for
medication allergies or vital signs. They also supported our proposal
to not require adherence to the Infobutton standard for laboratory test
values/results. A few commenters indicated that a more recent version
of the Infobutton standard (Release 4 of the HL7 Infobutton URL-based
Implementation Guide) does support laboratory test values/results.
We received support to adopt the updated HL7 Implementation Guide:
Service-Oriented Architecture Implementations of the Context-aware
Knowledge Retrieval (Infobutton) Domain, Release 1, August 2013.
Commenters also recommended that we do not discontinue referencing the
Infobutton URL-Based IG (HL7 Version 3 Implementation Guide: URL-Based
Implementations of the Context-Aware Information Retrieval (Infobutton)
Domain).
We received mixed feedback on the proposals to adopt the HeD
standards for the two use cases. Some commenters supported adoption of
the HeD standards in the Proposed Voluntary Edition, while others
cautioned that the standards are immature and not well-tested. Those in
support of adoption contended that providers and patients would benefit
from standardized CDS that could help providers make informed decisions
about their patients' care. Commenters also stated that adopting a
standard would lessen the implementation burden on providers as CDS has
normally been customized for each EHR system. A few organizations
commented that they have already successfully piloted the HeD standards
and are in production with a number of groups. Thus, they stated that
the standards were mature and tested enough to require as part of
voluntary certification.
A few commenters suggested further development of diagnostic
imaging CDS and alignment with clinical recommendations for
immunization-based CDS. One commenter recommended that providers be
able to view the HIT developer, bibliographic citation, source of
funding, and release/revision date of a CDS rule for full transparency.
Other commenters noted that the regulation text language of the
proposed CDS certification criterion was

[[Page 54453]]

unclear and that the regulation text could be improved with more
specificity.
The majority of commenters who opposed the HeD proposals expressed
concern about the HeD standards immaturity and lack of testing. Some
also argued that the standards would still be too immature to propose
for the next edition of certification criteria. To support their claim,
many pointed to the work of the S&I Clinical Quality Framework (CQF)
initiative to harmonize and update HeD with standards for CQMs (e.g.,
the Health Quality Measures Format standard (HQMF)). Commenters were
concerned that EHR technology developers would have to significantly
upgrade their systems once the harmonized HeD and HQMF standards become
available and that the amount of rework was not worth the short-term
benefit. Some commenters stated that market demand should drive the
standards and technology for shareable CDS rather than regulation. One
commenter suggested that the two HeD use cases should be evaluated
separately and not lumped together as the user experience to date may
be different between the two.
For testing and certification, many commenters recommended a focus
on a few simple and/or high impact or high clinical value Knowledge
Artifacts and decision support services to simplify the development,
testing, and certification processes. For example, one commenter
recommended focusing testing for the first use case on event action
condition rules as the commenter thought these are the most common type
of Knowledge Artifact and most tested. A few commenters recommended
that we and CMS consider allowing successful pilot testing of the HeD
standards to count toward meeting MU requirements. Last, some
commenters noted at least one case where an EHR accesses a CDS service
based on the HeD standards outside of the EHR and recommended allowing
the CDS service to be external to the EHR.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange.
We agree with commenters that our issued FAQs have addressed
earlier concerns and that most EHR developers have already implemented
the policy clarifications offered by the FAQs. Therefore, there is no
added value in codifying the FAQs at this point in time. There is also
no substantial value in adopting a criterion solely with an updated
Service-Oriented Architecture IG when, as commenters noted, there is a
new URL-based IG that we should also consider for adoption. We will
consider the comments regarding the updated Infobutton Service-Oriented
Architecture IG and updated Infobutton URL-Based IG for future
rulemaking activities and appreciate the detailed responses commenters
provided. To clarify, we did not propose to remove the Infobutton URL-
Based IG (at Sec. 170.204(b)(1)) from the 2014 Edition CDS
certification criterion. Rather, we proposed to include the updated
Service-Oriented Architecture IG as part of the voluntary proposed CDS
certification criterion that we have not adopted. We also agree with
commenters that more deliberation and clarity is needed regarding the
HeD proposals. We will consider the comments on HeD standards maturity,
appropriate use cases, and testing, as well as comments suggesting
improved clarity is needed in the CDS certification criterion
regulatory text in developing future proposals for rulemaking.
Electronic Notes
We proposed an ``electronic notes'' certification criterion for the
Proposed Voluntary Edition that was revised in comparison to the 2014
Edition certification criterion. We included in the proposed
certification criterion a capability to search for information across
separate notes within EHR technology rather than just within one
particular note. We stated that this expanded requirement was intended
to reduce the time providers spend looking for specific patient
information and noted that the requirement to search across notes was
not limited to a specific method. In addition to this proposal, we
requested comments regarding: Whether the proposed functionality should
extend to all patient electronic notes stored in the EHR or just to a
specific patient's electronic notes or specific types of patient notes;
whether we should wait to include the proposed functionality in a
future edition of certification criteria; and whether additional
metadata should be required as part of electronic notes (such as the
HL7 R2 header). We also asked for health care provider opinions on
whether the availability of the proposed 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.
Comments. We received comments, including those from provider
organizations, expressing support for expanding the search
functionality both across a patient's notes and across all patients'
notes in the EHR as a means of improving provider usability. We also
received comments recommending that we not expand the search
capability. These commenters argued that the functionality is not
required for participation in a particular government program (e.g.,
the EHR Incentive Programs), it could stifle innovation, and market-
driven approaches are sufficient to determine if additional search
capabilities are essential or not. Some commenters supported including
enhanced search functionality in the proposed certification criterion,
while others thought we should wait for a future edition. A few
comments supported metadata inclusion with the electronic note, while
most comments saw no value in mandating the inclusion of metadata.
Response. We have not adopted the proposed certification criterion.
Based on comments, we believe further evaluation is necessary as to
whether an enhanced search capability should be included in an
``electronic notes'' certification criterion and for what purpose the
certification of any enhanced search capability would serve. We will
consider the comments received in developing proposals future
rulemaking.
Drug Formulary Checks
We proposed a ``drug formulary checks'' certification criterion for
the Proposed Voluntary Edition that was unchanged as compared to the
2014 Edition certification criterion. However, we solicited public
comment on whether we should leave the criterion as-is (flexible and
without reference to a standard) or if it would be appropriate for us
to adopt a standard in the Proposed Voluntary Edition certification
criterion for which compliance would be required. In the 2014 Edition
Final Rule, we stated it was necessary to require the use of a
particular standard for certification as our certification criterion
was flexible and permitted EHR technology to access and store external
drug formularies in support of MU. As described in more detail in the
Proposed Rule (79 FR 10892), CMS recently finalized a proposal to
recognize NDPDP Formulary and Benefit Standard v3.0 as a backwards
compatible version of NCPDP Formulary and Benefit Standard 1.0 for

[[Page 54454]]

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 (78 FR 74787-74789).\29\ As such, we stated
in the proposed rule that it was an opportune time to solicit comment
on whether to adopt a particular standard for the drug-formulary checks
criterion.
---------------------------------------------------------------------------

\29\ CMS originally proposed retiring version 1.0 on July 1,
2014, but, in response to comment, subsequently decided to postpone
the retirement date to March 1, 2015, to allow the industry adequate
time to implement the necessary changes and testing to implement
version 3.0 (78 FR 74789).
---------------------------------------------------------------------------

We also noted the NCPDP Formulary and Benefit Standard v.4.0's \30\
potential limitations as discussed by the HITSC, including that the
version does not support expanded use cases such as real-time benefit
checks.\31\ Thus, we also solicited comment on whether there are other
standards or solutions (e.g., NCPDP Telecommunication Standard) that
could be used in conjunction with or in place of the NCPDP Formulary
and Benefit Standard to address the potential limitations or expanded
use cases identified by the HITSC.
---------------------------------------------------------------------------

\30\ 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 adopted v.3.0 (77 FR 74787-74789), which includes substantive
changes from previous versions.
\31\ The HITSC has discussed these potential limitations. Please
refer to Clinical Operations Workgroup Update to the HITSC on June
19, 2013. https://www.healthit.gov/FACAS/sites/faca/files/
clinicaloperationswgupdate062013
0.pdf
---------------------------------------------------------------------------

Comments. We received mixed comments regarding the proposal to
adopt a standard (namely the NCPDP Formulary and Benefit Standard v3.0)
for the proposed certification criterion. Some commenters supported
adopting the NCPDP Formulary and Benefit Standard v3.0 (``v3.0'') in
this rule, but most of these commenters recommended its adoption for
the next edition of certification criteria. Those in support of
adopting v3.0 noted the potential to reduce file sizes, which is
beneficial when checking thousands of drug formularies on a daily
basis. Many recommended that we should also accept test results from
the current Surescripts e-prescribing certification without additional
testing requirements.
Some commenters were concerned about known problems with v3.0, and
pointed to the NCPDP Formulary and Benefit Standard v4.0 (``v4.0''),
which may fix some of these known problems. Other commenters were
concerned about rework if we required v3.0 in the proposed
certification criterion followed by requiring v4.0 in the next edition.
One commenter stated that v4.0 is too unstable to require for
certification at this point. Some commenters also stated that the
industry should determine the EHR's drug formulary features and that we
should not be prescriptive in naming a particular standard for
adherence.
One ONC-ACB noted that, in their experience, the current drug-
formulary check criterion is considered an ``easy'' pass during the
certification process. The test procedure requires EHRs to simply show
formulary query results, and therefore the commenter recommended that
we consider expanding the test procedure to capture more of the real-
world setup of the formulary at the patient or practice level. However,
the ONC-ACB noted that this capability may be working fine and may not
need further changes as they have never received any surveillance
complaints regarding formulary features of certified EHR technologies.
Most commenters were in support of the expanded use case for real-
time, patient-level formulary benefit checking. However, we received
mixed opinions on the appropriateness of leveraging the NCPDP
Telecommunication Standard in conjunction with the NCPDP Formulary and
Benefit Standard v3.0 for this expanded use case. One commenter stated
that some of the issues found with the NCPDP Formulary and Benefit
Standard are due to payer implementations rather than issues with the
standard itself. The commenter recommended that we review an NCPDP-
authored white paper describing how payers and vendors should implement
the Formulary and Benefit Standard for maximum benefit.\32\
---------------------------------------------------------------------------

\32\ https://www.ncpdp.org/Education/Whitepaper ``Challenges and
Opportunities for Stakeholders Regarding ePrescribing Technologies
and Formulary Compliance''.
---------------------------------------------------------------------------

Some commenters stated that it was inappropriate to use the NCPDP
Telecommunication Standard for real-time, patient-level benefit
checking as it was not developed with that use case in mind. Rather, it
was developed to respond with coverage information for a pre-selected
medication, not a complete range of treatment options. Additionally,
commenters opined that use of the NCPDP Telecommunication Standard
could result in delays, workflow issues during provider ordering, and
additional EHR performance issues because the standard can take several
minutes to return a response. In addition to the NCPDP
Telecommunication Standard, commenters suggested that we consider the
pros and cons of additional standards that could be leveraged for real-
time benefit checking. These standards include the ASC X12/005010X279
Health Care Eligibility Benefit Inquiry and Response (270/271) standard
and the Proposed Real Time Benefit Check (RTBC) transaction based on a
previous version of NCPDP SCRIPT standard (also referred to by some
commenters as the Surescripts Real-Time Benefit Check standard).
Commenters also referred to different versions of the NCPDP
Telecommunications Standard (e.g., B1 (Billing), D1 (Pre-termination of
Benefits), D.0).
One commenter recommended that as we evaluate alternative standards
for real-time benefit checking, we should also consider protections to
ensure that direct communication between pharmacy benefit managers and
providers does not lead to unwanted advertising or pop-up messaging
intended to influence the prescription decision of a health care
professional at the point of care. A few commenters also recommended
that we consider proposals for automated electronic prior authorization
of medications to allow a prescriber to initiate prior authorization
electronically as part of future rulemaking.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. We will consider
comments regarding the pros and cons and maturity of the NCPDP
Formulary and Benefit Standard v3.0 and v4.0 for future rulemaking. We
will also examine whether we can learn from and/or leverage the
processes of existing certification programs as well as improve the
test procedure for this certification criterion as part of future
rulemaking.
We thank commenters for their detailed responses about specific
standards for the expanded use case of real-time, patient-level
formulary and benefit checking, and will continue to examine the pros
and cons of each to inform our future rulemaking. We will consider
these comments and comments encouraging adoption of standards for
electronic prior authorization for future rulemaking. Additionally, as
part of our continued work, we will seek to understand the differences
among the versions of the NCPDP Telecommunication Standard and

[[Page 54455]]

between the RTBC transaction with the Surescripts Real-Time Benefit
Check standard. As to the comment suggesting that we prohibit unwanted
advertising or pop-up messaging in communications between providers and
pharmacy benefit managers, we believe this request falls outside the
scope of the ONC HIT Certification Program.
Smoking Status
We proposed a ``smoking status'' certification criterion for the
Proposed Voluntary Edition that was unchanged as compared to the 2014
Edition certification criterion. We did not request any specific public
comments on this certification criterion.
Comments. We received comments expressing support for this
certification criterion as unchanged. A few commenters noted that there
is misalignment with the code sets adopted for the 2014 Edition and
proposed ``smoking status'' certification criteria and the Consolidated
CDA Release 2.0 and e-clinical quality measures (eCQMs). A few
commenters also suggested that we consider requiring the capture of
additional forms of tobacco use, such as smokeless tobacco and betel
nut use.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``smoking status'' certification criterion. We
note that we have also not adopted the proposed Consolidated CDA
Release 2.0 as discussed under the ToC certification criterion in this
section (IV.A). We will, however, take the comments about expansion of
the smoking code set and alignment with the Consolidated CDA Release
2.0 and eCQMs under consideration for future rulemaking concerning a
``smoking status'' certification criterion and the Consolidated CDA
standard.
Image Results
We proposed an ``image results'' certification criterion for the
Proposed Voluntary Edition that was unchanged as compared to the 2014
Edition certification criterion. We did not request any specific public
comments on this certification criterion.
Comments. We received a small number of comments on this proposed
unchanged criterion. A majority of the comments received on this
proposal simply indicated their support for keeping this certification
criterion as-is. However, some commenters offered additional
suggestions, including one that suggested we remove this certification
criterion in the next edition. This commenter did not believe the
functionality expressed in the certification criterion would be
relevant until a quality or incentive program existed that defined
clear objectives for its use as well as the requirement of consistent
vocabulary and interoperability support through common standards.
Another commenter recommended that images be of diagnostic quality.
Other commenters suggested that we incorporate the adoption of the
Digital Imaging and Communication in Medicine (DICOM) standards in
future editions. One commenter suggested that future editions should go
beyond the ``accessibility'' of images to focus on the transmission of
images. Commenters also stated that the interoperability of imaging
among different EHR systems must be supported through standards.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``image results'' certification criterion. The
2014 Edition certification criterion was expressly adopted to support
the correlated MU objective and associated measure, which focuses on
the accessibility of electronic imaging results through CEHRT. We point
readers to the 2014 Edition Final Rule (77 FR 54173) in which we
concluded ``that the adoption of the DICOM standard (or any other
standards) was unnecessary to enable users with electronic access to
images and their narrative interpretations.'' We will take the DICOM
suggestion as well as those comments that encouraged a broader
certification criterion into consideration for future rulemaking, if
the intended purpose for which this certification criterion was adopted
changes or new functionality for testing and certification appears
necessary.
Family Health History
We proposed a ``family health history'' (FHH) certification
criterion for the Proposed Voluntary Edition that was revised in
comparison to the 2014 Edition certification criterion. We proposed to
adopt the HL7 Pedigree IG, HL7 Version 3 Implementation Guide: Family
History/Pedigree Interoperability, Release 1 and to include only the
HL7 Pedigree standard and the new IG in this certification criterion,
and no longer permit demonstrating the use of only SNOMED CT[supreg] to
code family health history as a means of meeting this certification
criterion.
Comments. Some commenters expressed general agreement with the
proposal, noting that the proposed approach should improve
interoperability by moving to one standard and patient care through use
of a more comprehensive standard. Many commenters were against moving
solely to the HL7 Pedigree standard. Commenters argued that there was a
high burden in shifting to HL7 Pedigree, particularly after just
adopting SNOMED CT[supreg] for FHH. Commenters also expressed concern
about Consolidated CDA compatibility and, as they described it, HL7
Pedigree's nominal benefit in terms of genomics. Commenters also
recommended identifying an appropriate use case for moving solely to
HL7 Pedigree, noting that HL7 Pedigree relies on SNOMED CT[supreg] for
coding problems and problems is the predominate use case for coding FHH
among most providers.
Response. We have not adopted the proposed FHH certification
criterion. The comments received suggest further evaluation is needed
as to whether moving to solely the HL7 Pedigree standard for FHH serves
an appropriate use case for certification and whether the benefits
exceed any potential costs and burden for developers and providers.
Patient List Creation
We proposed a ``patient list creation'' certification criterion for
the Proposed Voluntary Edition that was revised in comparison to the
2014 Edition certification criterion. We proposed to include text in
the proposed ``patient list creation'' certification criterion
clarifying that EHR technology must demonstrate its capability to use
at least one of the more specific data categories included in the
proposed ``demographics'' certification criterion (e.g., sex or date of
birth), which

[[Page 54456]]

incorporated the guidance provided in FAQ 39.\33\
---------------------------------------------------------------------------

\33\ https://www.healthit.gov/policy-researchers-implementers/39-question-04-13-039.
---------------------------------------------------------------------------

Comments. We received only a few comments on this proposal.
Commenters expressed support for this proposal. Commenters also stated
that the certification criterion was essentially the ``same'' as the
2014 Edition by incorporating FAQ 39 because the FAQ applies for
certification to the 2014 Edition certification criterion. One
commenter suggested that instead of requiring the use of ``at least
one'' demographic data element in the creation of patient lists that we
require ``at least two'' demographic data elements.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would simply incorporate
guidance that EHR technology developers are already following for
certification to the 2014 Edition ``patient list creation''
certification criterion.
The required use of a minimum of two demographic elements was not
proposed. Therefore, we have insufficient stakeholder feedback on the
potential requirement's benefit versus its burden. We will, however,
consider this suggestion in relation to future rulemaking activity
concerning a ``patient list creation'' certification criterion.
Patient-Specific Education Resources
We proposed a ``patient-specific education resources''
certification criterion for the Proposed Voluntary Edition that was
revised in comparison to the 2014 Edition certification criterion. We
proposed to adopt this certification without the requirement that EHR
technology be capable of electronically identifying patient-specific
education resources based on ``laboratory values/results'' due to
stakeholder feedback indicating that the Infobutton standard does not
support this level of data specificity. We proposed to adopt the HL7
Implementation Guide: Service-Oriented Architecture (SOA)
Implementations of the Context-aware Knowledge Retrieval (Infobutton)
Domain, Release 1, August 2013, which is an updated version of the IG
we adopted for the 2014 Edition. To clearly distinguish this IG in the
regulation text from the prior version, we proposed a technical
amendment to Sec. 170.204(b)(2).
We proposed to revise the regulation text to be more consistent
with the intent and interpretation of the 2014 Edition certification
criterion regulation text that we expressed in the 2014 Edition Final
Rule.\34\ We noted that the text of the proposed certification
criterion made 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. We also noted that the guidance we provided in FAQ 40
\35\ would still be applicable to the proposed ``patient-specific
education resources'' certification criterion.
---------------------------------------------------------------------------

\34\ 77 FR 54216.
\35\ https://www.healthit.gov/policy-researchers-implementers/40-question-04-13-040.
---------------------------------------------------------------------------

We requested 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 proposed
certification criterion, a potential future ``patient-specific
education resources'' certification criterion, or both. The 2014
Edition and proposed certification criterion require EHR technology to
demonstrate the capability to electronically identify for a user
patient-specific education resources using Infobutton and an
alternative method. We sought 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 sought 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 proposed certification
criterion, in a potential future certification criterion, or in both.
Comments. We received comments supporting removal of the laboratory
values/results data element, adoption of the updated SOA IG, and the
proposed clarifying regulation text. We received comments supporting
both options (1) and (3) related to the methods EHR technology must
demonstrate for providing patient-specific education resources. Most
commenters preferred option (3). No commenters expressed support for
option (2). Consumer and patient advocacy groups supported providing
patient-specific education resources in a patient's preferred language,
while EHR technology developers did not support this proposal due to
the burden they stated it would create because of the great number of
potential languages and the lack of content resources for all potential
languages. These commenters also noted that burden would far exceed the
benefits (e.g., the number of patients requesting patient-specific
education resources in a preferred language).
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. We will consider the
comments on the specific proposed changes to the certification
criterion as well as the comments on the methods EHR technology must
demonstrate for providing patient-specific education resources and the
use of preferred language in providing those resources for future
rulemaking concerning a ``patient-specific education resources''
certification criterion.
Electronic Medication Administration Record
We proposed an ``electronic medication administration record''
(eMAR) certification criterion for the Proposed Voluntary Edition that
was unchanged as compared to the 2014 Edition certification criterion.
We did not request any specific public comments on this certification
criterion.
Comments. The majority of commenters supported an unchanged
criterion. One commenter suggested removing this criterion in future
editions because the market drove availability and adoption of this
functionality before it was introduced in the 2014 Edition. This
commenter also opined that the functionality could be

[[Page 54457]]

better improved as part of or in the context of the CDS criterion.
Another commenter stated that CDS at the point of medication
administration would serve as an additional quality check. A commenter
stated that a bar code administration process is needed to fulfill this
requirement. A commenter also suggested that a distinction be made for
data models that include pro re nata (PRN) medications that are
prescribed ``as needed'' and may not actually be given on a regular
basis. The commenter stated that these medications may be included in
the denominator even though they may never be included in the
numerator, and thus the commenter opined that PRN medications should be
treated differently than other medications.
One commenter stated that the FDA is working to implement
requirements in the Drug Supply Chain Security Act regarding standards
for the interoperable exchange of information for tracing human,
finished, and/or prescription drugs. The commenter recommended that we
be aware of these efforts and align current and future EHR requirements
with any future FDA requirements for standards-based identification of
prescription drugs.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. We will consider, in
regards to future rulemaking, feedback that this criterion is
unnecessary in of itself, comments regarding the FDA's work to
implement requirements in the Drug Supply Chain Security Act, comments
providing guidance for fulfilling this requirement, and comments noting
the distinction between PRN medications and other medications given on
a regular basis.
Advance Directives
We proposed an ``advance directives'' certification criterion for
the Proposed Voluntary Edition that was unchanged as compared to the
2014 Edition certification criterion. We did not request any specific
public comments on this certification criterion.
Comments. Commenters expressed support for the proposed unchanged
certification criterion. Some commenters suggested, however, that this
certification criterion be further enhanced by requiring HIT certified
to this certification criterion to be able to record the electronic
location of an advance directive, provide a link or instructions to the
location of an advance directive, provide the content of an advance
directive, and include other care planning documents such as a
Physicians Order for Life-Sustaining Treatment (POLST).
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``advance directives'' certification criterion. We
will, however, consider whether this certification criterion should be
enhanced in any of the ways mentioned by commenters as part of future
rulemaking activity concerning an ``advance directive'' certification
criterion.
Implantable Device List
We proposed to adopt a new certification criterion for EHR
technology to demonstrate that it is able to record and display a
unique device identifier (UDI) \36\ and other information about a
patient's implantable devices. We noted that this proposal represented
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
and the July 2, 2013 HHS Health Information Technology Patient Safety
Action and Surveillance Plan.\37\ We also provided a short summary of
the FDA's regulatory activity associated with the UDI.
---------------------------------------------------------------------------

\36\ A UDI is a unique numeric or alphanumeric code that
consists of two parts: (1) A device identifier (DI), a mandatory,
fixed portion of a UDI that identifies the labeler and the specific
version or model of a device, and (2) a production identifier (PI),
a conditional, variable portion of a UDI that identifies one or more
of the following when included on the label of a device: The lot or
batch number within which a device was manufactured; the serial
number of a specific device; the expiration date of a specific
device; the date a specific device was manufactured; the distinct
identification code required by 21 CFR 1271.290(c) for a human cell,
tissue, or cellular and tissue-based product (HCT/P) regulated as a
device. https://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/UniqueDeviceIdentification/.
\37\ https://www.healthit.gov/sites/default/files/
safetyplanmaster.pdf
---------------------------------------------------------------------------

In our proposal, we explained our belief that EHR technology will
play a key role in the widespread adoption and utilization of UDIs and
that EHRs' use of UDIs can help reduce device-related medical errors
and provide other significant patient safety, health care quality, and
public health benefits. For example, 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. We also noted that 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.
As part of our proposal, we recognized that additional standards
and technical specifications would be required to support the full
range of contemplated capabilities and uses, and that efforts to
identify or develop these standards are already underway. Nevertheless,
we stated our belief that specifying some baseline functionality as
part of a certification criterion would be important in order for EHR
technology developers to consider the functionality necessary to
capture, store, and retrieve UDIs and other contextually relevant
information associated with a patient's medical devices, specifically
implantable devices.
Our proposal focused on a certification criterion that would assess
an EHR technology's ability to record UDI information about implantable
devices. More specifically, we proposed that EHR technology would have
to show that it could 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.'' We also proposed that EHR
technology would need 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. Our last proposal focused on an EHR
technology's ability to parse the UDI in order to extract and allow a
user to view the ``device

[[Page 54458]]

identifier'' and ``production identifier'' portions of the UDI.
Combined with this specific certification criterion's proposal, we
also proposed that the UDI would need to be included as part of a
Consolidated CDA in each of the following proposed criteria:

Sec. 170.315(b)(1)--Transitions of care;
Sec. 170.315(b)(6)--Data portability;
Sec. 170.315(e)(1)--View, download, and transmit to 3rd
party; and
Sec. 170.315(e)(2)--Clinical summary.

Finally, we proposed to modify Sec. 170.102 to include new
definitions for ``implantable device,'' ``unique device identifier,''
``device identifier,'' and ``production identifier'' in order to
prevent any misinterpretation and ensure that each term's specific
meaning reflected the same meaning given to them in the Unique Device
Identification System Final Rule and in 21 CFR 801.3. We also sought
public comment on issues outside the scope of the Proposed Rule in
order to inform future rulemaking considerations, which we noted in the
Proposed Rule would not be responded to in this final rule.
Comments. Many commenters supported the overall intent behind the
proposed certification criterion. These commenters recognized its
potential benefits to patient safety and supported the adoption of a
certification criterion focused on implantable device list
functionality. Some commenters (including those that conceptually
supported the proposed criterion) contended that the proposed
certification criterion was complex, included new workflow
considerations and, from a timing perspective, that it would be
premature to adopt a certification criterion including the proposed
functionality in this final rule. Instead, they suggested that we wait
for the next rulemaking (the rulemaking we expressed our intention to
issue with CMS to accompany policy updates to the EHR Incentive
Programs) as that would provide EHR technology developers more time to
design their systems as well as time for the FDA to continue to make
progress on the broader technical infrastructure necessary to
comprehensively support the UDI.
Other commenters, mostly EHR technology developers, suggested that
the proposed criterion would not be applicable or relevant to the
ambulatory setting (due to where implantable device UDI data would be
most routinely captured in the inpatient setting) and requested that we
scope this criterion to be specific to the inpatient setting. A few
commenters suggested that this certification criterion might be ill-
suited for both the ambulatory and inpatient settings because the
capture of implantable device identifiers would take place in surgical
HIT systems. Additionally, some commenters suggested limiting the scope
of the certification criterion to focus just on storing only the UDI
number as structured data and include the criterion in a future edition
of certification criteria without any of the added functional
requirements proposed in the Proposed Rule. Another commenter suggested
expanding the scope of the certification criterion to include all
devices as opposed to the implantable device scope we had included in
our proposal, as greater alignment should exist between EHR technology
and other technologies used to support supply chain management.
Commenters stated that we had not clearly identified specific use
cases that the proposed certification criterion was meant to support.
They requested greater clarity in order to better understand how the
UDI data was to be used. In that regard, some commenters expressed
concern that including the UDI data as part of information exchange
transactions (specifically in the Consolidated CDA only) would be
premature and suggested that we work with other standards development
organizations (such as HL7, NCPDP, and X12) to clarify when and to whom
the UDI would need to be communicated. Along different lines, one
commenter suggested that we modify the proposal to ``electronically
record the UDI'' to focus on the EHR technology recording the UDI in
its complete and parsed state and similarly presented to users in an
understandable manner. Another commenter suggested that EHR technology
have the capability to generate patient lists by a particular device.
Several commenters requested that we require as part of the
certification criterion the use of AIDC technology, while another
commenter acknowledged that the system behavior for EHR technology
could be similar to that described in the 2014 Edition eMAR
certification criterion. These commenters reasoned that an EHR user
should not have to manually enter the UDI as it would be inefficient
and that the UDI's length could increase the risk of harm due to
inaccurate data entry. At least one commenter indicated that financial
constraints surrounding AIDC technology could hamper investments in
such technology and cause its use to be delayed.
Response. We have not adopted this certification criterion. We
believe additional work is necessary to further refine our proposal
based on public comments. We very much appreciate the detailed comments
submitted, including those that pointed to areas where we need to
provide additional detail and clarity. We believe that our next
rulemaking can provide such detail and clarity, and intend to propose a
UDI-focused certification criterion that reflects the input provided.
Transitions of Care
We proposed to make several changes to the ToC certification
criterion, including adopting an updated version of the Consolidated
CDA, certain data quality constraints on the creation of Consolidated
CDAs to improve patient matching, a proposed ``performance standard''
that would have required EHR technology to successfully electronically
process validly formatted Consolidated CDAs no less than 95% of the
time, and the inclusion of UDI information.
Updated Consolidated CDA Standard
We proposed to incorporate an updated version of the Consolidated
CDA Standard, HL7 Implementation Guide for CDA Release 2: Consolidated
CDA Templates for Clinical Notes (U.S. Realm), Draft Standard for Trial
Use, Release 2.0 (``Release 2.0''), which was balloted in the summer of
2013. We proposed to include Release 2.0 in four certification
criteria: ToC, VDT, clinical summary, and data portability.
Comments. We received many comments on this proposal. The majority
of commenters, especially those from EHR technology developers,
developer associations, and certification bodies, did not support this
proposal. Commenters voiced concerns that Release 2.0 was so new that
many stakeholders had not had the chance to review it and it had not
been sufficiently piloted. In addition, commenters pointed out a
technical problem with the update, known as ``bilateral asynchronous
cutover'' wherein Release 2.0 is not backwards compatible with previous
versions of the Consolidated CDA and therefore a provider with a 2014
Edition certified product could not receive a document conformant to
the Release 2.0 standard. These commenters supported considering
Release 2.0 for future editions of our certification rules. Consumer
advocacy groups supported the proposal, noting that the additional
functionality included in Release 2.0 such as new structural elements
for care plans, patient goals, and health

[[Page 54459]]

outcomes were important to longitudinal health and care planning and
therefore should be included.
Response. We have not adopted Release 2.0 for any certification
criteria in this final rule. We appreciate the detailed feedback we
received from the developer community and agree that more work remains
to address some of the challenges expressed by stakeholders. We remain
interested in moving to Release 2.0 and acknowledge that pilot testing
is occurring. We will continue to monitor the pilot testing and any
other developments concerning Release 2.0 and will consider them in
determining whether to include Release 2.0 in a future rulemaking.
ToC Interoperability and MU Stage 2 ``Cross-Vendor'' Exchange
We proposed to create a new ``cross-vendor'' exchange requirement.
We proposed to require EHR technology certified to the ToC
certification criterion to demonstrate that it can successfully
electronically process validly formatted Consolidated CDAs no less than
95% of the time.
Comments. We received many comments on this proposal. Overall,
commenters did not support our proposal. Commenters voiced concerns
about the testability of this requirement. Commenters also questioned
the likelihood that the proper set of testing documents could be
collected, which would prevent efficient testing and development.
Commenters questioned how we determined the 95% threshold and requested
we provide evidence supporting that limit. Commenters stated that the
95% threshold would be impractical, time consuming, and expensive to
implement, given the wide variation in Consolidated CDA implementation.
Commenters also noted that the proposal was vague and confusing, and
sought additional information about various portions of the proposal,
including what it means to ``electronically process.'' Commenters
supported constraining the Consolidated CDA as a better way to achieve
our stated goals.
Response. Given our approach in this final rule to only adopt a
small subset of the proposed certification criteria as optional 2014
Edition EHR certification criteria and include revisions to 2014
Edition EHR certification criteria that provide flexibility, clarity,
and enhance health information exchange, we have not finalized this
proposal. We agree that a more constrained Consolidated CDA is an
equally implementable approach to reducing the implementation ambiguity
and flexibility afforded in the current Consolidated CDA. We encourage
industry stakeholders to take such steps. We will re-consider this
proposal and the comments received for future rulemaking.
``Create'' and Patient Matching Data Quality
We proposed to include a limited set of standardized data (79 FR
10900) as a part of the ``create'' portion of the Proposed Voluntary
Edition ToC criterion to improve the quality of the data included in
outbound summary care records. We also sought comment on additional
data to include and other constraints that could be applied to this
data to improve its quality.
Comments. Overall, the vast majority of commenters supported the
policy that standardized patient identifying attributes should be
required and captured by certified EHR technology for use in relevant
exchange transactions. Commenters overwhelmingly supported the
inclusion of the proposed constrained specifications for last name/
family name, suffix, first/given name, middle/second name, date of
birth, current address and historical address, phone number, and sex in
support of patient matching.
We received an especially large amount of feedback regarding the
address proposal. Commenters suggested that we delay support for
international standards for address until future editions of
certification criteria. Commenters also provided feedback that the
United States Postal Service format specifications are not in sync with
other MU requirements, such as the LRI and LOI IGs, and recommended
further review of the appropriate address standardization. Commenters
also recommended the inclusion of a field for ``former name'' as many
patients change their names for purposes beyond marriage.
Commenters noted that some of the proposed data elements would come
from practice management systems that EHRs do not control, including
maiden name, historical address and phone number (including multiple
phone numbers), and recommended these fields be made optional. Some
commenters stated that the proposed standardization was premature,
raising usability and privacy concerns and urging us to do further
analysis.
Response. Given our approach in this final rule to only adopt a
small subset of the proposed certification criteria as optional 2014
Edition EHR certification criteria and include revisions to 2014
Edition EHR certification criteria that provide flexibility, clarity,
and enhance health information exchange, we have not adopted this
proposal. We will consider comments regarding patient matching
functionality for future rulemaking.
Unique Device Identifier Information
We proposed to include UDIs for a patient's implantable device
within a created Consolidated CDA formatted document.
Comments. As noted in the UDI section, commenters stated that it
was premature to include implantable device information in Consolidated
CDA formatted documents and raised questions about the Consolidated
CDA's ability to support such information.
Response. We have not finalized our proposal to include the UDI
information in a Consolidated CDA formatted document given our decision
not to adopt a UDI certification criterion at this time. We appreciate
the comments from stakeholders and will consider them for future
rulemakings.
Electronic Prescribing (e-prescribing)
We proposed an ``e-prescribing'' certification criterion for the
Proposed Voluntary Edition that was unchanged as compared to the 2014
Edition certification criterion. We did not request any specific public
comments on this certification criterion.
Comments. The majority of commenters supported an unchanged
criterion. One commenter suggested merging this criterion with the
CPOE--medications certification criterion. Multiple commenters
recommended that we adopt the NCPDP ``SCRIPT Implementation
Recommendations'' guidance document that provides clarity on how to
populate e-prescribing transactions.\38\ One commenter endorsed the
inclusion of RxNorm drug identifiers to provide quality controls for
drug identification and promote interoperable exchange of medication
information. This commenter recommended use of RxNorm in place of a
representative National Drug Code (NDC). One commenter suggested that
we consider requiring transmission of in-language prescription labels
to prevent inappropriate misuse of prescriptions.
---------------------------------------------------------------------------

\38\ The most recent version of this document is Version 1.26
May 2014.
---------------------------------------------------------------------------

A commenter noted that the FDA is working to implement requirements
in the Drug Supply Chain Security Act regarding standards for the
interoperable exchange of information for tracing human, finished, and/
or prescription drugs. The commenter recommended that we be aware of
these

[[Page 54460]]

efforts and align current and future EHR requirements with any future
FDA requirements for standards-based identification of prescription
drugs.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. We will consider
comments including those on vocabularies, the NCDPD SCRIPT
implementation guidance, prescription labeling, and the FDA's work to
implement the requirements in the Drug Supply Chain Security Act for
future rulemaking activity concerning an ``e-prescribing''
certification criterion.
Incorporate Laboratory Tests and Values/Results
We proposed an ``incorporate laboratory tests and values/results''
certification criterion for the Proposed Voluntary Edition that was
revised in comparison to the 2014 Edition certification criterion.
Specifically, we proposed to include in the criterion the HL7 Version
2.5.1 Implementation Guide: Standards and Interoperability Framework
Laboratory Results Interface, Release 1 (U.S. Realm) (S&I Framework
LRI) with Errata.\39\ We also proposed more specific requirements for
how EHR technology must be capable of electronically displaying the
information included in a test report. As stated in the Proposed Rule,
this specificity would improve the consistency with how laboratory
tests and values/results are displayed, which would also assist
laboratories with CLIA compliance. We proposed to require EHR
technology to be capable of displaying the following information
included in laboratory test reports it receives: 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).
---------------------------------------------------------------------------

\39\ https://www.hl7.org/implement/standards/
productbrief.cfm?productid=279.
---------------------------------------------------------------------------

Comments. Commenters were generally supportive of adoption of
interoperable laboratory standards, particularly the LRI IG with
errata, and with aligning requirements with CLIA. Commenters did,
however, express concerns. Commenters recommended that major errata in
the proposed LRI IG be tested further before normative balloting,
stating that this would give laboratories and HIT developers more
awareness of significant changes and time to implement and test the
changes before the IG becomes normative. EHR technology developers
expressed concerns with specific requirements for EHRs to display
information that they stated would routinely be captured in a
laboratory information system or other system and not available to
EHRs. Commenters also strongly recommended that there should be
harmonization across all IGs (e.g., LRI, LOI, ELR, eDOS, CDA and other
IGs) for consistent process, behavior, terminology, and usage.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. We believe, however,
that there is great promise and value in the LRI IG in terms of
improving the interoperability of laboratory test results/values, the
electronic exchange of laboratory test results/values, and compliance
with CLIA for laboratories. We believe work is currently being done to
address the concerns of commenters, such as addressing interoperability
concerns and ambiguities with the LRI IG with errata, testing use of
the LRI IG, developing implementation guidance for EHR functionality,
and harmonizing all laboratory standards and IGs. Accordingly, while we
have not adopted the proposed certification criterion at this time or
the LRI IG with errata, we intend to revisit this certification
criterion and the use of an updated LRI IG along with CLIA requirements
in a future rulemaking.
Transmission of Electronic Laboratory Tests and Values/Results to
Ambulatory Providers
We proposed a ``transmission of electronic laboratory tests and
values/results to ambulatory providers'' certification criterion for
the Proposed Voluntary Edition that was revised in comparison to the
2014 Edition certification criterion. Specifically, we proposed to
include in the criterion the HL7 Version 2.5.1 Implementation Guide:
Standards and Interoperability Framework Laboratory Results Interface,
Release 1 (U.S. Realm) (S&I Framework LRI) with Errata.\40\ We also
proposed to include new functionality that would improve the
consistency with how laboratory tests and values/results are sent,
received, and displayed. As stated in the Proposed Rule, this would
assist laboratories with CLIA compliance. We proposed to require EHR
technology to be capable of including in the laboratory test reports it
creates for electronic transmission: 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).
---------------------------------------------------------------------------

\40\ https://www.hl7.org/implement/standards/
productbrief.cfm?productid=279.
---------------------------------------------------------------------------

To make the CFR easier to follow for readers, we proposed to adopt
the updated S&I Framework LRI at Sec. 170.205(j)(2), which would
require 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).
Comments. The comments we received on this proposed certification
criterion were substantially similar to the comments we received on the
``incorporate laboratory tests and values/results'' certification
criterion discussed above. We refer readers to those comments.
Response. We have not adopted this certification criterion. Our
rationale for not adopting this certification criterion is the same as
that provided for the ``incorporate laboratory tests and values/
results'' certification criterion discussed above. We refer readers to
that response.
Data Portability
We proposed a ``data portability'' certification criterion for the
Proposed Voluntary Edition that was revised in comparison to the 2014
Edition certification criterion. We proposed to include in the
certification criterion the Consolidated CDA Release 2.0 and UDIs for a
patient's implantable device within a created Consolidated CDA
formatted document.
Comments. The comments we received regarding the Consolidated CDA
Release 2.0 in response to this criterion were similar to those
received on the other four criteria that we proposed to incorporate it
within. The majority of commenters thought it was premature to adopt
Release 2.0 and that

[[Page 54461]]

Release 2.0 would create backwards compatibility issues with previous
versions of the Consolidated CDA, thus preventing the receipt of the
new version. Commenters recommended we do not include it in the data
portability certification criterion at this time. Commenters also
stated that it was premature to include patient implantable device
information (i.e., UDIs) in Consolidated CDA formatted documents.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As discussed under
the ToC certification criterion in this section (IV.A) of the preamble,
we have not adopted the Consolidated CDA Release 2.0. As discussed
under the ``implantable device list'' certification criterion in this
section (IV.A) of the preamble, we have not adopted that proposed
certification criterion. We will, however, in relation to future
rulemaking activity, consider the comments received concerning a ``data
portability'' certification criterion, the Consolidated CDA Release
2.0, and a patient's implantable device list and associated UDIs.
Clinical Quality Measures--Capture and Export
We proposed a ``clinical quality measures--capture and export''
certification criterion as part of the Proposed Voluntary Edition that
was unchanged as compared to the 2014 Edition certification criterion.
We did, however, solicit public comment on the potential usefulness of
broadening the export requirement to include a QRDA Category II
formatted data file.
Comments. We received a few comments that the immunization CQMs do
not match well with the Advisory Committee on Immunization Practice's
recommendations. A commenter suggested that we should not update the
standards we adopted for CQMs in the 2014 Edition until the industry
has had sufficient time to adjust to the current standards. One
commenter suggested that we and CMS revise the current eCQM process and
provide a database configuration that all EHR technology developers,
EPs, EHs, and CAHs would install. The commenter stated that the
configuration would be able to take raw data and produce the desired
output for each eCQM and QRDA submission, thereby reducing the burden
on EHR technology developers to adapt to changes in the database schema
and data collection.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``clinical quality measures--capture and export''
certification criterion. Our request for comment on the potential
usefulness of broadening the export requirement to also include a QRDA
Category II formatted data file was to inform our decision-making for
future rulemaking. We will take comments received on this topic into
consideration with the comments received regarding clinical
recommendations, standards maturity, and the current eCQM process for
future rulemaking concerning CQMs.
Clinical Quality Measures--Import and Calculate
We proposed a ``clinical quality measures--import and calculate''
certification criterion as part of the Proposed Voluntary Edition that
was unchanged as compared to the 2014 Edition certification criterion.
We did not request any specific public comments on this certification
criterion.
Comments. One commenter stated that this criterion requires a level
of patient matching that does not currently exist. This commenter
encouraged the creation of a national patient identification number.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``clinical quality measures--import and
calculate'' certification criterion. We thank commenters and understand
the importance of matching clinical quality data with the right
patient. We note that we solicited comments on patient matching in the
Proposed Rule and discuss this topic in more detail under the ``ToC''
certification criterion in this section (IV.A) of the preamble.
However, we note that we have not adopted patient matching requirements
in this final rule given our rulemaking approach and will consider
comments on the topic for future rulemaking.
Clinical Quality Measures--Electronic Submission
We proposed a ``clinical quality measures--electronic submission''
certification criterion for the Proposed Voluntary Edition that was
unchanged as compared to the 2014 Edition certification criterion. We
did not request any specific public comments on this certification
criterion.
Comments. A few commenters noted the discrepancies between the QRDA
Category I and III standards referenced in the 2014 Edition and the
subsequently issued CMS QRDA Category I and III IGs dictating the
``form and manner'' of eCQM submission to CMS, as required for
participation in the Physician Quality Reporting System and Inpatient
Prospective Payment System programs. Commenters noted that the CMS QRDA
IGs issued in 2013 had some conflicts with the base QRDA Category I and
III standards named in the 2014 Edition. Commenters also stated that
the CMS QRDA IG publication dates (April 1, 2013 for EHs, June 1, 2013
for EPs) did not provide sufficient time for EHR updates, testing, and
rollout to providers. Therefore, these commenters suggested we remove
the language in paragraph (ii) of this criterion requiring the
electronic data file can be electronically accepted by CMS.
Two commenters recommended that we not adopt standards that are in
draft standard for trial use (DSTU) form and wait until they become
normalized standards. These commenters noted that the QRDA Category I
and III standards adopted in the 2014 Edition are still DSTUs. One
commenter added that no regulatory action has been taken to incorporate
the errata to the QRDA Category I and III standards since their release
in 2013. Another commenter stated that the QRDA Category I and III
standards are not widely used to transmit data.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR

[[Page 54462]]

certification criteria that provide flexibility, clarity, and enhance
health information exchange. As proposed, this certification criterion
would offer no value as an optional 2014 Edition certification
criterion because it would be the same as the current 2014 Edition
``clinical quality measures--electronic submission'' certification
criterion. We will consider comments received on this criterion
regarding QRDA standards maturity and program-specific QRDA IGs for
future rulemaking concerning CQMs.
Clinical Quality Measures--Patient Population Filtering
We proposed a new ``clinical quality measures--patient population
filtering'' certification criterion for the Proposed Voluntary Edition
that would require filtering of CQMs by patient population
characteristics. Certain CMS reporting programs such as the
Comprehensive Primary Care initiative and Pioneer Accountable Care
Organization model may determine financial incentives or bonus payments
based on the performance of an entity other than the individual
provider. To support CQM reporting for these groups, we proposed to
require 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 more of 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; and
Demographics including age, sex, preferred language,
education level, and socioeconomic status (SES).
To inform our proposal, we solicited comment on whether current CQM
standards (e.g., QRDA Category I and Category III) can collect metadata
for the characteristics listed above, and filter and create a CQM
report for a particular characteristic or combination of
characteristics. We also solicited comment on vocabulary standards that
could be used to record the characteristics proposed above.
Comments. We received mixed comments on the proposal to adopt a new
certification criterion to support filtering of CQMs by patient
characteristics. Those commenters in support of the proposal stated
that the added functionality included in the certification criterion
would help address health disparities and social determinants of
health. Some commenters believed that collecting the data in a
structured way would allow data to be filtered. One commenter pointed
to the National Quality Forum's draft report on ``Risk Adjustment for
Socioeconomic Status or Other Socioedemographic Factors,'' which
recommends stratification of measures on the basis of relevant socio-
demographic factors when the intended purpose is to identify and reduce
disparities.\41\ Additionally, commenters stated that the proposal
would help providers participating in programs where the reporting is
at an aggregate, rather than individual, provider level. Some
commenters noted that the use case for this functionality was not made
clear in the preamble.
---------------------------------------------------------------------------

\41\ https://www.qualityforum.org/WorkArea/linkit.aspx?LinkIdentifier=id&ItemID=75398.
---------------------------------------------------------------------------

A few commenters pointed out that race and ethnicity were not
included in the proposed list of characteristics and strongly urged us
to consider including race and ethnicity. Commenters also suggested the
inclusion of practice type, practice specialty, sexual orientation and
gender identity, and disability status in the list of characteristics
required for filtering. Some commenters suggested that we perform a
full inventory of the possible data elements that CQMs could be
filtered by before proposing a list.
We also received comments expressing concern about the level of
work required to build the proposed functionality into EHRs. Commenters
pointed out that some of the proposed data elements are typically found
within administrative systems (e.g., practice address and insurance
data) while other data is found within clinical systems such as the
EHR. Commenters opined that while some systems can easily merge
administrative and clinical data, not all systems currently have this
capability and thus the ability to support this proposed criterion
varies. Many commenters noted that proposed characteristics, such as
age, sex, diagnosis, NPI, and TIN, are being collected in standardized
ways within EHRs, but that there are not standard vocabularies or
definitions for other data elements such as education and SES. One
commenter recommended using a standard for collecting education based
on the standard used by the National Center for Health Statistics. Some
commenters were concerned about the complexity of establishing a
definition and standard for SES as it could factor in information on
occupation, education, income, wealth, and place of residence.
Commenters stated that this kind of data is not typically collected in
a clinical setting. Additionally, SES could change over time and thus
the inputs may change, adding further complexity.
Regarding standards for quality measurement, some commenters
remarked that the QRDA standards can currently capture the data
elements needed to filter CQMs by certain patient population
characteristics, although not all data elements in standardized form as
noted above. Commenters stated that the HQMF standard can currently
support filtering by patient characteristics but not by other provider
or location variables such as address, TIN, and NPI. Additionally, a
commenter stated that HQMF does not have the ability to indicate the
level at which a measure needs to be evaluated and summarized. The
commenter contended that this could affect whether patients are
identified in the initial patient population for group reporting or
not, and would impact whether the patient is filtered or not.
Response. Given the feedback we received, we believe additional
work is needed to further refine our proposal. Therefore, we have not
adopted this certification criterion. We clarify that we envision two
types of uses for this functionality: 1) Filtering of CQM results to
support the identification of health disparities, to help providers
identify gaps in quality, and to support a provider in delivering more
effective care to sub-groups of their patient populations, and 2) to
support administrative and group/ACO reporting of CQMs where the unit
of measurement is not the individual provider. We are considering
whether this functionality could be a standalone certification
criterion or an additional functionality included in a new version of
the ``clinical quality measures--import and calculate'' certification
criterion at Sec. 170.314(c)(2). As we have considered stakeholder
feedback on the workflow to filter CQMs, EHRs may need to first
calculate the CQM and then be able to stratify/filter results by
certain characteristics.
We agree with commenters that there are standardized vocabularies
to collect some of the data elements we proposed, but not all. We
recognize that more work is needed to identify standards for other data
elements we proposed. We also recognize that the list we proposed is
not a complete set, and that there are additional data elements the
stakeholders may wish to filter by. We appreciate the comments
regarding standards for quality reporting (e.g.,

[[Page 54463]]

QRDA and HQMF), and will use this feedback to inform our future
rulemaking. We will also take into consideration comments on the level
of filtering and summarization of CQMs for group and ACO reporting.
Authentication, Access Control, and Authorization
We proposed an ``authentication, access control, and
authorization'' certification criterion for the Proposed Voluntary
Edition that was unchanged as compared to the 2014 Edition
certification criterion. We did, however, solicit comments on the issue
of two-factor authentication to support two use cases: E-prescribing of
controlled substances; and remote provider access. In 2010, the Drug
Enforcement Agency (DEA) removed the federal ban on e-prescribing
controlled substances. The DEA requires the use of two-factor
authentication protocol when e-prescribing. In 2012, the HITPC
recommended that we adopt multi-factor authentication by providers
remotely accessing protected health information. We asked the public to
respond to two questions:
(1) Should we adopt a general two-factor authentication requirement
for certification?
(2) Were the HITPC's recommendations appropriate and actionable?
Comments. All commenters supported the certification criterion as
unchanged. Commenters did not support a broad two-factor authentication
requirement for certification. The majority of the commenters did,
however, support the inclusion of two-factor authentication
functionality for the specific purpose of e-prescribing controlled
substances. Some commenters noted that the DEA's requirements were more
complex than basic two-factor authentication and urged us to consult
with the DEA before creating a criterion to support this use case.
Commenters were divided in their support for requiring two-factor
authentication for remote access for providers. Commenters agreed that
the HITPC's recommendations regarding remote access for providers were
actionable. However, comments varied with regard to whether the
recommendation was appropriate for remote access. Specifically,
commenters were concerned that differences in EHR systems (i.e., cloud-
based versus practice-installed) created ambiguity as to when the
requirement would apply and sought clarity in the term ``remote
access.'' In addition, commenters voiced concern about the potential
criterion becoming too prescriptive, with many commenters urging us to
propose a criterion that required EHRs to support these use cases
without describing how they did so. Commenters further noted concern
about the ability to test two-factor authentication.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``authentication, access control, and
authorization'' certification criterion. We will consider comments
regarding the use of two-factor authentication to support e-prescribing
of controlled substances and remote access for providers in future
rulemaking concerning an ``authentication, access control, and
authorization'' certification criterion.
Auditable Events and Tamper-Resistance
We proposed an ``auditable events and tamper-resistance''
certification criterion for the Proposed Voluntary Edition that was
revised in comparison to the 2014 Edition certification criterion. We
proposed this certification criterion in response to a report by the
OIG entitled, ``Not All Recommended Safeguards Have Been Implemented in
Hospital EHR Technology'' (OEI-01-11-00570).\42\ We proposed to require
EHR technology to prevent all users from being able to disable an audit
log. We asked for public comment on the impact and potential unintended
consequences of such a change and for specific examples where disabling
an EHR technology's audit log is warranted.
---------------------------------------------------------------------------

\42\ https://oig.hhs.gov/oei/reports/oei01-11-00570.pdf.
---------------------------------------------------------------------------

Comments. The majority of commenters, including EHR technology
developers, EHR developer associations, and the HITSC, did not support
preventing all users from being able to disable the audit log.
Commenters stressed that there were valid and important reasons for
users to disable the audit log, including allowing a system
administrator to disable the audit log for performance fixes,
stability, disaster recovery, and system updates or allowing a system
administrator to disable it when there is rapid server space loss which
is hindering a provider from accessing needed clinical information in a
timely manner. Commenters stated that the majority of EHR developers do
not currently allow audit logs to be disabled. Commenters also stated
that preventing the disabling of the audit log was a best practice, but
should not be included in the certification criterion because of cases
of emergency or disaster that would necessitate disabling of the audit
log. Other commenters, including providers, provider associations,
consumer advocates, and EHR technology developers, supported the OIG
recommendation. Consumer advocates and others commented that preventing
the audit log from being disabled would improve consumers' trust. A
minority of commenters supported identifying a baseline set of
auditable actions that should be prevented from being disabled. The
baseline set included additions, deletions, and other changes.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. Additionally, in
response to the significant and detailed feedback we received
recommending that we do not finalize our proposal, we will further
evaluate whether it is appropriate to implement the OIG report's
recommendation. As many commenters noted, there are valid reasons that
require a limited number of EHR users to be capable of disabling the
audit log. We will continue to engage with stakeholders regarding audit
log functionality, and will consider stakeholder feedback in regard to
future rulemaking concerning an ``auditable events and tamper-
resistance'' certification criterion.
Audit Report(s)
We proposed an ``audit report(s)'' certification criterion for the
Proposed Voluntary Edition that was unchanged as compared to the 2014
Edition certification criterion. We did not request any specific public
comments on this certification criterion as part of the Proposed
Voluntary Edition.
Comments. Commenters supported the proposed certification criterion
as unchanged.
Response. We thank commenters for their support of this proposed
unchanged certification criterion. We have not, however, adopted this

[[Page 54464]]

certification criterion because we have not adopted the Proposed
Voluntary Edition. Rather, we have only adopted a small subset of the
proposed certification criteria as optional 2014 Edition EHR
certification criteria and made revisions to 2014 Edition EHR
certification criteria that provide flexibility, clarity, and enhance
health information exchange. As proposed, this certification criterion
would offer no value as an optional 2014 Edition certification
criterion because it would be the same as the current 2014 Edition
``audit report(s)'' certification criterion.
Amendments
We proposed an ``amendments'' certification criterion for the
Proposed Voluntary Edition that was unchanged as compared to the 2014
Edition certification criterion. We did not request any specific public
comments on this certification criterion.
Comments. Commenters supported the proposed certification criterion
as unchanged. Some commenters noted the importance of this
certification criterion and recommended records tag patient-generated
amendments to denote the appropriate provenance.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``amendments'' certification criterion. We will,
however, consider the comments about data provenance of amendments for
future rulemaking activity concerning an ``amendments'' certification
criterion.
Automatic Log-Off
We proposed an ``automatic log-off'' certification criterion for
the Proposed Voluntary Edition that was unchanged as compared to the
2014 Edition certification criterion. We did not request any specific
public comments on this certification criterion.
Comments. Commenters supported the proposed certification criterion
as unchanged.
Response. We thank commenters for their support. However, we have
not adopted this certification criterion because we have not adopted
the Proposed Voluntary Edition. Rather, we have only adopted a small
subset of the proposed certification criteria as optional 2014 Edition
EHR certification criteria and made revisions to 2014 Edition EHR
certification criteria that provide flexibility, clarity, and enhance
health information exchange. As proposed, this certification criterion
would offer no value as an optional 2014 Edition certification
criterion because it would be the same as the current 2014 Edition
``automatic log-off'' certification criterion.
Emergency Access
We proposed an ``emergency access'' certification criterion for the
Proposed Voluntary Edition that was unchanged as compared to the 2014
Edition certification criterion. We did not request any specific public
comments on this certification criterion.
Comments. Commenters supported the proposed certification criterion
as unchanged. One commenter expressed concerns that untrained users
could make a mistake in a complex EHR system related to access.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``emergency access'' certification criterion. In
response to the comment on ``untrained'' users, we note that the 2014
Edition certification criterion (and the proposed ``emergency access''
criterion) requires EHR technology to be able to designate a ``set of
users.'' A provider would determine appropriate users and access to
their system in conjunction with the EHR technology developer, which is
not part of the certification process under the ONC HIT Certification
Program.
End-User Device Encryption
We proposed an ``end-user device encryption'' certification
criterion for the Proposed Voluntary Edition that was unchanged as
compared to the 2014 Edition certification criterion. We did not
request any specific public comments on this certification criterion.
Comments. Commenters supported the proposed certification criterion
as unchanged.
Response. We thank commenters for their support. However, we have
not adopted this certification criterion because we have not adopted
the Proposed Voluntary Edition. Rather, we have only adopted a small
subset of the proposed certification criteria as optional 2014 Edition
EHR certification criteria and made revisions to 2014 Edition EHR
certification criteria that provide flexibility, clarity, and enhance
health information exchange. As proposed, this certification criterion
would offer no value as an optional 2014 Edition certification
criterion because it would be the same as the current 2014 Edition
``end-user device encryption'' certification criterion.
Integrity
We proposed an ``integrity'' certification criterion for the
Proposed Voluntary Edition that was unchanged as compared to the 2014
Edition certification criterion. We did not request any specific public
comments on this certification criterion.
Comments. Commenters supported the proposed certification criterion
as unchanged.
Response. We thank commenters for their support. However, we have
not adopted this certification criterion because we have not adopted
the Proposed Voluntary Edition. Rather, we have only adopted a small
subset of the proposed certification criteria as optional 2014 Edition
EHR certification criteria and made revisions to 2014 Edition EHR
certification criteria that provide flexibility, clarity, and enhance
health information exchange. As proposed, this certification criterion
would offer no value as an optional 2014 Edition certification
criterion because it would be the same as the current 2014 Edition
``integrity'' certification criterion.
Accounting of Disclosures
We proposed an ``accounting of disclosures'' certification
criterion for the Proposed Voluntary Edition that was unchanged
substantively as compared to the 2014 Edition certification criterion.
We did, however, propose to remove the ``optional'' designation from
this certification criterion for the Proposed Voluntary Edition because
such a designation would no longer be necessary with the proposed
discontinuation of the Complete EHR concept.
Comments. All of the comments received supported leaving the
certification criterion unchanged. Commenters overwhelmingly
recommended that we do not remove the optional designation regardless
of

[[Page 54465]]

other proposed changes. Commenters suggested removing the optional
designation would create confusion in the marketplace and require
significant additional development work.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. We note that
commenters apparently misunderstand the purpose of designating
certification criteria as optional. As we explained in the Proposed
Rule (79 FR 10918), the designation of ``optional'' for certification
criteria was 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 definition and certification). Complete EHR certification
is still permitted to the 2014 Edition. Therefore, as proposed, it
would make no sense to adopt this certification criterion as part of
the 2014 Edition as it is substantively the same as the current 2014
Edition ``accounting of disclosures'' certification criterion and,
without the optional designation, it would directly contradict the
current 2014 Edition ``accounting of disclosures'' certification
criterion and EHR technology would be required to certify to it for a
Complete EHR certification.
View, Download, and Transmit to 3rd Party
The summary of the proposals in the Proposed Rule recited in this
section only summarize and include the ``comments'' and ``response''
for the proposals that we have not adopted in this final rule. For the
VDT proposal made in the Proposed Rule and adopted in this final rule,
including a summary of what was proposed for that proposal, please see
section III.A.2 of this preamble.
We proposed to revise the VDT criterion in a number of ways,
including: Clarifying introductory text in order to clearly specify
that this criterion expressed patient facing capabilities for patient
use; decoupling the content and transport requirements and in tandem
proposing a revision that would more clearly express EHR technology's
ability to support a patient's ability to choose the destination or to
whom they wanted to send their health information; updating the
Consolidated CDA version with the corresponding inclusion of UDI
information; increasing the Web Content Accessibility Guidelines (WCAG)
level to level AA; and revising the activity history log requirement to
record two additional data elements (the addressee to whom an
ambulatory summary or inpatient summary was transmitted and whether
that transmission was successful).
Comments. Commenters generally supported clarifying the
introductory text of VDT. Commenters stressed the importance of
allowing authorized representatives the ability to perform the VDT
functionality. Some EHR technology developers opposed revisions related
to the clarification around a patient's ability to ``download'' a human
readable file, a Consolidated CDA file, or both. A commenter
representative of the majority of EHR technology developers indicated
that the revised criterion is overly prescriptive and not in sync with
actual software development. The commenter stated that EHR technology
developers enable users to download the XML version and the style sheet
together, since the style sheet is applied to the XML to provide the
human-readable information. The commenter concluded that most patients
would find making a choice confusing and did not believe that patients
would benefit from this proposal.
With respect to our proposal for EHR technology to enable a patient
to choose the destination or whom they wanted to send their health
information via Direct, many commenters opposed or raised concerns
about this proposal. Most of these commenters were EHR technology
developers who identified a number of technical concerns with the
proposal. They stated that:
EHR technology cannot guarantee that any message sent to a
Direct address specified for transmission will reach the endpoint. Each
HISP has rules beyond the EHR's control specifying their exchange with
other HISPs.
The ability of a patient to enter a third party
destination of their choice (i.e., initiate a direct exchange using a
valid direct exchange address) would imply that the EHR technology has
the ability to determine if the address entered is valid. When a
patient enters an address, the EHR technology would not know if it is
valid and with the separation of content from transport, the EHR
technology would no longer control the Domain Name System/Lightweight
Directory Access Protocol (DNS/LDAP) look up to ensure that the
certificate is valid and included within the sender's HISP trust
circle.
Patients have not, and will not any time soon, be given
Direct addresses because it is too great an expense.
We received many comments on our proposal to update the
Consolidated CDA version to Release 2.0. The majority of commenters,
especially those from EHR technology developers, HIT developer
associations, and certification bodies, did not support this proposal.
Commenters voiced concerns that Release 2.0 was so new that many
stakeholders had not had the chance to review it and it had not been
sufficiently piloted. In addition, commenters pointed out a technical
problem with the update, known as ``bilateral asynchronous cutover''
wherein Release 2.0 is not backwards compatible with previous versions
of the Consolidated CDA and therefore a provider with a 2014 Edition
certified product could not receive a document conformant to the
updated Consolidated CDA standard. These commenters supported
considering Release 2.0 for future editions of our certification
criteria. Consumer advocacy groups supported the proposal, noting that
the additional functionality included in Release 2.0, such as new
structural elements for care plans, patient goals, and health outcomes,
were important to consumers and care planning.
We received mixed comments on our proposal to move to WCAG Level
AA, including many from EHR technology developers. Some opposed the
increased level citing the cost and burden to reach Level AA.
Conversely, other EHR technology developers supported the move and
offered no concerns. In both cases, EHR technology developers noted
that WCAG conformance tools are somewhat sparse and that they have had
difficulty finding viable tools. Of the few comments on whether a
hybrid of Level A and Level AA would be preferred, the comments opposed
this type of approach because it would lead to variability and
inconsistency.
Most commenters supported the inclusion of the intended recipient
in the activity history log. Commenters voiced concern about requiring
a history log to record whether the transmission was successful, noting
that EHRs do not have information on what happens to a message once it
leaves the EHR and is processed by the HISP. Commenters stated that
prior to being able to make this information patient accessible,
standards development would be necessary to support this use case. Some
commenters agreed that activity history logs should record and include
both new data points and stated that this

[[Page 54466]]

transaction history provides important information about care
coordination that patients should be able to access.
Response. We appreciate the detailed feedback we received on many
of the VDT proposals. While we are not revising the 2014 Edition VDT to
include the proposed clarifying regulation text, we note for commenters
that the requirement to provide patients with the ability to download a
human readable version, a Consolidated CDA version, or both, already
exists within the 2014 Edition VDT certification criterion. As
discussed in the Proposed Rule, the clarification was not a
modification of existing policy. Rather, it was an attempt at more
clearly articulating existing policy to avoid any confusion. As EHR
technology developers indicated, we have long-standing policy that
permits them to satisfy this approach through the use of a style sheet,
which would be an acceptable approach because it would give a patient
both human readable and Consolidated CDA versions.
We have also decided to leave the 2014 Edition certification
criterion unmodified with respect to our proposal to enable a patient
to choose the destination or whom they wanted to send their health
information via Direct. We will consider the technical challenges
raised by EHR technology developers. In the case of the Consolidated
CDA update, we have already discussed our decision not to adopt this
proposal in the discussion on the ToC criterion (Section IV.A) and do
not adopt it for the VDT certification criterion for the same reasons.
In response to comments, we will continue to evaluate the WCAG level
and suitable testing approaches. Last, we will continue to evaluate
comments on our proposal to expand the activity history log and its
connection to some of the technical challenges identified by comments.
Overall, given our approach in this final rule to only adopt a
small subset of the proposed certification criteria as optional 2014
Edition EHR certification criteria and include revisions to 2014
Edition EHR certification criteria that provide flexibility, clarity,
and enhance health information exchange, we have not adopted any of the
proposals discussed in this section.
Clinical Summary
We proposed a ``clinical summary'' certification criterion for the
Proposed Voluntary Edition that was revised in comparison to the 2014
Edition certification criterion. We proposed to reflect the
clarifications we provided in FAQ 33 \43\ (i.e., require the use of
LOINC[reg] for diagnostic tests pending and future scheduled tests to
the degree such test could be coded in LOINC[reg]), to require the use
of CVX codes for immunizations, and reference the Consolidated CDA
Release 2.0 (including UDI(s) for a patient's implantable device(s) as
data within a created Consolidated CDA formatted document) in the
proposed certification criterion. We requested comment on whether
LOINC[reg] can be used to represent all possible diagnostic tests
pending and future scheduled tests.
---------------------------------------------------------------------------

\43\ https://www.healthit.gov/policy-researchers-implementers/33-question-12-12-033.
---------------------------------------------------------------------------

We also reiterated 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
certification criterion as well as the 2014 Edition ``clinical
summary'' certification criterion. We stated that 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. We clarified that in terms of
customization of the clinical summary, this permits the user to limit
this data in the clinical summary if so desired. We further clarified
that 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. Last, we noted that
this certification criterion, like the 2014 Edition ``clinical
summary'' certification criterion, was designed to support the
associated MU objective and measure that seeks to provide a patient
with a record of the office visit and specific lab tests or specific
follow-up actions and treatment related to the office visit.
Comments. We received many comments supporting the required use of
CVX and LOINC[reg]. A few commenters opposed the use of LOINC[reg]
codes, while others suggested the use be required ``where applicable''
because LOINC[reg] cannot currently cover all possible tests. We
received comments for and against the use of the Consolidated CDA
Release 2.0 and the inclusion of UDI(s). Commenters also expressed
varying opinions on the data that should be included in a clinical
summary. Some commenters suggested that EHR technology allow for
complete customization of the data. Others commenters recommended not
including historical information or code sets in the clinical summary
(which they claimed were confusing to patients).
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. We also note that we
have not adopted the proposed Consolidated CDA Release 2.0 as discussed
under the ToC certification criterion and the ``implantable device
list'' certification criterion in this section of the preamble (IV.A).
We expect EHR technology developers to follow FAQ 33 for certification
to the 2014 Edition ``clinical summary'' certification criterion and we
continue to encourage, but not require, the use of CVX codes for
immunizations. The data element requirements for certification to the
2014 Edition ``clinical summary'' certification criterion remain the
same as does the ``situational dependency'' guidance we provided in the
Proposed Rule and have recited above. We will, however, take into
consideration the comments we received about the data that should be in
a clinical summary and how it should be expressed for future rulemaking
activity concerning a ``clinical summary'' certification criterion.
Secure Messaging
We proposed a ``secure messaging'' certification criterion for the
Proposed Voluntary Edition that was unchanged as compared to the 2014
Edition certification criterion. We did not request any specific public
comments on this certification criterion.
Comments. The majority of commenters supported adopting this
certification criterion as unchanged. However, a few commenters
recommended that we take steps to allow a patient's authorized
representative to send and receive secure messages on the patient's
behalf as part of the Proposed Voluntary Edition. In addition, one
commenter suggested that this criterion should utilize the same
``decoupling'' of content and transport requirements as

[[Page 54467]]

was proposed for the ToC certification criterion.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``secure messaging'' certification criterion. We
also note that the comment about decoupling is unclear. This
certification criterion does not establish message content requirements
so we are not certain about what the commenter thinks should be
decoupled. Further, any method of transport that meets the security
requirements of the proposed criterion would have been permitted, as it
is currently permitted with the 2014 Edition ``secure messaging''
certification criterion.
Public Health Certification Criteria
We received comments related to the public health certification
criteria, but not specific to the proposed criteria or our proposals.
We summarize and respond to these comments below.
Comments. We received a comment in favor of bidirectional exchange
between EHRs and clinical registries. The commenter encouraged us to
consider certification requirements to promote bidirectional data
exchange and data standardization between EHRs and clinical data
registries, such as certification of clinical data registries. The
commenter stated that this would assist physicians and health care
systems as well as align with payment programs that utilize clinical
data registries (e.g., PQRS). The commenter also suggested that we
consider utilizing existing national standards being used for EHRs.
Response. We appreciate the feedback and will consider the
suggestions on standards and to require certification of clinical data
registries for future rulemaking.
Immunization Information
We proposed an ``immunization information'' certification criterion
for the Proposed Voluntary Edition that was unchanged as compared to
the 2014 Edition certification criterion. We did not request any
specific public comments on this certification criterion.
Comments. The majority of commenters supported an unchanged
criterion. One commenter suggested that we not adopt this criterion, or
similar criteria in future editions, because the ``transmission to
immunization registries'' criteria sufficiently addressed the
interoperability aspects of the immunization information.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``immunization information'' certification
criterion. We appreciate the feedback suggesting that this criterion is
unnecessary as the ``transmission to immunization registries''
certification criterion addresses the functionality required by this
criterion. We will consider this feedback for future rulemaking
concerning an ``immunization information'' certification criterion.
Transmission to Immunization Registries
We proposed a ``transmission to immunization registries''
certification criterion for the Proposed Voluntary Edition that was
revised in comparison to the 2014 Edition certification criterion. We
proposed to include in this criterion the updated IG for immunization
messaging: HL7 Version 2.5.1: Implementation Guide for Immunization
Messaging, Release 1.5. The updated IG 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.
Comments. The majority of commenters supported adoption of the
updated IG for immunization messaging. These commenters stated that the
updated IG provides additional clarification and guidance for better
interoperability between EHRs and immunization registries. Commenters
in opposition to adopting the updated IG were concerned about needing
to support two versions of an IG at the same time. Some commenters were
also concerned about backwards compatibility with the version currently
required in the 2014 Edition. Commenters who were generally opposed to
the proposed voluntary and more incremental rulemaking approach also
contended that the updated IG did not offer much value for the work
that would be required to update systems.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. We appreciate the
feedback commenters provided regarding the updated IG and will consider
the comments received for future rulemaking concerning a ``transmission
to immunization registries'' certification criterion.
Transmission of Reportable Laboratory Tests and Values/Results
We proposed a ``transmission of reportable laboratory tests and
values/results'' certification criterion for the Proposed Voluntary
Edition that was revised in comparison to the 2014 Edition
certification criterion. We proposed to include in this criterion the
updated IG for reporting laboratory tests and values/results to public
health agencies (HL7 Version 2.5.1: HL7 Version 2.5.1 Implementation
Guide: Electronic Laboratory Reporting to Public Health, DSTU, Release
2 (US Realm), 2013). The updated IG addresses technical corrections and
clarifications for interoperability with laboratory orders and other
laboratory domain IGs. To properly codify this proposal in regulation,
we proposed 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).
Comments. We received mixed feedback on the proposal to adopt the
updated IG for reporting laboratory tests and values/results to public
health agencies. Some commenters were in favor of adopting the updated
IG. Other commenters stated that many state public health agencies and
EHR technology developers are still working to implement the version we
adopted in the 2014 Edition, and thus contended it is too early to
require compliance with an updated IG.
A few commenters supported SNOMED-encoded observations values,
where applicable, because of the

[[Page 54468]]

potential value add to reportable laboratory results for public health.
Two commenters stated that we incorrectly referenced the author of the
updated IG in the preamble of the Proposed Rule. These commenters
recommended that we correct the author reference from CDC to the HL7
Public Health and Emergency Response Workgroup. These commenters also
recommended we update the title of the IG to ``HL7 Version 2.5.1
Implementation Guide: Electronic Laboratory Reporting to Public Health,
R2, US Realm--Draft Standard for Trial Use'' in order to encompass all
current and subsequent releases. One commenter recommended we update
the minimum code versions for LOINC[supreg] and SNOMED CT[supreg].
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange.
We agree with the correction of the author of the updated IG and
believe that the CDC worked in conjunction with the HL7 Public Health
Emergency Response Workgroup to develop the updated IG. For future
rulemaking, we will consider the comments received regarding the
maturity and version/naming of the updated IG. Regarding the comments
recommending that we adopt the updated LOINC[supreg] and SNOMED
CT[supreg] standards, we will reassess whether newer versions of the
minimum standards should be adopted in future rulemaking. As we stated
in the 2014 Edition Final Rule, based on our experience, newer versions
of the ``minimum standards'' code sets that we have adopted are issued
more frequently than our current process can reasonably accommodate. We
do not believe that permitting EHR technology to be upgraded and
certified to newer versions of these code sets would normally pose an
interoperability risk, and therefore we allow use of a newer version
voluntarily for certification without adversely affecting the EHR
technology's certified status unless the Secretary specifically
prohibits the use of a newer version (77 FR 54268). Thus, EHRs may be
certified to newer versions of LOINC[supreg] and SNOMED CT[supreg].
Cancer Case Information
We proposed a ``cancer case information'' certification criterion
for the Proposed Voluntary Edition that was unchanged as compared to
the 2014 Edition certification criterion. We did not request any
specific public comments on this certification criterion.
Comments. The majority of commenters supported an unchanged
criterion. One commenter suggested removing this criterion in future
editions because they recommend a focus on privacy and security,
interoperability, and quality reporting, and thus contended that this
criterion is not necessary. Another commenter recommended that we
consider privacy issues so that patients are not inappropriately
penalized by insurance companies or employers for having cancer or a
preexisting condition.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``cancer case information'' certification
criterion. We will consider the feedback regarding the necessity of
this criterion and privacy concerns for future rulemaking concerning a
``cancer case information'' certification criterion.
Transmission to Cancer Registries
We proposed a ``transmission to cancer registries'' certification
criterion for the Proposed Voluntary Edition that was revised in
comparison to the 2014 Edition certification criterion. We proposed to
include in this criterion an updated 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. We also proposed to make a technical
amendment to the regulation text for the 2014 Edition certification
criterion so that it continues to point to the appropriate standard
\44\ in the regulatory text hierarchy at Sec. 170.205(i), while
accommodating our Proposed Voluntary Edition proposal. Specifically, we
proposed 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 Voluntary Edition certification criterion.
---------------------------------------------------------------------------

\44\ 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).
---------------------------------------------------------------------------

Comments. We received mixed feedback on the proposal to adopt the
updated cancer transmission IG. Some commenters supported adopting the
updated IG and also commented that they look forward to more
generalizable CDA-based case reporting in the future. Other commenters
were concerned about the differences in state requirements that lead to
custom interface development before achieving bidirectional exchange.
Some suggested we wait until the next edition to propose adopting the
updated IG because there has not been sufficient time for
implementation experience.
Some commenters stated that, in their experience, the adoption of
the cancer transmission IG required in the 2014 Edition is low, and
therefore they did not foresee that many would adopt an updated
version. One commenter noted that there is a proposed HL7 project to
more closely align the CDA-based cancer reporting IG with the
Consolidated CDA standard. We also received comments stating that we
should consult with existing registries for guidance on the appropriate
standards to adopt. One commenter recommended that the updated IG
should include data elements for transmission of grade and pathological
TNM Stage,\45\ as it is difficult to report to state cancer agencies if
cancer synoptics are not in a structured data format and can be prone
to manual data entry errors.
---------------------------------------------------------------------------

\45\ The TNM Classification of Malignant Tumours (TNM) is a
cancer staging system that describes the extent of a person's
cancer.
---------------------------------------------------------------------------

Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. We agree that we
should evaluate the maturity of the updated IG, its required data
elements, efforts to move to the Consolidated CDA standard, and
standards used by current registries to inform our future rulemaking
concerning a ``transmission to cancer registries'' certification
criterion.

[[Page 54469]]

Automated Numerator Recording
We proposed to adopt an unchanged ``automated numerator recording''
certification criterion as compared to the 2014 Edition certification
criterion. We did not request any specific public comments on this
certification criterion.
Comments. Commenters expressed support for the proposed unchanged
certification criterion. Commenters also expressed concern over the
burden involved in meeting MU measurement requirements (e.g., time
consuming and affects efforts to improving clinical functionality and
usability). One commenter suggested that this criterion either be
removed or be made more granular and defined sufficiently. In terms of
more granularity, the commenter suggested that each numerator recording
requirement for a capability (e.g., CPOE or VDT) should be specified in
the ``automated numerator recording'' certification criterion.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``automated numerator recording'' certification
criterion. We will, however, consider whether additional specificity is
appropriate for the ``automated numerator recording'' certification
criterion and further evaluate the costs and benefits of this
certification requirement for future rulemaking activity concerning an
``automated numerator recording'' certification criterion.
Automated Measure Calculation
We proposed to adopt an unchanged ``automated numerator recording''
certification criterion as compared to the 2014 Edition certification
criterion. We proposed to apply guidance for certification to the 2014
Edition ``automated measure calculation'' certification criterion
included in the 2014 Edition Final Rule to the proposed certification
criterion (79 FR 10911). We also proposed that the interpretation of
the 2014 Edition ``automated measure calculation'' certification
criterion in FAQ 32 \46\ would apply to the proposed certification
criterion. We did not request any specific public comments on this
certification criterion.
---------------------------------------------------------------------------

\46\ https://healthit.gov/policy-researchers-implementers/32-question-11-12-032.
---------------------------------------------------------------------------

Comments. Commenters expressed support for the proposed
certification criterion as unchanged. A couple of commenters stated
this certification criterion helped providers and lessened their MU
reporting burden. EHR technology developers stated that this criterion
represents one of the largest areas of development investment of all of
the MU certification requirements. The commenters noted that it is
common to invest more effort in measuring a particular MU requirement
than developing the associated capability. One commenter suggested that
this criterion be made more granular. The commenter suggested that each
measure requirement for a capability (e.g., CPOE or VDT) should be
specified in the ``automated measure calculation'' certification
criterion. Another commenter recommended making available different
testing methods for this certification criterion, including scenario-
based testing options.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``automated measure calculation'' certification
criterion. We will, however, consider whether additional specificity is
appropriate for ``automated measure calculation'' certification
criteria, further evaluate the development effort associated with this
certification criterion, and consider any potential alternative testing
methods now and in relation to future rulemaking activity concerning an
``automated measure calculation'' certification criterion.
Safety-Enhanced Design
We proposed a ``safety-enhanced design'' (SED) certification
criterion for the Proposed Voluntary Edition that was unchanged as
compared to the 2014 Edition certification criterion. We did, however,
solicit public comment regarding whether we should modify the
certification criterion. Specifically, we requested comment regarding
whether:
The scope of SED should be expanded to include additional
certification criteria;
Formative usability tests should be explicitly required,
or used as substitutes for summative testing;
There are explicit usability tests that should be required
in addition to summative testing; and
There should be a minimum number of test subjects
explicitly required for usability testing.
Comments. We received many comments in response to our request for
comments. Commenters suggested expanding the certification criteria
covered in this criterion to criteria covering laboratory exchange,
problems, and other areas. Conversely, other commenters recommended not
expanding the certification criteria covered by the SED criterion.
Commenters were both for and against using actual formative usability
tests with some suggesting testing to certain usability standards. Some
commenters also suggested that there be a minimum number of test
subjects, with a few commenters emphasizing that the test subjects and
process should be objective.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``safety-enhanced design'' certification
criterion. We will, however, consider all the thoughtful comments we
received regarding expanding the scope and testing of the SED
certification criterion in relation to future rulemaking activity
concerning a SED certification criterion.
We note that we have revised the 2014 Edition SED certification
criterion (Sec. 170.314(g)(3)) to include the three optional CPOE
certification criteria and the optional CIRI certification criterion.
We discuss these revisions in further detail under the discussions of
CPOE and CIRI in section III.A.2 of this preamble.
Quality Management System
We proposed a ``quality management system'' certification criterion
for the Proposed Voluntary Edition that was unchanged as compared to
the 2014 Edition certification criterion. We did

[[Page 54470]]

not request any specific public comments on this certification
criterion.
Comments. Commenters expressed support for the proposed
certification criterion as unchanged. One commenter suggested that we
remove this certification criterion for the proposed edition and any
future editions until the Food and Drug Administration Safety and
Innovation Act (FDASIA) health care IT regulatory framework has been
established and implemented.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As proposed, this
certification criterion would offer no value as an optional 2014
Edition certification criterion because it would be the same as the
current 2014 Edition ``quality management system'' certification
criterion. As with all stakeholder feedback, we appreciate the comments
submitted, including the recommendation to remove this certification
criterion from future editions. We will consider the FDASIA Health IT
Report,\47\ including a published final report, in future rulemaking
activity concerning a ``quality management system'' certification
criterion.
---------------------------------------------------------------------------

\47\ https://www.healthit.gov/sites/default/files/
fdasiahealthitreportfinal.pdf.
---------------------------------------------------------------------------

Non-Percentage-Based Measures Report
We proposed a new ``non-percentage-based measures report''
certification criterion for the Proposed Voluntary Edition.
Specifically, we proposed to adopt a new certification criterion 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 for ``non-percentage-based measure use
report,'' but subsequently did not adopt the criterion in the 2014
Edition Final Rule based on commenters' concerns that additional
specificity would be needed to make the proposed criterion more
effective. In the Proposed Rule, we stated that we continue to believe
that EPs, EHs and CAHs could benefit from EHR technology that could
electronically report non-percentage-based MU objectives and measures,
and we have also received feedback from OIG and comments in response to
a MU Stage 3 Request For Comment \48\ echoing this need.
---------------------------------------------------------------------------

\48\ The Request for Comments is available at: https://
www.healthit.gov/sites/default/files/
hitpcstage3rfcfinal.pdf.
---------------------------------------------------------------------------

Therefore, we proposed a new criterion that is more specific than
the one proposed in the 2014 Edition NPRM and recognizes that certain
aspects of ``use'' associated with non-percentage-based measures will
occur in different ways based on the particular EHR capability
involved. 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 requested 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 this final rule's
preamble to provide more examples of what evidence would be acceptable.
If we were to make the regulatory text more specific, we proposed two
options, but also solicited 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.
We believe the proposed criterion provides EHR technology
developers with substantial flexibility to create innovative approaches
to document evidence of use. 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 illustrate which certification
criteria support one or more non-percentage-based measures, we provided
a table (79 FR 10912) in the Proposed Rule. As described in the
Proposed Rule, we also proposed not to include the proposed ``drug-
formulary checks'' and ToC certification criteria within the scope of
this criterion because the corresponding MU measures already provide
evidence of use. We also proposed that all the proposed privacy and
security certification criteria of the Proposed Voluntary Edition
should not be included within the scope of this certification criterion
because EHR technology would not 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 need to have new certification responsibilities if we
were to adopt this proposed criterion. As a result, we also proposed to
revise Sec. 170.550. This proposed 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 proposed certification criterion.
Comments. We received mixed comments regarding the proposal to
adopt a new certification criterion to generate reports for non-
percentage-based EHR capabilities. Some commenters supported the new
criterion for all of the seven certification criteria we presented in
the table (79 FR 10912).\49\ However, some commenters stated that this
requirement would only be feasible or preferable for a subset of the
proposed certification criteria. One commenter opined that this
functionality was feasible for drug-drug, drug-allergy interaction
checks and CDS, but for the rest of the certification criteria, it
would be difficult to build this functionality on a user-level. Another
commenter recommended adopting this functionality only to support CDS.
One commenter recommended the requirement be that EHRs be able to
perform this function for three out of the six proposed certification
criteria to lessen the administrative burden.
---------------------------------------------------------------------------

\49\ Drug-drug, drug-allergy interaction checks; clinical
decision support; patient list creation; transmission to
immunization registries; transmission of syndromic surveillance data
to public health agencies; transmission of reportable lab tests and
values/results to public health agencies; and transmission to cancer
registries.
---------------------------------------------------------------------------

Commenters that opposed adopting the proposed criterion expressed
that the reason for not adopting this criterion in the 2014 Edition
still holds (i.e.,

[[Page 54471]]

additional specificity is needed to make the proposed criterion more
effective). Many commenters stated that providers can, and currently
do, attest to the non-percentage-based MU objectives without the EHR
having to monitor or ``police'' the provider's interactions with the
EHR. Commenters were also concerned that building this functionality
will be a major development undertaking and will have to be custom-
built for each certification criterion. Commenters provided specific
examples of the challenges in building this functionality for certain
certification criteria. For example:
For CDS interventions, EHR systems vary in their
configurations that determine how often interventions are seen. EHR
developers who currently track this information note that the data
volumes can be very large, and that retention of large volumes of data
over extended periods of time can have performance and hardware
implications.
For the public health certification criteria, it is
possible that an EHR user is connected and submitting appropriate
information but may not have submissions within a particular reporting
period. Multiple transport methods and methodologies can introduce
challenges to implementing this functionality in a standard way. What
is defined as ``ongoing submission'' can vary and human judgment is
required to make the determination (e.g., data is sent using different
procedures like real-time or periodic uploads).

Thus, some commenters were concerned that an auditor could review the
``non-percentage-based measures report'' and incorrectly conclude that
the EP, EH, or CAH failed the CDS objective if none of the implemented
CDS rules/interventions were triggered during the reporting period.
Another commenter recommended changing the regulatory text that as
proposed would require an EHR to ``electronically record evidence that
a user used or interacted with the capability . . .'' The commenter
stated that the use of the word ``evidence'' implies too strong of a
legal ramification and that the EHR can only indicate when different
features or options were triggered or activated within the EHR, but not
that a user did or did not properly act upon the MU-related feature.
A few commenters were opposed to Option 1, which would require EHR
technology to record evidence of use each time a particular capability
was used during the reporting period. One commenter stated that there
are no standards to support reporting of this type of information.
Another commenter suggested that Option 1 would result in large amounts
of data that would require additional storage space. One commenter
supported Option 2 and agreed with the need to show that certain
functionalities were enabled in the system during the reporting period.
Response. There was mixed feedback on which certification criteria
this functionality would be required to support. We agree with comments
stating that this functionality would vary in support of different
certification criteria, and believe that more work is needed to further
refine our proposal. Since the overall scope of this final rule focuses
on the adoption of a small subset of the proposed certification
criteria as optional 2014 Edition EHR certification criteria and
includes revisions to 2014 Edition EHR certification criteria that
provide flexibility, clarity, and enhance health information exchange,
we do not believe it is appropriate to adopt this new certification
criterion at this time. Our experience with the certification of EHR
technology to the 2014 Edition suggests that EHR technology developers
have already implemented or are in the process of implementing their
certified software with providers and hospitals, and it is unlikely
that EHRs would be updated with this new functionality in time to
positively affect reporting for non-percentage-based functions. Thus,
we will consider the comments received on feasibility, implementation,
the regulatory text, and frequency of recording data on use of
particular capabilities for future rulemaking concerning a ``non-
percentage-based measures report'' certification criterion.
Applicability Statement for Secure Health Transport and Delivery
Notification in Direct
We proposed to adopt a new certification criterion for electronic
sending and receiving 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
implementation specification (Implementation Guide for Delivery
Notification in Direct, Version 1.0, June 29, 2012 (Delivery
Notification IG)).\50\
---------------------------------------------------------------------------

\50\ https://wiki.directproject.org/file/view/Implementation+Guide+for+Delivery+Notification+in+Direct+v1.0.pdf.
---------------------------------------------------------------------------

Comments. Some commenters supported the goal of acknowledging
receipt of the documents by the intended recipient. Commenters also
voiced concern that this was a new area of certification that lacked
HIT developer feedback and recommended that we further consider this
certification criterion before finalizing it. Other commenters stated
that the depth of information required to be reported to the sender of
information would cause significant burden on HIT developers to create
the functionality and providers and health care organizations to use
the functionality. One commenter noted that, as the market matured,
demand for this kind of functionality would increase and HIT developers
would design these functions without the need of a certification
criterion.
Response. We have not adopted this certification criterion because
we have not adopted the Proposed Voluntary Edition. Rather, we have
only adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. We will, however,
consider comments regarding the Delivery Notification IG capabilities,
the concerns expressed by commenters, and evaluate whether the market
demand for this capability would moot the benefit that certification
could provide for proof of a consistent implementation according to the
IG as part of future rulemaking.

B. 2014 Edition and Proposed Voluntary Edition Equivalency Table

In the Proposed Rule, we provided an ``equivalency table'' (79 FR
10915-16) that identified the Proposed Voluntary Edition EHR
certification criteria that were equivalent to the 2014 Edition
certification criteria for the purposes of meeting the CEHRT
definition. There is no longer a need for an ``equivalency table''
because we have not adopted the Proposed Voluntary Edition in this
final rule. Therefore, we have not included an ``equivalency table'' in
this final rule.

C. HIT Definitions

1. CEHRT
We proposed to revise the CEHRT definition for FY/CY 2014 and
subsequent years to include reference to the Proposed Voluntary Edition
as a means of giving EPs, EHs, and CAHs the flexibility to use EHR
technology that has been certified to either the 2014 Edition or the
Proposed Voluntary

[[Page 54472]]

Edition, or a combination of both editions, to meet the CEHRT
definition for FY/CY 2014 and subsequent years.
Comments. We received many comments recommending that we do not
adopt the Proposed Voluntary Edition.
Response. We have not revised the CEHRT definition. In response to
comments recommending that we not adopt the Proposed Voluntary Edition
and for the other reasons discussed earlier in this preamble, we have
not adopted the full Proposed Voluntary Edition. Rather, we have only
adopted a small subset of the proposed certification criteria as
optional 2014 Edition EHR certification criteria and made revisions to
2014 Edition EHR certification criteria that provide flexibility,
clarity, and enhance health information exchange. As such, no revisions
are necessary to the CEHRT definition to account for the additional
optional 2014 Edition EHR certification criteria.
2. Common MU Data Set
We proposed to revise the Common MU Data Set definition in Sec.
170.102 by including the preferred language standard in the proposed
``demographics'' certification criterion solely for the purposes of
certifying EHR technology to the Proposed Voluntary Edition EHR
certification criteria that referenced the Common MU Data Set.
Comments. We received comments recommending that we not adopt a new
preferred language standard as well as comments on each of the
standards we proposed as the potential new preferred language standard.
Response. We have not adopted a revised or new demographics
certification criterion or a new preferred language standard consistent
with our reasons for not adopting the Proposed Voluntary Edition and
for the reasons discussed in more detail under the ``demographics''
certification criterion in section IV.A. Accordingly, we have not
finalized our proposal to revise the Common MU Data Set definition.

C. ONC HIT Certification Program

1. Non-MU EHR Technology Certification
We proposed to establish an ``MU EHR Module'' definition and a
``non-MU EHR Module'' definition under the main ``EHR Module''
definition at Sec. 170.102. We proposed to define an ``MU EHR Module''
as any service, component, or combination thereof that is designed for
purposes of the Medicare and Medicaid EHR Incentive Programs and can
meet the requirements of at least one certification criterion adopted
by the Secretary. We proposed to define a ``non-MU EHR Module'' as any
service, component, or combination thereof that is designed for any
purpose other than the Medicare and Medicaid EHR Incentive Programs and
can meet the requirements of at least one certification criterion
adopted by the Secretary. Correspondingly, we proposed to revise Sec.
170.550 to require the certification of only MU EHR Modules, as
applicable, to the Proposed Voluntary Edition ``automated numerator
recording'' certification criterion, the ``automated measure
calculation'' certification criterion, and the ``non-percentage-based
measure use report'' certification criterion.
We stated that these proposals 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, while permitting EHR technology that is designed for non-MU
purposes (e.g., broad electronic health information exchange or
behavioral health settings staffed mainly by MU ineligibles) to be
certified without having to include capabilities that support
percentage-based and/or non-percentage-based MU measures. These
proposals were based on our belief that EHR technology developers who
design EHR technology for non-MU purposes and settings find that the MU
measurement certification criteria requirements are unnecessary burdens
and resource investments (i.e., to have to program MU-specific rules
into their software just to get certified). Similarly, we noted that
because of the specific ways in which MU measures are structured non-MU
health care providers would find little benefit in receiving EHR
utilization reports showing MU performance. In the Proposed Rule, we
specifically requested comment on these assumptions and on how best to
implement our proposed approach if we were to adopt it in this final
rule (e.g., requested comments on what processes we should use for
testing and certification and distinguishing MU and non-MU EHR Modules
on the CHPL) (79 FR 10919-20).
Overall, as stated in the Proposed Rule, we saw these proposals as
a first step towards the expansion of the ONC HIT Certification Program
to accommodate other types of HIT (79 FR 10930). To note, as stated in
the Proposed Rule, we did not propose 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.
Comments. We received comments supporting our proposal not to
require ``non-MU'' technologies to be certified to certification
criteria designed to support MU measurement. We also received a
significant number of comments expressing concern that our proposals
would cause confusion. Commenters suggested that designations and
concepts such as ``MU,'' ``non-MU,'' and ``beyond MU purposes'' would
add complexity and confusion to an already strained marketplace. A few
commenters stated that we need to also account for non-EHR
technologies. Another commenter suggested that we not rely on
assumptions about the differences in technology needs between providers
that are eligible for MU incentive payments and those that are
ineligible. As an example, the commenter suggested that the numerator
and denominator calculations may, in fact, be useful to providers that
are not eligible for MU incentive payments for patient safety tracking
and other purposes.
Response. In consideration of comments and our overall goal to
expand the ONC HIT Certification Program to accommodate other types of
HIT, we have decided not to adopt any of these proposals. Upon further
reflection, we believe these proposals may not clearly and
appropriately move us away from a certification program currently
focused on MU. By using terminology such as ``MU'' and ``non-MU,'' we
only reinforce the MU-aspect of the ONC HIT Certification Program.
Further, as noted by commenters, our proposals could confuse providers
and may not be based on sound assumptions such as MU-ineligible
providers not finding value in some of the capabilities that support MU
measurement as noted by a commenter. Accordingly, with consideration of
comments that supported our stated goal and recommended that we address
non-EHR technologies, we will further consider how best to restructure
the ONC HIT Certification Program to move it beyond MU in preparation
for our next rulemaking. To reaffirm, as our request for comment
indicated in the Proposed Rule (79 FR 10929-30), we intend to propose
changes to the ONC HIT

[[Page 54473]]

Certification Program that will permit the certification of other types
of HIT and the certification of HIT for other specific types of health
care settings (i.e., beyond the general ambulatory and general
inpatient settings). For now, we direct stakeholders to our guidance
for EHR technology developers serving providers ineligible for the EHR
Incentive Programs titled ``Certification Guidance for EHR Technology
Developers Serving Health Care Providers Ineligible for Medicare and
Medicaid EHR Incentive Payments.''\51\
---------------------------------------------------------------------------

\51\ https://www.healthit.gov/sites/default/files/
generalcertexchangeguidancefinal9-9-13.pdf.
---------------------------------------------------------------------------

2. ``Certification Packages'' for EHR Modules
We proposed to establish the concept of predefined ``certification
packages'' that would reflect groupings of certification criteria. We
stated that our proposal was intended to improve the ease with which
our regulatory concepts could be communicated to the general public and
to EHR Module purchasers. More specifically, we stated that this
concept would make it easier for stakeholders to communicate and
understand the functionality an EHR Module includes and the
certification criteria to which it is certified.
We proposed 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 that represent a specific grouping of
capabilities. For EHR Modules certified to the Proposed Voluntary
Edition, we proposed definitions in Sec. 170.502 for ``2015 Edition
Care Coordination Package'' and ``2015 Edition Patient Engagement
Package'' that each identified the set of specific certification
criteria to which an EHR Module would need 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. We further
sought comment on what certification criteria should be included in the
care coordination and patient engagement packages.
We also clarified that if an EHR Module were certified to the
certification criteria included in a proposed 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. However, to ensure that certification packages would be
represented accurately to potential purchasers and users of EHR
Modules, we proposed 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. We further
clarified 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 satisfied the certification
criteria included in each of the proposed certification packages and
was also certified to other certification criteria, it could be so
indicated by the EHR Module developer to its customers.
Comments. We received only three comments that supported our
proposals. However, the commenters submitting these comments
misconstrued our proposals as either a new required type of
certification for EHR Modules to the Proposed Voluntary Edition or as
an additional requirement beyond initial certification, such as
specifically requiring additional functionality for ``care
coordination.'' All other commenters did not support our proposals.
These commenters disagreed with our rationale that our approach would
provide clarity for stakeholders. Rather, commenters stated that our
approach would cause more confusion than it would solve. Commenters
noted that one individual's definition of ``care coordination'' may not
be the same as another, which could lead to misunderstandings about
what is or is not included in the EHR technology. Commenters also noted
that there are a large number of possible combinations of certification
criteria and associated capabilities that could plausibly be called
``care coordination'' (e.g., inclusion of lab exchange certification
criteria and capabilities) and patient engagement (e.g., inclusion of
the ``clinical summary'' certification criterion). The commenters
opined that the certification criteria included in the proposed
packages seemed arbitrary and not applicable to all providers.
Commenters suggested that we focus on educating providers, particularly
those ineligible for the EHR Incentive Programs, as to what types of
certified capabilities providers should look for in a certified
technology. In this regard, one commenter suggested that we rely on and
educate more providers on our guidance titled ``Certification Guidance
for EHR Technology Developers Serving Health Care Providers Ineligible
for Medicare and Medicaid EHR Incentive Payments.'' \52\ A few
commenters also mentioned that certified technologies should be
properly labeled as to the certification criteria and associated
capabilities they include.
---------------------------------------------------------------------------

\52\ https://www.healthit.gov/sites/default/files/
generalcertexchangeguidancefinal9-9-13.pdf.
---------------------------------------------------------------------------

Response. We have not finalized our proposals for the ``care
coordination'' and ``patient engagement'' packages.
We clarify that our ``certification packages'' proposals did not
require a new type of certification or additional functionality for EHR
Modules. Under the proposals, an EHR Module would not have been
required to be certified to the certification criteria specified in a
certification package, and an EHR Module could have been certified to
more certification criteria than were included in a certification
package. Our proposal was designed such that an EHR Module developer
could assert (e.g., for communications and marketing purposes) that its
EHR Module met a certification package if the EHR Module had been
certified to all of the certification criteria included in a
certification package without any additional determination made by an
ONC-ACB. However, given the comments received from commenters that
clearly understood our proposals, we have not adopted ``certification
package'' as a concept and definition in Sec. 170.502 nor have we
finalized a requirement under Sec. 170.523(k)(1) that an ONC-ACB
ensure that an EHR Module developer accurately represents the
certification packages its EHR Module meets. We agree with commenters
that our proposed ``certification packages'' could have ended up
creating more confusion than they solved, and that there are no
definitive certification criteria that meet the concept of ``care
coordination'' and ``patient engagement'' for all providers. As
recommended by commenters, we will try to further educate providers on
the capabilities included in certification criteria, the means for
determining what capabilities a certified EHR Module includes (e.g.,
utilizing the CHPL and reviewing an EHR technology developer's
communications and marketing materials, which should include a list of
the certification criteria and CQMs that the EHR Module was certified
to), and on the ``Certification Guidance for EHR Technology Developers
Serving Health Care Providers Ineligible for Medicare and

[[Page 54474]]

Medicaid EHR Incentive Payments'' guidance we issued in 2013.

V. Comments Beyond the Scope of This Final Rule

In response to the Proposed Rule, some commenters chose to raise
issues that are beyond the scope of our proposals such as encouraging
us to amend our certification criteria to include EHR accessibility for
users with disabilities. We do not summarize or respond to those
comments in this final rule. However, we will review the comments and
consider whether other actions may be necessary, such as addressing the
comments in future rulemakings.

VI. Collection of Information Requirements

This final rule contains no new collections of information under
the Paperwork Reduction Act nor does it revise any current collection
of information approved by OMB.

VII. Regulatory Impact Statement

A. Statement of Need

Consistent with EO 13563, we have completed a retrospective review
of our 2014 Edition Final Rule and the certification criteria we
adopted in that final rule. Further, consistent with EO 13563, we have
only adopted the proposed certification criteria as part of the 2014
Edition that provide regulatory flexibility and reduce regulatory
burden for stakeholders.

B. Overall Impact

We have examined the impact of this final rule as required by EO
12866 on Regulatory Planning and Review (September 30, 1993), EO 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 EO 13132 on
Federalism (August 4, 1999).
1. Executive Orders 12866 and 13563--Regulatory Planning and Review
Analysis
EOs 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 final rule is not an economically significant
rule. Related costs to prepare EHR technology and other HIT to be
tested and certified are estimated to be far less than $100 million per
year. Nevertheless, because of the public interest in this final rule,
we have prepared an RIA that to the best of our ability presents the
costs and benefits of this final rule.
a. Costs
This final rule adopts new optional certification criteria and
revised certification criteria as part of the 2014 Edition. Our
analysis focuses on the direct effects of the provisions of this final
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 to certify to
the new optional certification criteria and revised certification
criteria and for developing new EHR technology to meet the new optional
certification criteria and revised certification criteria. The costs
for testing and certification of EHR technologies to the certification
criteria adopted in this final rule were captured in the RIA of the
Permanent Certification Program final rule as we discuss in more detail
below (VI.B.1.a.ii ``Testing and Certification Costs for the 2014
Edition Release 2''). The costs that EPs, EHs, and CAHs will incur in
adopting and implementing EHR technology certified to the certification
criteria adopted in this final rule are not within the scope of this
final rule.
i. Development and Preparation Costs for the 2014 Edition Release 2
In the Proposed Rule (79 FR 10932-36), we estimated the development
and preparation costs for the Proposed Voluntary Edition. We
categorized proposed certification criteria based on their gap
certification status (i.e., new, revised, and unchanged). We used the
total number of unique \53\ 2011 Edition Complete EHRs and EHR Modules
that were used for MU Stage 1 attestation as reported at the end of FY
2013.\54\ Using the unique number of 2011 Edition EHR technologies used
for MU Stage 1 attestation we established a range of between 20% and
40% of unique EHR technologies used for MU Stage 1 that we believed
would be developed and prepared to meet each of the certification
criteria of the Proposed Voluntary Edition. This range accounted for
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. The range also took into account any
potential non-MU-focused EHR technologies that will be developed and
prepared to meet the Proposed Voluntary Edition, but not designed for
MU purposes. We identified three levels of effort to associate with the
development and preparation of EHR technology to meet the requirements
of the Proposed Voluntary Edition.\55\ We based the effort levels on
the hours necessary for a software developer to develop and prepare the
EHR technology for testing and certification and calculated the average
software developer's wage with benefits at $61 per hour.\56\ We
calculated a low cost estimate, high cost estimate, and average cost
estimate for each proposed certification criterion and then estimated
the totals equally split between 2014 and 2015.\57\
---------------------------------------------------------------------------

\53\ 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.
\54\ For the Proposed Voluntary Edition certification criteria
that did 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.
\55\ 79 FR 10932-33.
\56\ 79 FR 10933.
\57\ 79 FR 10933-36.
---------------------------------------------------------------------------

Comments. We received very limited comments on our proposed impact
analysis, all of which came from EHR technology developers and
reiterated the detailed comment that came from the Electronic Health
Record Association (EHRA). In its comments, the EHRA presented average
hourly burden estimates that would be incurred by an EHR technology
developer per proposed certification criterion. The EHRA indicated that
its estimates presumed a product was already certified to 2014 Edition
certification criteria and included ``research, planning and design,
development, testing, usability testing, documentation, release, and
certification effort.'' Additionally, a follow-up request for
clarification and fact finding indicated that these hourly estimates
included an average of 2.5 products per EHR technology developer that
would be certified to the certification criteria of the Proposed
Voluntary Edition. Overall, the EHRA

[[Page 54475]]

generally concluded that we had, in most cases, significantly
underestimated the hourly burden associated with the proposed
certification criteria and provided a detailed chart identifying the
potential discrepancies.
Response. We appreciate the detailed response provided by the EHR
technology developer community. In reviewing the provided comments, it
became clear that the way in which we were presenting the calculation
of our impacts in the preamble and the way in which EHR technology
developers think about the impacts were different. In other words, our
approach in the Proposed Rule was to assign burden hours to each
certified product listed on the CHPL by certification criterion and we
never provided a ``per EHR technology developer'' estimate. However, in
contrast, the EHRA estimates were burden hours by EHR technology
developer for each certification criterion.
On face value, for example, if one were to compare the ``Level 2
range'' we included in the Proposed Rule of 100-300 hours without
multiplying by the number of products on the CHPL attributable to a
particular EHR technology developer it would appear that we did
significantly underestimate the burden. However, if one were to
multiply that 100-300 hour range by the number of products attributable
to a particular EHR technology developer and that were certified to the
certification criterion in question a potentially narrower gap in the
estimates could result.
After considering these comments, we believe that a more direct way
for this final rule and for future rulemakings to identify burden will
be to identify hourly burden estimates for each certification criterion
by EHR technology developer. Given the reduced scope of this final
rule, we do not include hourly cost estimates for certification
criteria that we are not finalizing. Table 4 indicates only the
regulatory changes we have finalized for the adopted certification
criteria and our hourly burden estimate range for each of the changes
by EHR technology developer.
We also include an estimated number of EHR technology developers
that we believe will seek certification to these certification criteria
(and built into this assumption is that they would be presenting on
average 3 products for certification, similar to EHRA's number). To
arrive at this estimate, we analyzed available CHPL data from mid-May
of this year for 2014 Edition certifications. From this data, we
determined how many EHR technology developers had at least one product
certified to the adopted 2014 Edition. From the group of EHR technology
developers with a product certified to the 2014 Edition, we estimate
that no more than 20% of those developers will seek certification
because of the reduced and specific scope of this final rule. We also
believe that for some certification criteria the 20% estimate could be
a substantial overestimation. We provide a more detailed criterion-by-
criterion explanation of our estimates below in Table 4.
Additionally, despite the specificity included in the EHRA
estimates, we have found from past experience that at times EHR
technology developers have misinterpreted what we have proposed. The
EHRA's comments noted this kind of discrepancy by stating for certain
certification criteria that some of its members interpreted the burden
to be reasonably low while others very high. Given that we have no
other comments by which to compare the EHRA estimates, we have
generally used the EHRA estimate as our ``high average'' rounded up or
down to the nearest hundred hours.

Table 4--Development and Preparation Costs for EHR Technology Developers for Adopted Certification Criteria
----------------------------------------------------------------------------------------------------------------
Number of EHR Hourly development effort by
developers who EHR developer
Certification develop -------------------------------
Item CFR Text criterion name product(s) for
certification Low avg High avg
to criterion
----------------------------------------------------------------------------------------------------------------
1.................... Sec. CPOE--medications.. 33 0 100
170.314(a)(18).
2.................... Sec. CPOE--laboratory... 33 0 100
170.314(a)(19).
3.................... Sec. CPOE--diagnostic 33 0 100
170.314(a)(20). imaging.
4.................... Sec. 170.314(b)(8) Transitions of care 29 400 600
5.................... Sec. 170.314(b)(9) Clinical 27 0 100
information
reconciliation and
incorporation.
6.................... Sec. 170.314(e)(1) View, download, and 33 400 600
transmit to 3rd
party.
7.................... Sec. 170.314(f)(7) Transmission to 25 0 100
public health
agencies--syndromi
c surveillance.
8.................... Sec. 170.314(g)(1) Automated numerator N/A N/A N/A
recording.
9.................... Sec. 170.314(g)(3) Safety-enhanced 77 0 100
design.
10................... Sec. 170.314(h)(1) Applicability 33 300 500
Statement for
Secure Health
Transport.
11................... Sec. 170.314(h)(2) Applicability 33 200 300
Statement for
Secure Health
Transport & XDR/
XDM for Direct
Messaging.
12................... Sec. 170.314(h)(3) SOAP Transport and 33 200 300
Security
Specification &
XDR/XDM for Direct
Messaging.
----------------------------------------------------------------------------------------------------------------

Items #1 through #3: With the exception of splitting out
the three CPOE order type functionalities, there are no new
requirements as part of any of these three certification criteria in
this final rule. As a result, we provided a low range estimate.
Item #4: For this certification criterion, the only
substantial new development change between it and the 2014 Edition
certification criteria at Sec. 170.314(b)(1) and (2) is the addition
of the Direct Edge Protocols IG. The EHRA estimates did not clearly
identify whether the hourly range of 1,380 hours was to implement all
four edge protocols or some number of them. Regardless, given that we
only require one for certification, we have more than halved the EHRA
estimate to fall into a range that we believe would be more reflective
of the burden imposed by the final certification criterion.
Item #5: The EHRA did not provide any hourly estimate for
new development, nor does this criterion substantively differ from
already

[[Page 54476]]

required capabilities in the 2014 Edition. As a result, we provided a
low estimate.
Item #6: For this certification criterion, the only
substantial new development change between it and the original 2014
Edition version is the addition of the IG for Direct Edge Protocols. As
a result, our estimates are the same as for Item 4.
Item #7: Given the adoption of this more general
certification criterion, we have provided a low estimate.
Item # 8: This certification criterion was simply changed
to an ``optional'' designation to provide regulatory clarity for
Complete EHR certification to the 2014 Edition. There should be no new
cost estimates related to certification as this regulatory change
simply implements ONC Regulation FAQ 28 as discussed in section III.B.3
of the preamble.
Item # 9: This certification criterion now includes the
adopted optional CPOE and CIRI certification criteria. We have
estimated a low cost range because we anticipate that EHR technology
developers will use the same SED practices they used for certification
to the CPOE (Sec. 170.314(a)(1)) and CIR (Sec. 170.314(b)(4))
certification criteria. Additionally, we note that we do not believe
that there will be 99 different EHR technology developers that will get
certified to the three CPOE criteria (i.e., 33 + 33 + 33). We expect
that there will be overlap (i.e., multiple EHR technology developers
getting certified to more than one CPOE certification criterion) and
that some EHR technology developers will only get certified to one CPOE
certification criterion such as CPOE--medications or CPOE--laboratory.
Therefore, we estimate that there will be no more than 50 EHR
technology developers that are certified to the SED certification
criterion based on certification to the new optional CPOE certification
criteria. We have combined this estimated number with the number of EHR
technology developers we have estimated for the CIRI certification
criterion to get an estimated total for this certification criterion.
Items #10-12: We provide estimates reasonably close to the
EHRA estimates.
Table 5 includes an overall 2-year cost estimate for each
criterion. We retain the 2-year cost estimate period (CY 2014 and CY
2015) for the reason provided in the Proposed Rule as they would
similarly apply to the adopted optional and revised 2014 Edition
certification criteria. Additionally, we retain and use the estimate of
$61 per hour (with benefits) as the average software developer's wage.

Table 5--Distributed Total Development and Preparation Costs for EHR Technology Developers (Two-Year Period)--
Totals Rounded
----------------------------------------------------------------------------------------------------------------
Total high Total average
Item CFR Text Certification Total low cost cost estimate cost estimate
criterion name estimate ($M) ($M) ($M)
----------------------------------------------------------------------------------------------------------------
1............................ Sec. CPOE--medicatio $0 $.2 $.1
170.314(a)(18). ns.
2............................ Sec. CPOE--laborator 0 .2 .1
170.314(a)(19). y.
3............................ Sec. CPOE--diagnosti 0 .2 .1
170.314(a)(20). c imaging.
4............................ Sec. Transitions of .71 1.0 .89
170.314(b)(8). care.
5............................ Sec. Clinical 0 .16 .081
170.314(b)(9). information
reconciliation
and
incorporation.
6............................ Sec. View, download, .81 1.22 1.0
170.314(e)(1). and transmit
to 3rd party.
7............................ Sec. Transmission to 0 .15 .077
170.314(f)(7). public health
agencies--synd
romic
surveillance.
8............................ Sec. Automated N/A N/A N/A
170.314(g)(1). numerator
recording.
9............................ Sec. Safety-enhanced 0 .47 .235
170.314(g)(3). design.
10........................... Sec. Applicability .6 1.0 .8
170.314(h)(1). Statement for
Secure Health
Transport.
11........................... Sec. Applicability .4 .6 .5
170.314(h)(2). Statement for
Secure Health
Transport &
XDR/XDM for
Direct
Messaging.
12........................... Sec. SOAP Transport .4 .6 .5
170.314(h)(3). and Security
Specification
& XDR/XDM for
Direct
Messaging.
2-Year Total............. ................ ............... 2.92 5.80 4.38
2014 total (50%)......... ................ ............... 1.46 2.90 2.19
2015 total (50%)......... ................ ............... 1.46 2.90 2.19
----------------------------------------------------------------------------------------------------------------

iii. Testing and Certification Costs for the 2014 Edition Release 2
In the RIA 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.\58\ 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
Edition and the certification criteria we have adopted as part of the
2014 Edition Release 2. This assessment is based on the number of EHR
technologies currently certified to the 2014 Edition and our
projections for the number of EHR technology developers that would
likely have their EHR technologies tested and certified to the optional
and revised 2014 Edition certification criteria adopted in this final
rule. 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.
---------------------------------------------------------------------------

\58\ 76 FR 1318.
---------------------------------------------------------------------------

b. Benefits
The regulatory flexibility the 2014 Edition Release 2 certification
criteria provide will offer several significant benefits to patients,
health care providers, and HIT developers. The 2014 Edition Release 2
incorporates stakeholder feedback on particular 2014 Edition issues
identified as unnecessarily impeding innovation and causing undue
burden. The 2014 Edition Release 2 also seeks to continue to improve
EHR technology's interoperability and electronic health

[[Page 54477]]

information exchange. Specifically, the separating out of the
``content'' and ``transport'' capabilities in the optional 2014 Edition
ToC certification criterion (compared to the 2014 Edition ToC
certification criteria adopted at Sec. 170.314(b)(1) and (2)) and
adoption of the Edge Protocol IG is aimed at improving the market
availability of electronic health information exchange services. The
new certification flexibilities offered by the optional ``CPOE'' and
optional ``syndromic surveillance'' certification criteria are designed
to enhance innovation and offer providers enhanced functionality and
options for meeting applicable MU measures. The new flexibility in the
VDT certification criterion is designed to further facilitate the
exchange of patient health information between provider and patient.
The optional CIRI criterion is designed to align better with clinical
workflows and reduce regulatory burden found in certification to the
current ToC certification criterion at Sec. 170.314(b)(1).
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 final 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 \59\ which ``indicates the maximum allowed for a concern and
its affiliates to be considered small entities.''
---------------------------------------------------------------------------

\59\ 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/SizeStandardsTable.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
optional 2014 Edition Release 2 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.
We estimate that this final 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 final rule. We note that this final rule does not
impose the costs cited in the RIA as compliance costs, but rather as
investments which these EHR technology developers voluntarily take on
and expect to recover with an appropriate rate of return. Accordingly,
we do not find that this final rule will create a significant impact on
a substantial number of small entities. Additionally, the Secretary
certifies that this final 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 final 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
certification criteria or other proposals we have adopted in this final
rule.
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 final
rule will not impose an unfunded mandate on state, local, and tribal
governments or on the private sector that will reach the threshold
level.

Regulation Text

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 recordkeeping requirements, Public
health, Security.

For the reasons set forth in the preamble, 45 CFR subtitle A,
subchapter D, part 170, is 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. Section 170.102 is amended by revising the definition for ``Base
EHR'' to read as follows:

Sec. 170.102 Definitions.

* * * * *
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;

[[Page 54478]]

(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:
(i) For at least one of the four criteria adopted at Sec.
170.314(a)(1), (a)(18), (a)(19), or (a)(20);
(ii) At Sec. 170.314(a)(3);
(iii) At Sec. 170.314(a)(5) through Sec. 170.314(a)(8);
(iv) Both Sec. 170.314(b)(1) and (2); or, both Sec. 170.314(b)(8)
and Sec. 170.314(h)(1); or Sec. 170.314(b)(1) and (2) combined with
either Sec. 170.314(b)(8) or Sec. 170.314(h)(1), or both Sec.
170.314(b)(8) and Sec. 170.314(h)(1);
(v) At Sec. 170.314(b)(7);
(vi) At Sec. 170.314(c)(1) through Sec. 170.314(c)(3);
(vii) At Sec. 170.314(d)(1) through Sec. 170.314(d)(8);
(4) Has been certified to the certification criteria at Sec.
170.314(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.
* * * * *

Sec. 170.102 [Amended]

0
3. Section 170.102 is further amended, effective March 1, 2015, by
removing the definitions of ``2011 Edition EHR certification criteria''
and ``Complete EHR, 2011 Edition.''

0
4. Section 170.202 is amended by adding paragraph (d) to read as
follows:

Sec. 170.202 Transport standards.

* * * * *
(d) Standard. ONC Implementation Guide for Direct Edge Protocols
(incorporated by reference in Sec. 170.299).

Sec. 170.205 [Amended]

0
5. Section 170.205 is amended, effective March 1, 2015, by removing and
reserving paragraphs (b)(1), (c), (d)(1), (e)(1) and (2), and (f).

Sec. 170.207 [Amended]

0
6. Section 170.207 is amended, effective March 1, 2015, by removing and
reserving paragraphs (a)(1) and (2), (b)(1), (c)(1), (d)(1), and
(e)(1).

Sec. 170.210 [Amended]

0
7. Section 170.210 is amended, effective March 1, 2015, by removing and
reserving paragraphs (a)(2) and (b).

0
8. Section 170.299 is amended by adding paragraph (k)(4) to read as
follows:

Sec. 170.299 Incorporation by reference.

* * * * *
(k) * * *
(4) ONC Implementation Guide for Direct Edge Protocols, Version
1.1, June 25, 2014, IBR approved for Sec. 170.202; available at http:/
/www.healthit.gov/sites/default/files/
implementationguidefordirectedgeprotocolsv11.pdf.
* * * * *

Sec. 170.302 [Removed and Reserved]

0
9. Section 170.302 is removed and reserved, effective March 1, 2015.

Sec. 170.304 [Removed and Reserved]

0
10. Section 170.304 is removed and reserved, effective March 1, 2015.

Sec. 170.306 [Removed and Reserved]

0
11. Section 170.306 is removed and reserved, effective March 1, 2015.

0
12. Section 170.314 is amended by:
0
a. Revising paragraph (a)(1)(iii);
0
b. Adding paragraphs (a)(18) through (20) and (b)(8) and (9);
0
c. Revising paragraphs (e)(1)(i)(C)(1) and (2);
0
d. Adding paragraph (f)(7);
0
e. Revising paragraphs (g)(1) and (3); and
0
f. Adding paragraph (h).
The revisions and additions read as follows:

Sec. 170.314 2014 Edition electronic health record certification
criteria.

* * * * *
(a) * * *
(1) * * *
(iii) Diagnostic imaging.
* * * * *
(18) Optional--computerized provider order entry--medications.
Enable a user to electronically record, change, and access medication
orders.
(19) Optional--computerized provider order entry--laboratory.
Enable a user to electronically record, change, and access laboratory
orders.
(20) Optional--computerized provider order entry--diagnostic
imaging. Enable a user to electronically record, change, and access
diagnostic imaging orders.
(b) * * *
(8) Optional--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(d) 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(d) from a
service that has implemented the standard specified in Sec.
170.202(a).
(ii)(A) Display. 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 (3).
(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).
(iii) Create. Enable a user to electronically create a transition
of care/referral summary formatted according to the standard adopted at
Sec. 170.205(a)(3) that includes, at a minimum, the Common MU Data Set
and the following data expressed, where applicable, according to the
specified standard(s):
(A) 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);
(B) Immunizations. The standard specified in Sec. 170.207(e)(2);
(C) Cognitive status;
(D) Functional status;
(E) Ambulatory setting only. The reason for referral; and referring
or transitioning provider's name and office contact information; and
(F) Inpatient setting only. Discharge instructions.
(9) Optional--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)(3), 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.

[[Page 54479]]

(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).
* * * * *
(e) * * *
(1) * * *
(i) * * *
(C) * * *
(1) Electronically transmit 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 at least one of the following:
(i) The standard specified in Sec. 170.202(a).
(ii) Through a method that conforms to the standard specified at
Sec. 170.202(d) and that leads to such summary being processed by a
service that has implemented the standard specified in Sec.
170.202(a).
(2) 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 at least one of the following:
(i) The standard specified in Sec. 170.202(a).
(ii) Through a method that conforms to the standard specified at
Sec. 170.202(d) and that leads to such summary being processed by a
service that has implemented the standard specified in Sec.
170.202(a).
* * * * *
(f) * * *
(7) Optional--Ambulatory setting only--Transmission to public
health agencies--syndromic surveillance. EHR technology must be able to
electronically create syndrome-based public health surveillance
information for electronic transmission.
(i) Optional. That contains the following data:
(A) Patient demographics;
(B) Provider specialty;
(C) Provider address;
(D) Problem list;
(E) Vital signs;
(F) Laboratory test values/results;
(G) Procedures;
(H) Medication list; and
(I) Insurance.
(ii) [Reserved]
(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.
* * * * *
(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.314(a)(1), (2), (6)
through (8), (16) and (18) through (20) and (b)(3), (4), and (9).
* * * * *
(h) Transport methods--(1) Optional--Applicability Statement for
Secure Health Transport. Enable health information to be electronically
sent and electronically received in accordance with the standard
specified in Sec. 170.202(a).
(2) Optional--Applicability Statement for Secure Health Transport
and XDR/XDM for Direct Messaging. Enable health information to be
electronically sent and electronically received in accordance with the
standards specified in Sec. 170.202(a) and (b).
(3) Optional--SOAP Transport and Security Specification and XDR/XDM
for Direct Messaging. Enable health information to be electronically
sent and electronically received in accordance with the standards
specified in Sec. 170.202(b) and (c).

Subpart D--[Removed and Reserved]

0
13. Remove and reserve subpart D, consisting of Sec. Sec. 170.400
through 170.499.

0
14. Section 170.501 is amended by designating the existing text as
paragraph (a) and by adding paragraph (b) to read as follows:

Sec. 170.501 Applicability.

* * * * *
(b) References to the term Complete EHR and Complete EHR
certification throughout this subpart do not apply to certification in
accordance with any edition of certification criteria that is adopted
by the Secretary under subpart C after the 2014 Edition EHR
certification criteria.

0
15. Section 170.503 is amended by revising paragraphs (b)(1) and (e)(1)
and (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 (incorporated by reference in Sec. 170.599).
* * * * *
(e) * * *
(1) Maintain conformance with ISO/IEC 17011 (incorporated by
reference in Sec. 170.599);
(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
(incorporated by reference in Sec. 170.599).
* * * * *

0
16. Section 170.523 is amended by adding paragraph (l) to read as
follows:

Sec. 170.523 Principles of proper conduct for ONC-ACBs.

* * * * *
(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

[[Page 54480]]

and Terms of Use for the ONC Certified HIT Certification and Design
Mark.

0
17. Section 170.550 is amended by revising paragraph (f)(1) to read as
follows:

Sec. 170.550 EHR Module certification.

* * * * *
(f) * * *
(1) Section 170.314(g)(1) or (2) if the EHR Module has capabilities
presented for certification that would support a meaningful use
objective with a percentage-based measure;
* * * * *

Sec. 170.550 [Amended]

0
18. Section 170.550 is further amended, effective March 1, 2015, by
removing and reserving paragraph (e).

0
19. Section 170.599 is amended by revising paragraphs (b)(1) and (2)
and adding paragraph (b)(3) to read as follows:

Sec. 170.599 Incorporation by reference.

* * * * *
(b) * * *
(1) ISO/IEC 17011:2004 Conformity Assessment--General Requirements
for Accreditation Bodies Accrediting Conformity Assessment Bodies
(Corrected Version), February 15, 2005, ``ISO/IEC 17011,'' IBR approved
for Sec. 170.503.
(2) ISO/IEC GUIDE 65:1996--General Requirements for Bodies
Operating Product Certification Systems (First Edition), 1996, ``ISO/
IEC Guide 65,'' IBR approved for Sec. 170.503.
(3) ISO/IEC 17065:2012(E)--Conformity assessment--Requirements for
bodies certifying products, processes and services (First Edition),
2012, ``ISO/IEC 17065,'' IBR approved for Sec. 170.503.

Dated: August 20, 2014.
Sylvia M. Burwell,
Secretary.
[FR Doc. 2014-21633 Filed 9-10-14; 8:45 am]
BILLING CODE 4150-45-P

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.