2014-21633. 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 § 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:

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®

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

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.

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

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 “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	Title of regulation paragraph
§ 170.314(a)(18)	Optional—computerized provider order entry—medications	§ 170.314(e)(1)	View, download, and transmit to 3rd party.
§ 170.314(a)(19)	Optional—computerized provider order entry—laboratory	§ 170.314(g)(3)	Safety-enhanced design.
§ 170.314(a)(20)	Optional—computerized provider order entry—diagnostic imaging.
§ 170.314(b)(8)	Optional—transitions of care.
§ 170.314(b)(9)	Optional—clinical information reconciliation and incorporation.
§ 170.314(f)(7)	Optional—ambulatory setting only—Transmission to public health agencies—syndromic surveillance.
§ 170.314(g)(1)	Optional—automated numerator recording.
§ 170.314(h)(1)	Optional—Applicability Statement for Secure Health Transport.
§ 170.314(h)(2)	Optional—Applicability Statement for Secure Health Transport and XDR/XDM for Direct Messaging.
§ 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 (§ 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 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.

Table 2—Distributed Total Development and Preparation Costs for EHR Technology Developers (2-Year Period)—Totals Rounded

Year	Ratio (percent)	Total low cost estimate ($M)	Total high cost estimate ($M)	Total average cost estimate ($M)
2014	50	$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 § 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).

II. Background

A. Statutory Basis

The Health Information Technology for Economic and Clinical Health (HITECH) Act, Title XIII of Division A and Title IV of Division B of the American Recovery and Reinvestment Act of 2009 (the Recovery Act) (Pub. L. 111-5), was enacted on February 17, 2009. The HITECH Act amended the Public Health Service Act (PHSA) and created “Title XXX—Health Information Technology and Quality” (Title XXX) to improve health care quality, safety, and efficiency through the promotion of HIT and electronic health information exchange.

1. Standards, Implementation Specifications, and Certification Criteria

The HITECH Act established two new federal advisory committees, the HIT Policy Committee (HITPC) and the HIT Standards Committee (HITSC) (sections 3002 and 3003 of the PHSA, respectively). Each is responsible for advising the National Coordinator for Health Information Technology (National Coordinator) on different aspects of standards, implementation specifications, and certification criteria. The HITPC is responsible for, among other duties, recommending priorities for the development, harmonization, and recognition of standards, implementation specifications, and certification criteria. Main responsibilities of the HITSC include recommending standards, implementation specifications, and certification criteria for adoption by the Secretary under section 3004 of the PHSA consistent with the ONC-coordinated Federal Health IT Strategic Plan.

Section 3004 of the PHSA identifies a process for the adoption of health IT standards, implementation specifications, and certification criteria and authorizes the Secretary to adopt such standards, implementation specifications, and certification criteria. As specified in section 3004(a)(1), the Secretary is required, in consultation with representatives of other relevant federal agencies, to jointly review standards, implementation specifications, and certification criteria endorsed by the National Coordinator under section 3001(c) and subsequently determine whether to propose the adoption of any grouping of such standards, implementation specifications, or certification criteria. The Secretary is required to publish all determinations in the Federal Register.

Section 3004(b)(3) of the PHSA titled “Subsequent Standards Activity” provides that the “Secretary shall adopt additional standards, implementation specifications, and certification criteria as necessary and consistent” with the schedule published by the HITSC. We consider this provision in the broader context of the HITECH Act to grant the Secretary the authority and discretion to adopt standards, implementation specifications, and certification criteria that have been recommended by the HITSC and endorsed by the National Coordinator, as well as other appropriate and necessary HIT standards, implementation specifications, and certification criteria. Throughout this process, the Secretary intends to continue to seek the insights and recommendations of the HITSC.

2. HIT Certification Programs

Section 3001(c)(5) of the PHSA provides the National Coordinator with the authority to establish a certification program or programs for the voluntary certification of HIT. Specifically, section 3001(c)(5)(A) specifies that the “National Coordinator, in consultation with the Director of the National Institute of Standards and Technology, shall keep or recognize a program or programs for the voluntary certification of health information technology as being in compliance with applicable certification criteria adopted under this subtitle” (i.e., certification criteria adopted by the Secretary under section 3004 of the PHSA).

The certification program(s) must also “include, as appropriate, testing of the technology in accordance with section 13201(b) of the [HITECH] Act.” Overall, section 13201(b) of the HITECH Act requires that with respect to the development of standards and implementation specifications, the Director of the National Institute of Standards and Technology (NIST), in coordination with the HITSC, “shall support the establishment of a conformance testing infrastructure, including the development of technical test beds.” The HITECH Act also indicates that “[t]he development of this conformance testing infrastructure may include a program to accredit independent, non-Federal laboratories to perform testing.”

B. Regulatory History

1. Standards, Implementation Specifications, and Certification Criteria Rules

The Secretary issued an interim final rule with request for comments titled, “Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology” (75 FR 2014, Jan. 13, 2010) (the “S&CC January 2010 interim final rule”), which adopted an initial set of standards, implementation specifications, and certification criteria. After consideration of the public comments received on the S&CC January 2010 interim final rule, a final rule was issued to complete the adoption of the initial set of standards, implementation specifications, and certification criteria and realign them with the final objectives and measures established for meaningful use (MU) Stage 1 (formally titled: Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology; Final Rule, (75 FR 44590, July 28, 2010) and referred to as the “2011 Edition Final Rule”). The 2011 Edition Final Rule also established the first version of the 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 “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.

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 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 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” (§ 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]

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

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 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 (§ 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 § 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 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]

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

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.

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

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

Table 3—Gap Certification Eligibility for 2014 Edition, Release 2 EHR Certification Criteria

2014 edition release 2		2014 Edition		2011 Edition
Regulation section	Title of regulation paragraph	Regulation section	Title of regulation paragraph	Regulation section	Title of regulation paragraph
§ 170.314(a)(18)	Optional—computerized physician order entry—medications
§ 170.314(a)(19)	Optional—computerized physician order entry—laboratory.	§ 170.314(a)(1)	Computerized physician order entry	§ 170.304(a); § 170.306(a)	Computerized physician order entry.
§ 170.314(a)(20)	Optional—computerized physician order entry—diagnostic imaging.
§ 170.314(f)(7)*	Optional—ambulatory setting only—transmission to public health agencies—syndromic surveillance	§ 170.314(f)(3)	Transmission to public health agencies—syndromic surveillance (ambulatory setting only)	§ 170.302(1)	Public health surveillance (ambulatory setting only).
§ 170.314(h)(1)	Optional—Applicability Statement for Secure Health	§ 170.314(b)(1)(i)(A) and § 170.314(b)(2)(ii)(A).	Transitions of care—receive, display, and incorporate transition of care/referral summaries.Transitions of care—create and transmit transition of care/referral summaries.	Not applicable	Not applicable.
§ 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).	Transitions of care—receive, display, and incorporate transition of care/referral summaries Transitions of care—create and transmit transition of care/referral summaries.	Not applicable	Not applicable.
§ 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).	Transitions of care—create and transmit transition of care/referral summaries	Not applicable	Not applicable.
* Gap certification does not apply for the optional data elements listed in § 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 (§ 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 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 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 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. 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.”

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 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 percentage-based 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).

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

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.

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

Commenters that opposed adopting the proposed criterion expressed that the reason for not adopting this criterion in the 2014 Edition still holds (i.e., 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 § 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]

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

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

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

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

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

• 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 § 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 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 (Two-Year Period)—Totals Rounded

Item #	CFR Text	Certification criterion name	Total low cost estimate ($M)	Total high cost estimate ($M)	Total average cost estimate ($M)
1	§ 170.314(a)(18)	CPOE—medications	$0	$.2	$.1
2	§ 170.314(a)(19)	CPOE—laboratory	0	.2	.1
3	§ 170.314(a)(20)	CPOE—diagnostic imaging	0	.2	.1
4	§ 170.314(b)(8)	Transitions of care	.71	1.0	.89
5	§ 170.314(b)(9)	Clinical information reconciliation and incorporation	0	.16	.081
6	§ 170.314(e)(1)	View, download, and transmit to 3rd party	.81	1.22	1.0
7	§ 170.314(f)(7)	Transmission to public health agencies—syndromic surveillance	0	.15	.077
8	§ 170.314(g)(1)	Automated numerator recording	N/A	N/A	N/A
9	§ 170.314(g)(3)	Safety-enhanced design	0	.47	.235
10	§ 170.314(h)(1)	Applicability Statement for Secure Health Transport	.6	1.0	.8
11	§ 170.314(h)(2)	Applicability Statement for Secure Health Transport & XDR/XDM for Direct Messaging	.4	.6	.5
12	§ 170.314(h)(3)	SOAP Transport and Security Specification & XDR/XDM for Direct Messaging	.4	.6	.5
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.

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

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;

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

* * * * *

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

§ 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 http://www.healthit.gov/​sites/​default/​files/​implementationguidefordirectedgeprotocolsv1_​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.

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

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

* * * * *

(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: § 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).

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

* * * * *

§ 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, “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.

Footnotes

1.  79 FR 10881-82.

2.  79 FR 10885.

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

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.

5.  http://www.whitehouse.gov/​omb/​circulars_​a119.

6.  http://www.healthit.gov/​policy-researchers-implementers/​direct-project.

7.  http://www.healthit.gov/​policy-researchers-implementers/​standards-interoperability-si-framework.

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

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.

10.  http://www.healthit.gov/​sites/​default/​files/​implementationguidefordirectedgeprotocolsv1_​1.pdf.

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.

12.  77 FR 54182.

13.  http://wiki.siframework.org/​Query+​Health.

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

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.

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.

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

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.  http://www.iso.org/​iso/​catalogue_​detail.htm?​csnumber=​46568. ISO slide presentation on 17065: http://www.iso.org/​iso/​ppt_​presentation_​17065.ppt.

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

21.  http://www.hhs.gov/​news/​press/​2014pres/​05/​20140513c.html.

22.  http://www.healthit.gov/​policy-researchers-implementers/​onc-hit-certification-program.

23.  http://www.healthit.gov/​sites/​default/​files/​hit_​certificationterms_​of_​use_​final.pdf.

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

25.  http://www.hl7.org/​special/​committees/​projman/​searchableprojectindex.cfm?​action=​edit&​ProjectNumber=​922.

26.  http://www.healthit.gov/​policy-researchers-implementers/​39-question-04-13-039.

27.  http://www.healthit.gov/​policy-researchers-implementers/​34-question-12-12-034.

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.

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. http://www.healthit.gov/​FACAS/​sites/​faca/​files/​clinical_​operations_​wg_​update_​062013_​0.pdf

32.  http://www.ncpdp.org/​Education/​Whitepaper “Challenges and Opportunities for Stakeholders Regarding ePrescribing Technologies and Formulary Compliance”.

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

34.  77 FR 54216.

35.  http://www.healthit.gov/​policy-researchers-implementers/​40-question-04-13-040.

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. http://www.fda.gov/​MedicalDevices/​DeviceRegulationandGuidance/​UniqueDeviceIdentification/​.

37.  http://www.healthit.gov/​sites/​default/​files/​safety_​plan_​master.pdf

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

39.  http://www.hl7.org/​implement/​standards/​product_​brief.cfm?​product_​id=​279.

40.  http://www.hl7.org/​implement/​standards/​product_​brief.cfm?​product_​id=​279.

41.  http://www.qualityforum.org/​WorkArea/​linkit.aspx?​LinkIdentifier=​id&​ItemID=​75398.

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

43.  http://www.healthit.gov/​policy-researchers-implementers/​33-question-12-12-033.

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

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

46.  http://healthit.gov/​policy-researchers-implementers/​32-question-11-12-032.

47.  http://www.healthit.gov/​sites/​default/​files/​fdasia_​healthitreport_​final.pdf.

48.  The Request for Comments is available at: http://www.healthit.gov/​sites/​default/​files/​hitpc_​stage3_​rfc_​final.pdf.

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.

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

51.  http://www.healthit.gov/​sites/​default/​files/​generalcertexchangeguidance_​final_​9-9-13.pdf.

52.  http://www.healthit.gov/​sites/​default/​files/​generalcertexchangeguidance_​final_​9-9-13.pdf.

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.

58.  76 FR 1318.

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. http://www.sba.gov/​sites/​default/​files/​files/​Size_​Standards_​Table.pdf.