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



[[Page 54429]]

Vol. 79

Thursday,

No. 176

September 11, 2014

Part IV





 Department of Health and Human Services





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





 Office of the Secretary





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





45 CFR Part 170





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

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

[[Page 54430]]


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

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Office of the Secretary

45 CFR Part 170

RIN 0991-AB92


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

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

ACTION: Final rule.

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

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

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

FOR FURTHER INFORMATION CONTACT: Michael Lipinski, Office of Policy, 
Office of the National Coordinator for Health Information Technology, 
202-690-7151.

SUPPLEMENTARY INFORMATION: 

Commonly Used Acronyms

CAH Critical Access Hospital
CDA Clinical Document Architecture
CDC Centers for Disease Control and Prevention
CDS Clinical Decision Support
CEHRT Certified Electronic Health Record Technology
CFR Code of Federal Regulations
CHPL Certified Health Information Technology Product List
CLIA Clinical Laboratory Improvement Amendments
CMS Centers for Medicare & Medicaid Services
CQM Clinical Quality Measure
CY Calendar Year
EH Eligible Hospital
EHR Electronic Health Record
EP Eligible Professional
FDA Food and Drug Administration
FY Fiscal Year
HHS Department of Health and Human Services
HIT Health Information Technology
HITECH Health Information Technology for Economic and Clinical 
Health
HITPC HIT Policy Committee
HITSC HIT Standards Committee
HL7 Health Level Seven
IG Implementation Guide
IHE Integrating the Healthcare Enterprise[supreg]
LOINC[supreg] Logical Observation Identifiers Names and Codes
MU Meaningful Use
OMB Office of Management and Budget
ONC Office of the National Coordinator for Health Information 
Technology
NCPDP National Council for Prescription Drug Programs
NIST National Institute of Standards and Technology
PHSA Public Health Service Act
SNOMED CT[supreg] Systematized Nomenclature of Medicine Clinical 
Terms

Table of Contents

I. Executive Summary
    A. Purpose of Regulatory Action
    1. New Approach
    2. Edition Naming Convention
    B. Summary of Major Provisions
    1. Overview of the 2014 Edition Release 2 EHR Certification 
Criteria
    2. ONC HIT Certification Program
    C. Costs and Benefits
II. Background
    A. Statutory Basis
    1. Standards, Implementation Specifications, and Certification 
Criteria
    2. HIT Certification Programs
    B. Regulatory History
    1. Standards, Implementation Specifications, and Certification 
Criteria Rules
    2. ONC HIT Certification Programs Rules
III. Adopted Proposals
    A. 2014 Edition Release 2 EHR Certification Criteria
    1. National Technology Transfer and Advancement Act (NTTAA) of 
1995
    2. Certification Criteria
    3. Gap Certification Eligibility Table for 2014 Edition Release 
2
    4. Base EHR Definition
    B. ONC HIT Certification Program
    1. Discontinuation of the Complete EHR
    2. Applicability
    3. ONC Regulations FAQ 28
    4. Patient List Creation Certification Criteria
    5. ISO/IEC 17065
    6. ONC Certification Mark
    C. Removal of the 2011 Edition EHR Certification Criteria From 
the CFR
    D. Removal of the Temporary Certification Program From the CFR
IV. Not Adopted Proposals
    A. Not Adopted EHR Certification Criteria and Certification 
Criteria Proposals
    B. 2014 Edition and Proposed Voluntary Edition Equivalency Table
    C. HIT Definitions
    1. CEHRT
    2. Common MU Data Set
    C. ONC HIT Certification Program
    1. Non-MU EHR Technology Certification
    2. ``Certification Packages'' for EHR Modules
V. Comments Beyond the Scope of This Final Rule
VI. Collection of Information Requirements
VII. Regulatory Impact Statement
    A. Statement of Need
    B. Overall Impact
    1. Executive Orders 12866 and 13563--Regulatory Planning and 
Review Analysis
    2. Regulatory Flexibility Act
    3. Executive Order 13132--Federalism
    4. Unfunded Mandates Reform Act of 1995

I. Executive Summary

A. Purpose of Regulatory Action

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

    \1\ 79 FR 10881-82.

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

[[Page 54431]]

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

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

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

    \3\ CMS final rule ``Medicare Program; Physicians' Referrals to 
Health Care Entities With Which They Have Financial Relationships: 
Exception for Certain Electronic Health Records Arrangements'' (78 
FR 78751). OIG final rule ``Medicare and State Health Care Programs: 
Fraud and Abuse; Electronic Health Records Safe Harbor Under the 
Anti-Kickback Statute'' (78 FR 79202).
---------------------------------------------------------------------------

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

B. Summary of Major Provisions

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

[[Page 54432]]

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

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

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

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

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

C. Costs and Benefits

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

[[Page 54433]]



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

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

II. Background

A. Statutory Basis

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

[[Page 54434]]

conformance testing infrastructure, including the development of 
technical test beds.'' The HITECH Act also indicates that ``[t]he 
development of this conformance testing infrastructure may include a 
program to accredit independent, non-Federal laboratories to perform 
testing.''

B. Regulatory History

1. Standards, Implementation Specifications, and Certification Criteria 
Rules
    The Secretary issued an interim final rule with request for 
comments titled, ``Health Information Technology: Initial Set of 
Standards, Implementation Specifications, and Certification Criteria 
for Electronic Health Record Technology'' (75 FR 2014, Jan. 13, 2010) 
(the ``S&CC January 2010 interim final rule''), which adopted an 
initial set of standards, implementation specifications, and 
certification criteria. After consideration of the public comments 
received on the S&CC January 2010 interim final rule, a final rule was 
issued to complete the adoption of the initial set of standards, 
implementation specifications, and certification criteria and realign 
them with the final objectives and measures established for meaningful 
use (MU) Stage 1 (formally titled: Health Information Technology: 
Initial Set of Standards, Implementation Specifications, and 
Certification Criteria for Electronic Health Record Technology; Final 
Rule, (75 FR 44590, July 28, 2010) and referred to as the ``2011 
Edition Final Rule''). The 2011 Edition Final Rule also established the 
first version of the CEHRT definition. Subsequent to the 2011 Edition 
Final Rule (October 13, 2010), we issued an interim final rule with a 
request for comment to remove certain implementation specifications 
related to public health surveillance that had been previously adopted 
in the 2011 Edition Final Rule (75 FR 62686).
    The standards, implementation specifications, and certification 
criteria adopted by the Secretary in the 2011 Edition Final Rule 
established the capabilities that CEHRT must include in order to, at a 
minimum, support the achievement of MU Stage 1 by EPs, EHs, and CAHs 
under the Medicare and Medicaid EHR Incentive Programs Stage 1 final 
rule (the ``EHR Incentive Programs Stage 1 final rule'') (see 75 FR 
44314 for more information about MU and the Stage 1 requirements).
    The Secretary issued a notice of proposed rulemaking with request 
for comments titled ``Health Information Technology: Standards, 
Implementation Specifications, and Certification Criteria for 
Electronic Health Record Technology, 2014 Edition; Revisions to the 
Permanent Certification Program for Health Information Technology'' (77 
FR 13832, March 7, 2012) (the ``2014 Edition NPRM''), which proposed 
new and revised standards, implementation specifications, and 
certification criteria. After consideration of the public comments 
received on the 2014 Edition NPRM, a final rule was issued to adopt the 
2014 Edition set of standards, implementation specifications, and 
certification criteria and realign them with the final objectives and 
measures established for MU Stage 2 as well as MU Stage 1 revisions 
(Health Information Technology: Standards, Implementation 
Specifications, and Certification Criteria for Electronic Health Record 
Technology, 2014 Edition; Revisions to the Permanent Certification 
Program for Health Information Technology (77 FR 54163, Sept. 4, 2012) 
(the ``2014 Edition Final Rule''). The standards, implementation 
specifications, and certification criteria adopted by the Secretary in 
the 2014 Edition Final Rule established the capabilities that CEHRT 
must include in order to, at a minimum, support the achievement of MU 
Stage 2 by EPs, EHs, and CAHs under the Medicare and Medicaid EHR 
Incentive Programs Stage 2 final rule (the ``EHR Incentive Programs 
Stage 2 final rule'') (see 77 FR 53968 for more information about the 
MU Stage 2 requirements).
    On December 7, 2012, an interim final rule with a request for 
comment was jointly issued by ONC and CMS to update certain standards 
that had been previously adopted in the 2014 Edition Final Rule. The 
interim final rule also revised the EHR Incentive Programs by adding an 
alternative measure for the MU Stage 2 objective for hospitals to 
provide structured electronic laboratory results to ambulatory 
providers, corrected the regulation text for the measures associated 
with the objective for hospitals to provide patients the ability to 
view online, download, and transmit information about a hospital 
admission, and made the case number threshold exemption policy for 
clinical quality measure (CQM) reporting applicable for eligible 
hospitals and CAHs beginning with FY 2013. The rule also provided 
notice of CMS's intent to issue technical corrections to the electronic 
specifications for CQMs released on October 25, 2012 (77 FR 72985).
    On November 4, 2013, the Secretary published an interim final rule 
with a request for comment, 2014 Edition Electronic Health Record 
Certification Criteria: Revision to the Definition of ``Common 
Meaningful Use (MU) Data Set'' (78 FR 65884), to make a minor revision 
to the Common MU Data Set definition. This revision was intended to 
allow more flexibility with respect to the representation of dental 
procedures data for EHR technology testing and certification.
    On February 26, 2014, the Secretary issued the Proposed Rule. The 
Proposed Rule proposed voluntary certification criteria that would 
enable a more efficient and effective response to stakeholder feedback, 
incorporate ``bug fixes'' to improve on 2014 Edition in ways designed 
to make ONC's rules clearer and easier to implement, and reference 
newer standards and implementation specifications. A correction notice 
was published for the Proposed Rule on March 19, 2014, entitled 
``Voluntary 2015 Edition Electronic Health Record (EHR) Certification 
Criteria; Interoperability Updates and Regulatory Improvements; 
Correction'' (79 FR 15282). This correction notice corrected the 
preamble text and gap certification table for four certification 
criteria that were omitted from the list of certification criteria 
eligible for gap certification for the 2015 Edition EHR certification 
criteria.
    On May 23, 2014, CMS and ONC jointly published the ``Medicare and 
Medicaid Programs; Modifications to the Medicare and Medicaid 
Electronic Health Record Incentive Programs for 2014; and Health 
Information Technology: Revisions to the Certified EHR Technology 
Definition'' proposed rule (79 FR 29732). The rule proposed to update 
the MU Stage 2 and Stage 3 participation timeline. It proposed to 
revise the CEHRT definition to permit the use of EHR technology 
certified to the 2011 Edition to meet the CEHRT definition for FY/CY 
2014. It also proposed to allow EPs, EHs, and CAHs that could not fully 
implement EHR technology certified to the 2014 Edition for an EHR 
reporting period in 2014 due to delays in the availability of such 
technology to continue to use EHR technology certified to the 2011 
Edition or a combination of EHR technology certified to the 2011 
Edition and 2014 Edition for the EHR reporting periods in CY 2014 and 
FY 2014. On September 4, 2014, a final rule (``MU Flexibility Final 
Rule'') was published (79 FR 52910) adopting these proposals.
2. ONC HIT Certification Program Rules
    On March 10, 2010, ONC published a proposed rule (75 FR 11328) 
titled, ``Proposed Establishment of Certification Programs for Health 
Information Technology'' (the

[[Page 54435]]

``Certification Programs proposed rule''). The rule proposed both a 
temporary and permanent certification program for the purposes of 
testing and certifying HIT. It also specified the processes the 
National Coordinator would follow to authorize organizations to perform 
the certification of HIT. A final rule establishing the temporary 
certification program was published on June 24, 2010 (75 FR 36158) (the 
``Temporary Certification Program final rule'') and a final rule 
establishing the permanent certification program was published on 
January 7, 2011 (76 FR 1262) (``the Permanent Certification Program 
final rule'').
    On May 31, 2011, ONC published a proposed rule (76 FR 31272) titled 
``Permanent Certification Program for Health Information Technology; 
Revisions to ONC-Approved Accreditor Processes.'' The rule proposed a 
process for addressing instances where the ONC-Approved Accreditor 
(ONC-AA) engaged in improper conduct or did not perform its 
responsibilities under the permanent certification program, addressed 
the status of ONC-Authorized Certification Bodies in instances where 
there may be a change in the accreditation organization serving as the 
ONC-AA, and clarified the responsibilities of the new ONC-AA. All these 
proposals were finalized in a final rule published on November 25, 2011 
(76 FR 72636).
    The 2014 Edition Final Rule made changes to the permanent 
certification program. The final rule adopted a proposal to change the 
Permanent Certification Program's name to the ``ONC HIT Certification 
Program,'' revised the process for permitting the use of newer versions 
of ``minimum standard'' code sets, modified the certification processes 
ONC-Authorized Certification Bodies (ONC-ACBs) need to follow for 
certifying EHR Modules in a manner that provides clear implementation 
direction and compliance with the new certification criteria, and 
reduced regulatory burden by eliminating the certification requirement 
that every EHR Module be certified to the ``privacy and security'' 
certification criteria.
    The Proposed Rule included proposals that focused on improving 
regulatory clarity, simplifying the certification of EHR Modules that 
are designed for purposes other than achieving MU, and discontinuing 
the use of the Complete EHR definition starting with the ``Proposed 
Voluntary Edition.''

III. Adopted Proposals

A. 2014 Edition Release 2 EHR Certification Criteria

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

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

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

[[Page 54436]]

criterion (i.e., the adaptation must be capable of performing CPOE for 
each of the three types of orders (medication, laboratory and 
radiology/imaging)) even though the EHR technology developer's 
customers may only wish to use the mobile adaptation to enter 
medication orders away from the office.
---------------------------------------------------------------------------

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

    Similarly, we noted that some providers could interpret our 
approach to CPOE certification as inconsistent with the flexibility 
provided in the FY/CY 2014 CEHRT definition under Sec.  170.102. As one 
example, we noted that the MU Stage 2 CPOE objective for EPs includes 
three associated measures (one measure for each of the three types of 
orders) and exclusions for each of those three measures. An EP who 
could potentially meet an exclusion for one or two of the measures 
would still need to possess EHR technology certified to the 2014 
Edition CPOE certification criterion (that is, CEHRT that includes CPOE 
capabilities for each of the three types of orders). As another 
example, we stated that the MU Stage 1 CPOE objective for EPs does not 
include measures for laboratory and radiology orders, which means EPs 
attempting this objective also do not necessarily require these 
additional certified CPOE capabilities. As one final example, we 
explained that if an EP expects to meet the MU exclusion for one or two 
of the MU measures (i.e., writing fewer than 100 of each order type 
during an EHR reporting period), they could choose to adopt EHR 
technology certified only to the proposed CPOE certification criterion 
for the order types reflected in the measure(s) they expect to 
demonstrate for MU. This approach would permit an EP to meet the Base 
EHR definition requirements and CEHRT definition without having to 
adopt EHR technology that includes certified CPOE capabilities they 
would not expect to use for MU.
    For the reasons above, we proposed to split the CPOE certification 
criterion for the Proposed Voluntary Edition into three separate 
certification criteria with each criterion focused on one of the three 
order types, reasoning that certification criteria focused on each 
order type would permit EHR technology developers to develop order-
specific CPOE adaptations and provide EPs, EHs, and CAHs with 
significantly more implementation flexibility.
    In the Proposed Rule, we also stated that the proposed ``CPOE'' 
certification criteria would omit the ``at a minimum'' language 
included in the 2014 Edition and 2011 Edition CPOE certification 
criteria. We noted that the ``at a minimum'' language was included in 
prior editions to indicate that EHR technology developers could include 
capabilities that support other types of orders. We stated that this 
language is extraneous because we have consistently maintained that 
certification criteria (and certification in general) serve as minimum 
requirements or a baseline.
    Comments. We received universal support for adopting three separate 
CPOE certification criteria based on medications, laboratory, and 
radiology/imaging orders. We also received support for the elimination 
of the ``at a minimum'' language found in the 2011 and 2014 Edition 
criteria with commenters stating that elimination of the language would 
remove redundancy from the criteria and reduce confusion.
    Response. We have adopted these three certification criteria as 
2014 Edition optional certification criteria based on stakeholder 
feedback and for the reasons we cited in the Proposed Rule. We clarify 
and emphasize that there are no standards included in the optional 
certification criteria, unlike the proposed CPOE--laboratory 
certification criterion. We have also omitted the ``at a minimum'' 
language in these certification criteria for the reasons proposed and 
supported by commenters.
    We have changed the title of the certification criterion that 
supports CPOE for ``radiology/imaging'' (Sec.  170.314(a)(20)) to 
``CPOE--diagnostic imaging'' and changed the relevant regulation text 
of this certification criterion from ``radiology and imaging orders'' 
to ``diagnostic imaging orders.'' We have also made a similar revision 
to Sec.  170.3014(a)(1)(iii) by replacing ``radiology/imaging'' with 
``diagnostic imaging.'' We have made these revisions to eliminate any 
potential confusion as to the type of orders we are referencing. We 
note, however, that these revisions in no way alter the required 
capability.
    We have adopted the optional certification criteria at Sec.  
170.314(a)(18) through (20) and included them in the Base EHR 
definition. We have also revised the ``safety-enhanced design'' (SED) 
certification criterion at Sec.  170.314(g)(3) to include the three 
optional CPOE certification criteria. These optional CPOE certification 
criteria included the same ``patient safety-related'' capabilities 
included in the CPOE certification criterion at Sec.  170.314(a)(1) and 
thus the same ``patient safety risk'' rationale for their inclusion in 
the SED certification criterion at Sec.  170.314(g)(3) applies.\9\
---------------------------------------------------------------------------

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

    As we noted in the Proposed Rule (79 FR 10886), we caution that 
this additional flexibility comes with potential risk for EPs who 
expect to qualify for one or more of the exclusions from the CPOE 
measures, but do not ultimately satisfy the exclusion criteria based on 
the number of orders written during an EHR reporting period. EPs who 
choose to possess EHR technology that is not certified for each of the 
three types of orders may risk not having EHR technology that meets the 
CEHRT definition if they ultimately fail to meet one or more MU 
exclusions. Therefore, we emphasize that EHR technology developers need 
to be aware that this additional certification flexibility and 
subsequent certification decisions could have corresponding impacts on 
EPs who are ultimately responsible for ensuring that their EHR 
technology meets the CEHRT definition.
    We note that we discuss comments received on each of the three 
proposed CPOE certification criteria that suggested changes to the 
criteria under section IV.A ``Not Adopted EHR Certification Criteria 
and Certification Criteria Proposals.'' This includes a discussion of 
our reasons for not adopting the HL7 Laboratory Orders Interface (LOI) 
standard and the Clinical Laboratory Improvement Amendments (CLIA)-
related requirements for the proposed ``CPOE--laboratory'' 
certification criterion.
Transitions of Care
    We proposed to make several changes to the ``transitions of care'' 
(ToC) certification criterion, including decoupling content and 
transport capabilities, the inclusion of the Direct Edge Protocols IG 
Version 1.0, and shifting the ``incorporation'' requirements into an 
updated ``clinical information reconciliation and incorporation'' 
(CIRI). We included several other proposals in the ToC certification 
criterion that we have not finalized. These proposals are discussed in 
section IV.A of this preamble.
``Decoupling'' Content and Transport
    In the Proposed Rule, we recited specific stakeholder feedback 
stating that the ``binding'' of transport and content capabilities 
within the scope of a single certification criterion could impede 
innovation and limit EPs', EHs', and CAHs' market choices for 
electronic health information exchange. We also recited stakeholder 
feedback indicating that we had incorrectly imposed the coupling of 
technical capabilities that

[[Page 54437]]

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

    \10\ http://www.healthit.gov/sites/default/files/implementationguidefordirectedgeprotocolsv1_1.pdf.
---------------------------------------------------------------------------

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

[[Page 54438]]

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

[[Page 54439]]

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

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

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

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

Transmission to Public Health Agencies--Syndromic Surveillance
    We proposed to revise the 2014 Edition ``syndromic surveillance'' 
certification criterion and adopt a parallel ``syndromic surveillance'' 
certification criterion for the Proposed Voluntary Edition.
    For both MU Stages 1 and 2, EPs may choose the ``electronic 
syndromic surveillance data'' objective under the menu set. In the MU 
Stage 2 final rule, CMS stated that very few public health agencies 
were accepting syndromic surveillance data from ambulatory, non-
hospital providers, and there was no corresponding HL7 2.5.1 IG 
available at the time of the final rule's publication (77 FR 54025). 
CMS also noted, however, that the CDC was working with the syndromic 
surveillance community to develop a new IG for ambulatory reporting of 
syndromic surveillance data, which was expected to be published in 
spring 2013.
    We stated in the Proposed Rule that only a few public health 
agencies are currently accepting syndromic surveillance data from the 
ambulatory setting using HL7 2.5.1. We stated that due to lack of 
demand, the CDC no longer planned to develop an HL7 2.5.1 IG for 
ambulatory reporting of syndromic surveillance data and that without 
such an IG most public health agencies would not have enough specific 
guidance to build systems to receive syndromic surveillance data from 
the ambulatory setting formatted to HL7 2.5.1. Further, we noted that 
the MU Stage 2 final rule permits an EP, EH, or CAH to claim an 
exclusion if the public health agency does not have the

[[Page 54440]]

capacity to accept reporting (77 FR 54021) and, therefore, many EPs may 
qualify for an exclusion for this objective and associated measure and, 
as a result, would need to choose another objective from the menu set 
on which to report.
    Given the lack of an ambulatory IG for HL7 2.5.1, we proposed to 
revise the current 2014 Edition certification criterion to allow EHR 
technology designed for the ambulatory setting to be certified to 
alternative standards that support other modes of electronic syndromic 
surveillance data submission. In this regard, we indicated that 
syndromic surveillance data was being sent to public health agencies 
through new query-based models, including the QueryHealth 
initiative.\13\ Query-based models take patient level data, de-identify 
it, and aggregate it for population health use. In the Proposed Rule, 
we also noted that we understood that the query-based models use HL7 
CDA and QRDA Category III (``QRDA III'') standards, and did not 
necessarily use the HL7 2.5.1 standard. Further, we stated that CDA and 
QRDA III standards were adopted and referenced by 2014 Edition 
certification criteria and, as a result, had become more widely 
implemented.
---------------------------------------------------------------------------

    \13\ http://wiki.siframework.org/Query+Health.
---------------------------------------------------------------------------

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

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

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

[[Page 54441]]

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

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

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

[[Page 54442]]

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

[[Page 54443]]



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

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

B. ONC HIT Certification Program

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

[[Page 54444]]

EHR certification by the MU Stage it would be associated with, while 
another suggested calling it a ``Comprehensive EHR.''
    Response. We have finalized our proposal to discontinue the 
Complete EHR definition and Complete EHR certification. While we have 
not adopted the Proposed Voluntary Edition, this approach will apply 
for all future adopted editions of certification criteria as specified 
in Sec.  170.501(b) (discussed in more detail under section III.B.2 
``Applicability'' of this preamble). To be clear, the discontinuation 
of the Complete EHR definition and Complete EHR certification will have 
no impact on current 2014 Edition Complete EHR certifications or in 
using a 2014 Edition Complete EHR to meet the current CEHRT definition. 
In regard to additional 2014 Edition Release 2 certification criteria, 
we have adopted them all as optional criteria and thus they do not 
impact the 2014 Edition Complete EHR definition.
    In the Proposed Rule (79 FR 10917-10918), we explained our 
rationale for discontinuing the Complete EHR definition. We are 
reciting our rationale again here as we still believe these reasons 
hold true. Following the recitation of these reasons, with minor 
modifications due to the MU Flexibility Final Rule (79 FR 52910), we 
offer further rationale and responses to comments.
    (1) The Complete EHR definition initially was intended to support 
the original CEHRT definition established in the 2011 Edition Final 
Rule under Sec.  170.102. As a general summary, the original CEHRT 
definition required an EP, EH, and CAH to have EHR technology that met 
ALL of the certification criteria adopted for an applicable setting 
(ambulatory or inpatient). The ``Complete EHR'' term and definition was 
meant to convey that all applicable certification criteria had been met 
and the statutory requirements of the Qualified EHR definition had been 
fulfilled. The CEHRT definition based on EHR technology certification 
to the 2014 Edition (2014 Edition CEHRT definition) and Complete EHR 
definition no longer share the same symmetry. In fact, the 2014 Edition 
Complete EHR definition now exceeds the 2014 Edition CEHRT definition's 
requirements as to the number of certification criteria to which an EHR 
technology would need to be certified to meet the CEHRT definition.
    (2) Since publication of the 2014 Edition Final Rule, we have 
received stakeholder feedback through email questions and during 
educational presentations and other outreach that demonstrates 
confusion about the interplay between the CEHRT definition, the Base 
EHR definition (adopted as part of the 2014 Edition Final Rule), and 
the Complete EHR definition. Stakeholders have correctly concluded that 
a certified 2014 Edition Complete EHR could be used to meet the CEHRT 
definition. However, some stakeholders believe incorrectly that their 
only regulatory option to meet the CEHRT definition is to adopt a 
certified Complete EHR when, under the CEHRT definition for FY/CY 2014 
and subsequent years in Sec.  170.102, they can use EHR technology (EHR 
Module(s)) certified to the 2014 Edition EHR certification criteria 
that meets the Base EHR definition (a finite set of capabilities) and 
includes all other capabilities that are necessary to meet the 
objectives and measures and successfully report CQMs for the MU Stage 
they are attempting to achieve.
    (3) A Complete EHR is not necessarily ``complete'' or sufficient 
when it comes to an EP's, EH's, or CAH's attempt to achieve MU. For 
example, based on the ``Complete EHR, 2014 Edition'' definition, it may 
not be certified to particular CQMs on which an EP intends to report 
and it may not have been certified to capabilities included in optional 
certification criteria that an EP needs for MU, such as the 2014 
Edition cancer reporting certification criteria (Sec.  170.314(f)(5) 
and (6)). Thus, if we were to continue this policy approach, we believe 
this discrepancy would only grow and cause greater confusion over time.
    (4) Stakeholder feedback to us since the 2014 Edition Final Rule 
(via conference and webinar question and answer sessions, public 
meetings, and emails) and the data currently available on the CHPL 
indicates that some EHR technology developers have continued to seek 
only a 2014 Edition Complete EHR certification and, thus, only plan to 
offer a certified Complete EHR as a solution to customers. While we 
recognize EHR technology developers may choose to pursue various 
approaches for designing and marketing their products, we are in a 
position to modify our policy so that it does not encourage EHR 
technology developers to offer only a single certified solution. In 
general, we believe the decision to seek certification only for a 
Complete EHR serves to defeat the flexibility provided by the 2014 
Edition CEHRT definition. Consequently, by discontinuing the 
availability of the Complete EHR certification, the EHR technology 
market could be driven by EHR technology developers competing on the 
capabilities included in their EHR technology rather than on the type 
of certification issued (Complete EHR or EHR Module).
    (5) The discrepancy between what any single EP, EH, or CAH needs to 
achieve MU and the Complete EHR definition will likely only grow more 
disparate when we adopt certification criteria in a new edition to 
support MU Stage 3. At that time, there may be EPs, EHs, and CAHs 
attempting to achieve each of the three stages of MU, but a Complete 
EHR following the structure of the 2014 Edition Complete EHR definition 
would likely include capabilities that support core and menu objectives 
and measures for all MU stages.
    (6) Discontinuing the use of the Complete EHR concept would be 
consistent with the instruction of Executive Order 13563 to identify 
and consider approaches that make the agency's regulatory program more 
effective or less burdensome in achieving the regulatory objectives. To 
illustrate, we would not need to designate EHR certification criteria 
as mandatory or optional in our regulation text as these categories 
were specifically developed to accommodate the Complete EHR definition 
(i.e., cases where EHR technology would otherwise have to be certified 
to a criterion solely because it is required in order to satisfy the 
Complete EHR certification).
    As stated in the Proposed Rule, discontinuation of Complete EHR 
definition and certification does not affect EHR Module certification. 
In fact, as it stands now with 2014 Edition certification, an EHR 
Module certificate can be issued to an EHR technology that includes 
every certification criterion that is included in a Complete EHR 
certificate issued to an EHR technology (and even with the EHR Module 
certificate, the capabilities can be integrated in the same 
manner),\16\ but would not be given the ``Complete EHR'' designation. 
The discontinuation of the Complete EHR definition and certification 
will also help to address commenters' concerns about clearly knowing 
what certification criteria an EHR technology is certified to because, 
unlike Complete EHR developers for their Complete EHRs, an EHR Module 
developer is required by regulation to specifically list in 
communications and marketing materials all the certification criteria 
to which the EHR technology was certified and for which it was issued 
an EHR Module certificate.

[[Page 54445]]

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

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

2. Applicability
    We proposed to revise the ``applicability'' section (Sec.  170.501) 
for the ONC HIT Certification Program to clearly indicate that 
references to the term Complete EHR and Complete EHR certification do 
not apply to certification in accordance with the Proposed Voluntary 
Edition and any subsequent edition of certification criteria adopted by 
the Secretary under subpart C. This proposal was consistent with our 
proposal to discontinue the use of the Complete EHR concept and 
Complete EHR certification beginning with the Proposed Voluntary 
Edition.
    Comments. We received two comments expressing agreement with our 
proposal.
    Response. We have finalized our proposal consistent with our 
decision to finalize the proposals to discontinue use of the Complete 
EHR concept and Complete EHR certification for any subsequent adopted 
edition of certification criteria. We have, however, finalized this 
proposal in a manner that accounts for our decision not to adopt the 
Proposed Voluntary Edition. Specifically, we have revised Sec.  
170.501(b) to read: ``References to the term Complete EHR and Complete 
EHR certification throughout this subpart do not apply to certification 
in accordance with any edition of certification criteria that is 
adopted by the Secretary under subpart C after the 2014 Edition EHR 
certification criteria.''
3. ONC Regulations FAQ 28
    In ONC regulations FAQ 28,\17\ we provide guidance on the 
application of Sec.  170.314(g)(1) and (g)(2) to the certification of 
Complete EHRs and EHR Modules. We state in FAQ 28 and in the 2014 
Edition Final Rule (77 FR 54186) that ONC-ACBs can certify an EHR 
Module to either the 2014 Edition ``automated numerator recording'' 
certification criterion or the 2014 Edition ``automated measure 
calculation'' certification criterion.
---------------------------------------------------------------------------

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

    To provide regulatory clarity, we proposed to revise Sec.  
170.550(f)(1) to specify this flexibility for the certification of EHR 
Modules to the 2014 Edition and proposed the same flexibility in Sec.  
170.550(g)(1) for MU EHR Modules certified to the Proposed Voluntary 
Edition ``automated numerator recording'' certification criterion and 
the ``automated measure calculation'' certification criterion. We also 
clarified that an EHR Module (or proposed ``MU EHR Module'' with regard 
to the Proposed Voluntary Edition) could be certified to only the 
``automated measure calculation'' certification criterion (Sec. Sec.  
170.314(g)(2) or proposed 170.315(g)(2)) in situations where the EHR 
Module does not include a capability that supports a percentage-based 
MU objective and measure, but can meet the requirements of the 
``automated measure calculation'' certification criterion (Sec. Sec.  
170.314(g)(2) or proposed 170.315(g)(2)). We noted that an example of 
this would be an ``analytics'' EHR Module where data is fed from other 
EHR technology and the EHR Module can record the requisite numerators, 
denominators and create the necessary percentage report as specified in 
the ``automated measure calculation'' certification criterion. In these 
situations, we stated that Sec.  170.550(f)(1) or (g)(1) would not be 
implicated or need to be applied.
    We proposed to revise Sec.  170.314(g)(1) to be an optional 
certification criterion as a means of providing regulatory clarity for 
the certification of Complete EHRs to the 2014 Edition, which would 
implement the guidance provided in FAQ 28. In FAQ 28, we stated that 
EHR technology issued a 2014 Edition Complete EHR certification must be 
certified to Sec.  170.314(g)(2) because it is a mandatory 
certification criterion consistent with the 2014 Edition Complete EHR 
definition requiring certification to all mandatory certification 
criteria for a particular setting (ambulatory or inpatient), but not 
Sec.  170.314(g)(1) (even though it too was designated as a mandatory 
certification criterion) because a 2014 Edition Complete EHR would have 
demonstrated capabilities beyond those included in Sec.  170.314(g)(1) 
by being certified to (g)(2).
    We proposed that if were to retain the Complete EHR concept for the 
Proposed Voluntary Edition, we would take the same approach for 
Complete EHRs as specified in FAQ 28 and in our proposed regulatory 
changes to Sec.  170.314(g)(1).
    Comments. We received a few comments supporting the continued 
requirement for Complete EHRs to be certified to the ``automated 
measure calculation'' certification criterion (Sec.  170.314(g)(2)). We 
received one comment supporting our proposal to revise Sec.  
170.314(g)(1) to be an optional certification criterion as a means of 
providing regulatory clarity for the certification of Complete EHRs to 
the 2014 Edition.
    Response. We have not finalized the proposals related to the 
Proposed Voluntary Edition because we have not adopted the Proposed 
Voluntary Edition. We have, however, finalized the proposals related to 
the 2014 Edition. We have designated the ``automated numerator 
recording'' certification criterion at Sec.  170.314(g)(1) as an 
optional certification criterion, which will provide greater regulatory 
clarity for ONC-ACBs as they determine whether EHR technology meets the 
2014 Edition Complete EHR definition and therefore must be certified to 
Sec.  170.314(g)(2). Certification to Sec.  170.314(g)(2) is required 
to meet the 2014 Complete EHR definition as it is a mandatory 
certification criterion. This approach is also supported by commenters. 
We have revised Sec.  170.550(f)(1) to require ONC-ACBs to certify EHR 
Modules to either Sec.  170.314(g)(1) or (2), rather than just 
requiring certification to Sec.  170.314(g)(1). This will implement FAQ 
28 guidance and flexibility as well as provide regulatory clarity.
    We also maintain our clarification and guidance included in the 
Proposed Rule related to an EHR Module being able to be certified to 
only the ``automated measure calculation'' certification criterion 
(Sec.  170.314(g)(2)) in situations where the EHR Module does not 
include a capability that supports a percentage-based MU objective and 
measure, but can meet the requirements of the ``automated measure 
calculation'' certification criterion.
4. Patient List Creation Certification Criteria
    In the Proposed Rule, we discussed how the 2014 Edition (and 
Proposed Voluntary Edition) ``patient list creation'' certification 
criterion includes capabilities that support two MU objectives, one 
with a percentage-based measure and one without (i.e., ``use clinically 
relevant information to identify patients who should receive reminders 
for preventive/follow-up care and send these patients the reminders, 
per patient preference'' (``patient

[[Page 54446]]

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

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

    Comments. We received a few comments supporting our clarification 
and guidance. An ONC-ACB further noted that, in its experience, there 
are only a ``handful'' of EHR technologies presented for certification 
for which this type of scenario would be applicable.
    Response. We appreciate commenters' support and agreement with our 
clarification and guidance. While we have not adopted the proposed 
``patient list creation'' certification criterion, our clarification 
and guidance remains applicable for the certification of EHR technology 
to the 2014 Edition ``patient list creation'' certification criterion 
(Sec.  170.314(a)(14)). As noted by the ONC-ACB, the clarification and 
guidance will be helpful in facilitating the proper certification of at 
least some EHR technology to the 2014 Edition ``patient list creation'' 
certification criterion.
5. ISO/IEC 17065
    Section 170.503(b)(1) requires applicants for ONC-Approved 
Accreditor (ONC-AA) status to provide a detailed description of their 
experience evaluating the conformance of certification bodies to 
International Organization for Standardization/International 
Electrotechnical Commission (ISO/IEC) Guide 65:1996 (``Guide 65''). 
Section 170.503(e)(2) requires the ONC-AA to verify that the 
certification bodies it accredits and ONC-ACBs conform to, at a 
minimum, Guide 65. The ISO issued ISO/IEC 17065: 2012 \19\ (ISO 17065), 
which cancels and replaces Guide 65.
---------------------------------------------------------------------------

    \19\ http://www.iso.org/iso/catalogue_detail.htm?csnumber=46568. ISO slide presentation 
on 17065: http://www.iso.org/iso/ppt_presentation_17065.ppt.
---------------------------------------------------------------------------

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

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

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

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

6. ONC Certification Mark
    ONC has developed and administers the ``ONC Certified HIT'' 
certification and design mark (the ``Mark'').\22\ The Mark, as used by 
an authorized user, certifies that a particular HIT product (Complete 
EHR, EHR Module, or other types of HIT for which the Secretary of HHS 
adopts applicable certification criteria, see 45 CFR 170.510) has been 
tested in accordance with test procedures approved by the National 
Coordinator; has been certified in accordance with the certification 
criteria adopted by the Secretary at 45 CFR part 170, Subpart C; and 
has met all other required conditions of the ONC HIT Certification 
Program at 45 CFR part 170, Subpart E.
---------------------------------------------------------------------------

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

    We proposed to require ONC-ACBs to use the Mark in connection with 
HIT they certify under the ONC HIT Certification Program. More 
specifically, we proposed to revise Sec.  170.523 (``Principles of 
Proper Conduct'') to require ONC-ACBs to display the Mark on all 
certifications issued under the ONC HIT Certification Program in a 
manner that complies with the Criteria and Terms of Use for the ONC 
Certified HIT Certification and Design Mark (``Terms of Use'').\23\ In 
addition, we proposed to revise Sec.  170.523 to require ONC-ACBs to 
ensure that use of the Mark by HIT developers whose products are 
certified under the ONC HIT Certification Program is compliant with the 
Terms of Use. We noted that, in the event that the Terms of Use are 
revised or updated, compliance with the most recent version would be 
required.
---------------------------------------------------------------------------

    \23\ http://www.healthit.gov/sites/default/files/hit_certificationterms_of_use_final.pdf.
---------------------------------------------------------------------------

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

[[Page 54447]]

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

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

    We proposed to remove the 2011 Edition EHR Certification Criteria 
and related standards, terms, and requirements from the CFR. 
Specifically, we proposed to remove 45 CFR 170.302, 170.304, and 
170.306. We also proposed to remove the standards and implementation 
specifications found in 45 CFR 170.205, 170.207, 170.210, and 170.299 
that are only referenced in the 2011 Edition EHR certification 
criteria. In regard to terms, we proposed to retire the definitions 
found in 45 CFR 170.102 related to the 2011 Edition, including ``2011 
Edition EHR certification criteria'' and ``Complete EHR, 2011 
Edition.'' In regard to requirements, we proposed to remove Sec.  
170.550(e) and any other requirement in subpart E, Sec. Sec.  170.500 
through 170.599 that is specific to the 2011 Edition and does not have 
general applicability to other editions of certification criteria.
    Comments. We received one comment supporting this ``administrative 
update.''
    Response. In the Proposed Rule, we stated that EHR technology 
certified to 2011 Edition no longer meets the CEHRT definition. We also 
referenced recent rulemakings by the HHS Office of Inspector General 
and CMS around donations of EHR items and services that cited our 
expectations to retire old/no longer applicable certification criteria 
editions.\24\ As noted in the Proposed Rule, we believe this approach 
will streamline our requirements and ensure there is no regulatory 
confusion involving administration of ONC's rules and the rules of 
other agencies' such as CMS's Physician Self-Referral Law exception and 
OIG's Anti-kickback Statute safe harbor for certain EHR donations. 
Therefore, consistent with EO 13563 instruction to ``determine whether 
any [agency] regulations should be modified, streamlined, expanded, or 
repealed so as to make the agency's regulatory program more effective 
or less burdensome in achieving the regulatory objectives,'' we are 
removing the 2011 Edition EHR certification criteria and related 
standards, terms, and requirements from the CFR.
---------------------------------------------------------------------------

    \24\ CMS final rule ``Medicare Program; Physicians' Referrals to 
Health Care Entities With Which They Have Financial Relationships: 
Exception for Certain Electronic Health Records Arrangements'' (78 
FR 78751).OIG final rule ``Medicare and State Health Care Programs: 
Fraud and Abuse; Electronic Health Records Safe Harbor Under the 
Anti-Kickback Statute'' (78 FR 79202).
---------------------------------------------------------------------------

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

D. Removal of the Temporary Certification Program From the CFR

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

IV. Not Adopted Proposals

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

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

    Section 170.300 establishes the applicability of subpart C--
Certification Criteria for Health Information Technology. We proposed 
to revise paragraph (d) of Sec.  170.300 to add in a reference to Sec.  
170.315, which would clarify which specific capabilities within a 
certification criterion included in Sec.  170.315 have general 
applicability (i.e., apply to both ambulatory and inpatient settings) 
or apply only to an inpatient setting or an ambulatory setting.
    Comments. We did not receive any comments on this specific 
proposal.
    Response. As noted in the Executive Summary, we have not adopted 
the Proposed Voluntary Edition. Rather, we have only adopted a small 
subset of the proposed certification criteria as optional 2014 Edition 
EHR certification criteria and made revisions to 2014 Edition EHR 
certification criteria that provide flexibility, clarity, and enhance 
health information exchange. Therefore, we have not revised paragraph 
(d) of Sec.  170.300 to add in a reference to Sec.  170.315. The 
optional certification criteria that we have adopted in this final rule 
will be part of the 2014 Edition and are included in Sec.  170.314, 
which is already referenced in paragraph (d) of Sec.  170.300.
Computerized Provider Order Entry--Medications
    We proposed to adopt for the Proposed Voluntary Edition a CPOE

[[Page 54448]]

certification criterion specific to medication ordering. The proposed 
criterion was structured substantially similar to the 2014 Edition CPOE 
certification criterion, except it did not reference laboratory and 
radiology/imaging orders. We did not request any specific public 
comments on this certification criterion.
    Comments. One commenter recommended that we add functionality that 
would allow health care providers to electronically report adverse 
events related to medications directly to manufacturers and the Food 
and Drug Administration (FDA). Another commenter suggested that when 
providers order medication, labs and radiology that providers 
electronically send a CDA formatted document to the patient, where the 
capability exists.
    Response. We appreciate these comments, but they are outside the 
scope of the proposed criterion. We have not adopted this certification 
criterion as part of the Proposed Voluntary Edition because we have not 
adopted the Proposed Voluntary Edition. Rather, we have only adopted a 
small subset of the proposed certification criteria as optional 2014 
Edition EHR certification criteria and made revisions to 2014 Edition 
EHR certification criteria that provide flexibility, clarity, and 
enhance health information exchange. As discussed under section III.A.2 
of this preamble, we have adopted this certification criterion without 
modification as a 2014 Edition optional certification criterion.
Computerized Provider Order Entry--Laboratory
    We proposed to adopt for the Proposed Voluntary Edition a CPOE 
certification criterion specific to laboratory ordering. We proposed to 
adopt, for the ambulatory setting, the HL7 Version 2.5.1 Implementation 
Guide: S&I Framework Laboratory Orders from EHR, Release 1-US Realm, 
Draft Standard for Trial Use, November 2013 (LOI).\25\ We also proposed 
to require the use of, at a minimum, the version of Logical Observation 
Identifiers Names and Codes (LOINC[supreg]) adopted at Sec.  
170.207(c)(2) (version 2.40) as the vocabulary standard for laboratory 
orders. Last, we proposed that laboratory orders must include all the 
information for a test requisition as specified at 42 CFR 
493.1241(c)(1) through (c)(8). We stated that the use of these 
standards and compliance with these requirements should greatly improve 
the interoperability of laboratory orders sent from ambulatory EHR 
technology to a laboratory and laboratory compliance with the Clinical 
Laboratory Improvements Amendments (CLIA).
---------------------------------------------------------------------------

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

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

[[Page 54449]]

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

[[Page 54450]]

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

[[Page 54451]]

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

[[Page 54452]]

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

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

    We proposed to include and adopt the HL7 Implementation Guide: 
Service-Oriented Architecture Implementations of the Context-aware 
Knowledge Retrieval (Infobutton) Domain, Release 1, August 2013 (at 
Sec.  170.204(b)(3)) in place of the older version referenced by the 
2014 Edition certification criterion.
    We proposed to adopt two new IGs from the Health eDecisions (HeD) 
S&I Framework initiative that support shareable CDS. The first IG 
defines requirements for the contents of ``CDS Knowledge Artifacts'' 
\28\ for event condition action rules, order sets, and documentation 
templates (HL7 Implementation Guide: Clinical Decision Support 
Knowledge Artifact Implementation Guide, Release 1 (January 2013) 
(``HeD standard'')). In addition to proposing to adopt this IG, we 
proposed to require EHR technology be able to electronically process a 
CDS artifact in the HeD standard. The second IG defines SOAP and REST 
web interface requirements needed to send patient data and receive CDS 
guidance when a request for clinical guidance is made to a CDS guidance 
supplier (HL7 Decision Support Service Implementation Guide, Release 1, 
Version 1 (December 2013)). We also proposed to require that EHR 
technology demonstrate the ability to make an information request, send 
patient data, and receive CDS guidance according to the interface 
requirements defined in the Decision Support Service IG.
---------------------------------------------------------------------------

    \28\ A CDS Knowledge Artifact is the encoding of structured CDS 
content as a rule to support clinical decision making in many areas 
of the health care system, including quality and utilization 
measures, disease outbreaks, comparative effectiveness analysis, 
efficacy of drug treatments, and monitoring health trends.
---------------------------------------------------------------------------

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

[[Page 54453]]

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

[[Page 54454]]

the period of July 1, 2014 through February 28, 2015, and to retire 
version 1.0 and adopt version 3.0 as the official Part D e-Prescribing 
standard on March 1, 2015 (78 FR 74787-74789).\29\ As such, we stated 
in the proposed rule that it was an opportune time to solicit comment 
on whether to adopt a particular standard for the drug-formulary checks 
criterion.
---------------------------------------------------------------------------

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

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

    \30\ V.4.0 has minor changes compared to v.3.0, including 
removal of values from an unused diagnosis code, typographical 
changes, and a change to the standard length of the name field. CMS 
has adopted v.3.0 (77 FR 74787-74789), which includes substantive 
changes from previous versions.
    \31\ The HITSC has discussed these potential limitations. Please 
refer to Clinical Operations Workgroup Update to the HITSC on June 
19, 2013. http://www.healthit.gov/FACAS/sites/faca/files/clinical_operations_wg_update_062013_0.pdf
---------------------------------------------------------------------------

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

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

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

[[Page 54455]]

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

[[Page 54456]]

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

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

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

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

    We requested comment on whether we should adopt a different 
approach related to the methods EHR technology uses to electronically 
identify patient-specific education resources for the proposed 
certification criterion, a potential future ``patient-specific 
education resources'' certification criterion, or both. The 2014 
Edition and proposed certification criterion require EHR technology to 
demonstrate the capability to electronically identify for a user 
patient-specific education resources using Infobutton and an 
alternative method. We sought comment on whether we should: (1) 
Maintain this approach; (2) require EHR technology to demonstrate only 
the use of Infobutton, but permit EHR technology to be certified to 
other methods upon an EHR technology developer's request for the 
purpose of an EP, EH, or CAH being able to use the alternative 
certified method for MU (to count such use toward meeting the measure); 
or (3) certify only the use of Infobutton and consult with CMS 
regarding a meaningful use policy change that would permit the use of 
any method (certified or not) to electronically identify patient-
specific education resources, provided that the EP, EH, or CAH has EHR 
technology certified to perform the Infobutton capability.
    We also sought comment on whether we should require that EHR 
technology be capable of providing patient-specific education resources 
in a patient's preferred language in the proposed certification 
criterion, in a potential future certification criterion, or in both.
    Comments. We received comments supporting removal of the laboratory 
values/results data element, adoption of the updated SOA IG, and the 
proposed clarifying regulation text. We received comments supporting 
both options (1) and (3) related to the methods EHR technology must 
demonstrate for providing patient-specific education resources. Most 
commenters preferred option (3). No commenters expressed support for 
option (2). Consumer and patient advocacy groups supported providing 
patient-specific education resources in a patient's preferred language, 
while EHR technology developers did not support this proposal due to 
the burden they stated it would create because of the great number of 
potential languages and the lack of content resources for all potential 
languages. These commenters also noted that burden would far exceed the 
benefits (e.g., the number of patients requesting patient-specific 
education resources in a preferred language).
    Response. We have not adopted this certification criterion because 
we have not adopted the Proposed Voluntary Edition. Rather, we have 
only adopted a small subset of the proposed certification criteria as 
optional 2014 Edition EHR certification criteria and made revisions to 
2014 Edition EHR certification criteria that provide flexibility, 
clarity, and enhance health information exchange. We will consider the 
comments on the specific proposed changes to the certification 
criterion as well as the comments on the methods EHR technology must 
demonstrate for providing patient-specific education resources and the 
use of preferred language in providing those resources for future 
rulemaking concerning a ``patient-specific education resources'' 
certification criterion.
Electronic Medication Administration Record
    We proposed an ``electronic medication administration record'' 
(eMAR) certification criterion for the Proposed Voluntary Edition that 
was unchanged as compared to the 2014 Edition certification criterion. 
We did not request any specific public comments on this certification 
criterion.
    Comments. The majority of commenters supported an unchanged 
criterion. One commenter suggested removing this criterion in future 
editions because the market drove availability and adoption of this 
functionality before it was introduced in the 2014 Edition. This 
commenter also opined that the functionality could be

[[Page 54457]]

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

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

    In our proposal, we explained our belief that EHR technology will 
play a key role in the widespread adoption and utilization of UDIs and 
that EHRs' use of UDIs can help reduce device-related medical errors 
and provide other significant patient safety, health care quality, and 
public health benefits. For example, EHR technology could be leveraged 
in conjunction with automated identification and data capture (AIDC) 
technology or other technologies to streamline the capture and exchange 
of UDIs and associated device data in clinical and administrative 
workflows. We also noted that patients' UDI data in EHR technology 
could pave the way for new CDS and help health care providers more 
rapidly and accurately identify a patient's devices and key information 
about the safe and effective use of such devices.
    As part of our proposal, we recognized that additional standards 
and technical specifications would be required to support the full 
range of contemplated capabilities and uses, and that efforts to 
identify or develop these standards are already underway. Nevertheless, 
we stated our belief that specifying some baseline functionality as 
part of a certification criterion would be important in order for EHR 
technology developers to consider the functionality necessary to 
capture, store, and retrieve UDIs and other contextually relevant 
information associated with a patient's medical devices, specifically 
implantable devices.
    Our proposal focused on a certification criterion that would assess 
an EHR technology's ability to record UDI information about implantable 
devices. More specifically, we proposed that EHR technology would have 
to show that it could enable a user to electronically record the UDI of 
an implantable device and other relevant information (such as a 
procedure note or additional information about the device) as part of a 
patient's ``implantable device list.'' We also proposed that EHR 
technology would need to allow a user to electronically access and view 
a patient's list of UDIs and other relevant information associated with 
a patient's implantable devices. Our last proposal focused on an EHR 
technology's ability to parse the UDI in order to extract and allow a 
user to view the ``device

[[Page 54458]]

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

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

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

[[Page 54459]]

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

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

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

[[Page 54460]]

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

    \39\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=279.
---------------------------------------------------------------------------

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

    \40\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=279.
---------------------------------------------------------------------------

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

[[Page 54461]]

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

[[Page 54462]]

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

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

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

[[Page 54463]]

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

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

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

[[Page 54464]]

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

[[Page 54465]]

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

[[Page 54466]]

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

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

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

[[Page 54467]]

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

[[Page 54468]]

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

    \44\ Standard. HL7 Clinical Document Architecture (CDA), Release 
2.0, Normative Edition (incorporated by reference in Sec.  170.299). 
Implementation specifications. Implementation Guide for Ambulatory 
Healthcare Provider Reporting to Central Cancer Registries, HL7 
Clinical Document Architecture (CDA), Release 1.0 (incorporated by 
reference in Sec.  170.299).
---------------------------------------------------------------------------

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

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

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

[[Page 54469]]

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

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

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

[[Page 54470]]

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

    \47\ http://www.healthit.gov/sites/default/files/fdasia_healthitreport_final.pdf.
---------------------------------------------------------------------------

Non-Percentage-Based Measures Report
    We proposed a new ``non-percentage-based measures report'' 
certification criterion for the Proposed Voluntary Edition. 
Specifically, we proposed to adopt a new certification criterion that 
would apply to EHR technology presented for certification that includes 
certain ``non-percentage-based capabilities'' (i.e., capabilities that 
support MU objectives for which the corresponding MU measure is not 
percentage-based). In the 2014 Edition NPRM (77 FR 13842), we proposed 
a certification criterion for ``non-percentage-based measure use 
report,'' but subsequently did not adopt the criterion in the 2014 
Edition Final Rule based on commenters' concerns that additional 
specificity would be needed to make the proposed criterion more 
effective. In the Proposed Rule, we stated that we continue to believe 
that EPs, EHs and CAHs could benefit from EHR technology that could 
electronically report non-percentage-based MU objectives and measures, 
and we have also received feedback from OIG and comments in response to 
a MU Stage 3 Request For Comment \48\ echoing this need.
---------------------------------------------------------------------------

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

    Therefore, we proposed a new criterion that is more specific than 
the one proposed in the 2014 Edition NPRM and recognizes that certain 
aspects of ``use'' associated with non-percentage-based measures will 
occur in different ways based on the particular EHR capability 
involved. The proposed certification criterion would require that an 
EHR technology presented for certification be capable of electronically 
generating a report that shows a user had used (or interacted with) the 
EHR technology capability associated with a non-percentage-based MU 
measure during an EHR reporting period. This means that, at a minimum, 
the EHR technology would need to be capable of determining an EHR 
reporting period (date range) and be able to record some evidence of 
use (e.g., transaction, user action, intervention/reminder) during the 
reporting period. We requested public comment on whether we should make 
the regulatory text for this certification criterion more specific or 
if we should maintain the word ``evidence'' and use this final rule's 
preamble to provide more examples of what evidence would be acceptable. 
If we were to make the regulatory text more specific, we proposed two 
options, but also solicited comment on other potential language that 
would make satisfying this criterion clearer.
     Option 1: Require the EHR technology to record evidence of 
use each time a particular capability was used during the reporting 
period.
     Option 2: Require the EHR technology to record evidence of 
use at the beginning, during, and end of the reporting period.
    We believe the proposed criterion provides EHR technology 
developers with substantial flexibility to create innovative approaches 
to document evidence of use. The proposed criterion would apply to only 
those non-percentage-based measures for which this pertinent 
information would be available to the EHR technology based on the 
nature of the capabilities and the ways in which a user could be 
expected to interact with them. To illustrate which certification 
criteria support one or more non-percentage-based measures, we provided 
a table (79 FR 10912) in the Proposed Rule. As described in the 
Proposed Rule, we also proposed not to include the proposed ``drug-
formulary checks'' and ToC certification criteria within the scope of 
this criterion because the corresponding MU measures already provide 
evidence of use. We also proposed that all the proposed privacy and 
security certification criteria of the Proposed Voluntary Edition 
should not be included within the scope of this certification criterion 
because EHR technology would not be able to capture that a security 
risk analysis was performed by an EP, EH, or CAH except through a 
manual entry by the EP, EH, or CAH affirming the completion of the risk 
analysis.
    Consistent with the way in which we have previously implemented 
certification policy that more generally applies to EHR technology, an 
ONC-ACB would need to have new certification responsibilities if we 
were to adopt this proposed criterion. As a result, we also proposed to 
revise Sec.  170.550. This proposed revision would ensure that EHR 
Modules presented for certification to certification criteria that 
support MU objectives with a non-percentage-based measure are certified 
to this proposed certification criterion.
    Comments. We received mixed comments regarding the proposal to 
adopt a new certification criterion to generate reports for non-
percentage-based EHR capabilities. Some commenters supported the new 
criterion for all of the seven certification criteria we presented in 
the table (79 FR 10912).\49\ However, some commenters stated that this 
requirement would only be feasible or preferable for a subset of the 
proposed certification criteria. One commenter opined that this 
functionality was feasible for drug-drug, drug-allergy interaction 
checks and CDS, but for the rest of the certification criteria, it 
would be difficult to build this functionality on a user-level. Another 
commenter recommended adopting this functionality only to support CDS. 
One commenter recommended the requirement be that EHRs be able to 
perform this function for three out of the six proposed certification 
criteria to lessen the administrative burden.
---------------------------------------------------------------------------

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

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

[[Page 54471]]

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

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

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

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

B. 2014 Edition and Proposed Voluntary Edition Equivalency Table

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

C. HIT Definitions

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

[[Page 54472]]

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

C. ONC HIT Certification Program

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

[[Page 54473]]

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

    \51\ http://www.healthit.gov/sites/default/files/generalcertexchangeguidance_final_9-9-13.pdf.
---------------------------------------------------------------------------

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

    \52\ http://www.healthit.gov/sites/default/files/generalcertexchangeguidance_final_9-9-13.pdf.
---------------------------------------------------------------------------

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

[[Page 54474]]

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

V. Comments Beyond the Scope of This Final Rule

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

VI. Collection of Information Requirements

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

VII. Regulatory Impact Statement

A. Statement of Need

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

B. Overall Impact

    We have examined the impact of this final rule as required by EO 
12866 on Regulatory Planning and Review (September 30, 1993), EO 13563 
on Improving Regulation and Regulatory Review (February 2, 2011), the 
Regulatory Flexibility Act (5 U.S.C. 601 et seq.), section 202 of the 
Unfunded Mandates Reform Act of 1995 (2 U.S.C. 1532), and EO 13132 on 
Federalism (August 4, 1999).
1. Executive Orders 12866 and 13563--Regulatory Planning and Review 
Analysis
    EOs 12866 and 13563 direct agencies to assess all costs and 
benefits of available regulatory alternatives and, if regulation is 
necessary, to select regulatory approaches that maximize net benefits 
(including potential economic, environmental, public health and safety 
effects, distributive impacts, and equity). A regulatory impact 
analysis (RIA) must be prepared for major rules with economically 
significant effects ($100 million or more in any 1 year). We have 
determined that this final rule is not an economically significant 
rule. Related costs to prepare EHR technology and other HIT to be 
tested and certified are estimated to be far less than $100 million per 
year. Nevertheless, because of the public interest in this final rule, 
we have prepared an RIA that to the best of our ability presents the 
costs and benefits of this final rule.
a. Costs
    This final rule adopts new optional certification criteria and 
revised certification criteria as part of the 2014 Edition. Our 
analysis focuses on the direct effects of the provisions of this final 
rule--the costs incurred by EHR technology developers to develop and 
prepare EHR technology to be tested and certified in accordance with 
the certification criteria (and the standards and implementation 
specifications they include) adopted by the Secretary. That is, we 
focus on the technological development and preparation costs necessary 
for EHR technology already certified to the 2014 Edition to certify to 
the new optional certification criteria and revised certification 
criteria and for developing new EHR technology to meet the new optional 
certification criteria and revised certification criteria. The costs 
for testing and certification of EHR technologies to the certification 
criteria adopted in this final rule were captured in the RIA of the 
Permanent Certification Program final rule as we discuss in more detail 
below (VI.B.1.a.ii ``Testing and Certification Costs for the 2014 
Edition Release 2''). The costs that EPs, EHs, and CAHs will incur in 
adopting and implementing EHR technology certified to the certification 
criteria adopted in this final rule are not within the scope of this 
final rule.
i. Development and Preparation Costs for the 2014 Edition Release 2
    In the Proposed Rule (79 FR 10932-36), we estimated the development 
and preparation costs for the Proposed Voluntary Edition. We 
categorized proposed certification criteria based on their gap 
certification status (i.e., new, revised, and unchanged). We used the 
total number of unique \53\ 2011 Edition Complete EHRs and EHR Modules 
that were used for MU Stage 1 attestation as reported at the end of FY 
2013.\54\ Using the unique number of 2011 Edition EHR technologies used 
for MU Stage 1 attestation we established a range of between 20% and 
40% of unique EHR technologies used for MU Stage 1 that we believed 
would be developed and prepared to meet each of the certification 
criteria of the Proposed Voluntary Edition. This range accounted for 
potential new entrants to the market as well as those EHR technologies 
used for MU Stage 1 attestation that may no longer be brought forth for 
certification because of such factors as corporate re-organizations 
(e.g., mergers and acquisitions) as well as the loss of market share 
for some EHR technologies. The range also took into account any 
potential non-MU-focused EHR technologies that will be developed and 
prepared to meet the Proposed Voluntary Edition, but not designed for 
MU purposes. We identified three levels of effort to associate with the 
development and preparation of EHR technology to meet the requirements 
of the Proposed Voluntary Edition.\55\ We based the effort levels on 
the hours necessary for a software developer to develop and prepare the 
EHR technology for testing and certification and calculated the average 
software developer's wage with benefits at $61 per hour.\56\ We 
calculated a low cost estimate, high cost estimate, and average cost 
estimate for each proposed certification criterion and then estimated 
the totals equally split between 2014 and 2015.\57\
---------------------------------------------------------------------------

    \53\ We attempted to discern how many Complete EHRs and EHR 
Modules were used that would not constitute a newer version of the 
same EHR technology.
    \54\ For the Proposed Voluntary Edition certification criteria 
that did not have equivalent 2011 Edition EHR certification 
criteria, we used the unique number for the equivalent 2014 Edition 
EHR certification criteria as identified and used for the 2014 
Edition Final Rule regulatory impact analysis.
    \55\ 79 FR 10932-33.
    \56\ 79 FR 10933.
    \57\ 79 FR 10933-36.
---------------------------------------------------------------------------

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

[[Page 54475]]

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

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

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

[[Page 54476]]

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

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

iii. Testing and Certification Costs for the 2014 Edition Release 2
    In the RIA of the Permanent Certification Program final rule, we 
estimated the costs for testing and certification of EHR technologies 
that would be used for providers to attempt to achieve MU Stages 1-
3.\58\ These costs were based on a two-year rulemaking cycle for the 
CEHRT definition and each MU stage. We believe the costs we attributed 
to testing and certification of EHR technologies in support of MU Stage 
2 in the Permanent Certification Program final rule would encompass the 
actual testing and certification of EHR technologies to both the 2014 
Edition and the certification criteria we have adopted as part of the 
2014 Edition Release 2. This assessment is based on the number of EHR 
technologies currently certified to the 2014 Edition and our 
projections for the number of EHR technology developers that would 
likely have their EHR technologies tested and certified to the optional 
and revised 2014 Edition certification criteria adopted in this final 
rule. Further, we note that the estimated costs in the Permanent 
Certification Program final rule included costs for surveillance of EHR 
technologies and also estimated the costs for testing and certification 
above what we understand are the cost ranges charged by ONC-ACBs today.
---------------------------------------------------------------------------

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

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

[[Page 54477]]

information exchange. Specifically, the separating out of the 
``content'' and ``transport'' capabilities in the optional 2014 Edition 
ToC certification criterion (compared to the 2014 Edition ToC 
certification criteria adopted at Sec.  170.314(b)(1) and (2)) and 
adoption of the Edge Protocol IG is aimed at improving the market 
availability of electronic health information exchange services. The 
new certification flexibilities offered by the optional ``CPOE'' and 
optional ``syndromic surveillance'' certification criteria are designed 
to enhance innovation and offer providers enhanced functionality and 
options for meeting applicable MU measures. The new flexibility in the 
VDT certification criterion is designed to further facilitate the 
exchange of patient health information between provider and patient. 
The optional CIRI criterion is designed to align better with clinical 
workflows and reduce regulatory burden found in certification to the 
current ToC certification criterion at Sec.  170.314(b)(1).
2. Regulatory Flexibility Act (RFA)
    The RFA requires agencies to analyze options for regulatory relief 
of small businesses if a rule has a significant impact on a substantial 
number of small entities.
    The Small Business Administration (SBA) establishes the size of 
small businesses for federal government programs based on average 
annual receipts or the average employment of a firm. While EHR 
technology developers that pursue certification under the ONC HIT 
Certification Program represent a small segment of the overall 
information technology industry, we believe that the entities impacted 
by this final rule most likely fall under the North American Industry 
Classification System (NAICS) code 541511 ``Custom Computer Programming 
Services'' specified at 13 CFR 121.201 where the SBA publishes ``Small 
Business Size Standards by NAICS Industry.'' The SBA size standard 
associated with this NAICS code is set at $25 million in annual 
receipts \59\ which ``indicates the maximum allowed for a concern and 
its affiliates to be considered small entities.''
---------------------------------------------------------------------------

    \59\ The SBA references that annual receipts means ``total 
income'' (or in the case of a sole proprietorship, ``gross income'') 
plus ``cost of goods sold'' as these terms are defined and reported 
on Internal Revenue Service tax return forms. http://www.sba.gov/sites/default/files/files/Size_Standards_Table.pdf.
---------------------------------------------------------------------------

    Based on our analysis, we believe that there is enough data 
generally available to establish that between 75% and 90% of entities 
that are categorized under the NAICS code 541511 are under the SBA size 
standard, but note that the available data does not show how many of 
these entities will develop a EHR product that will be certified to the 
optional 2014 Edition Release 2 certification criteria under the ONC 
HIT Certification Program. We also note that with the exception of 
aggregate business information available through the U.S. Census Bureau 
and the SBA related to NAICS code 541511, it appears that many EHR 
technology developers that pursue certification under the ONC HIT 
Certification Program are privately held or owned and do not regularly, 
if at all, make their specific annual receipts publicly available. As a 
result, it is difficult to locate empirical data related to many of 
these EHR technology developers to correlate to the SBA size standard. 
However, although not correlated to the size standard for NAICS code 
541511, we do have information indicating that over 60% of EHR 
technology developers that have had Complete EHRs and/or EHR Modules 
certified to the 2011 Edition EHR certification criteria have less than 
51 employees.
    We estimate that this final rule would have effects on EHR 
technology developers that are likely to pursue certification under the 
ONC HIT Certification Program, some of which may be small entities. 
However, we believe that we have proposed the minimum amount of 
requirements necessary to accomplish our policy goals, including a 
reduction in regulatory burden and additional flexibility for the 
regulated community, and that no additional appropriate regulatory 
alternatives could be developed to lessen the compliance burden 
associated with this final rule. We note that this final rule does not 
impose the costs cited in the RIA as compliance costs, but rather as 
investments which these EHR technology developers voluntarily take on 
and expect to recover with an appropriate rate of return. Accordingly, 
we do not find that this final rule will create a significant impact on 
a substantial number of small entities. Additionally, the Secretary 
certifies that this final rule will not have a significant impact on a 
substantial number of small entities.
3. Executive Order 13132--Federalism
    Executive Order 13132 establishes certain requirements that an 
agency must meet when it promulgates a proposed rule (and subsequent 
final rule) that imposes substantial direct requirement costs on state 
and local governments, preempts state law, or otherwise has federalism 
implications. Nothing in this final rule imposes substantial direct 
compliance costs on state and local governments, preempts state law or 
otherwise has federalism implications. We are not aware of any state 
laws or regulations that are contradicted or impeded by any of the 
certification criteria or other proposals we have adopted in this final 
rule.
4. Unfunded Mandates Reform Act of 1995
    Section 202 of the Unfunded Mandates Reform Act of 1995 requires 
that agencies assess anticipated costs and benefits before issuing any 
rule whose mandates require spending in any one year of $100 million in 
1995 dollars, updated annually for inflation. The current inflation-
adjusted statutory threshold is approximately $141 million. This final 
rule will not impose an unfunded mandate on state, local, and tribal 
governments or on the private sector that will reach the threshold 
level.

Regulation Text

List of Subjects in 45 CFR Part 170

    Computer technology, Electronic health record, Electronic 
information system, Electronic transactions, Health, Health care, 
Health information technology, Health insurance, Health records, 
Hospitals, Incorporation by reference, Laboratories, Medicaid, 
Medicare, Privacy, Reporting and recordkeeping requirements, Public 
health, Security.

    For the reasons set forth in the preamble, 45 CFR subtitle A, 
subchapter D, part 170, is amended as follows:

PART 170--HEALTH INFORMATION TECHNOLOGY STANDARDS, IMPLEMENTATION 
SPECIFICATIONS, AND CERTIFICATION CRITERIA AND CERTIFICATION 
PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY

0
1. The authority citation for part 170 continues to read as follows:

    Authority:  42 U.S.C. 300jj-11; 42 U.S.C. 300jj-14; 5 U.S.C. 
552.


0
2. Section 170.102 is amended by revising the definition for ``Base 
EHR'' to read as follows:


Sec.  170.102  Definitions.

* * * * *
    Base EHR means an electronic record of health-related information 
on an individual that:
    (1) Includes patient demographic and clinical health information, 
such as medical history and problem lists;

[[Page 54478]]

    (2) Has the capacity:
    (i) To provide clinical decision support;
    (ii) To support physician order entry;
    (iii) To capture and query information relevant to health care 
quality;
    (iv) To exchange electronic health information with, and integrate 
such information from other sources;
    (v) To protect the confidentiality, integrity, and availability of 
health information stored and exchanged; and
    (3) Has been certified to the certification criteria adopted by the 
Secretary:
    (i) For at least one of the four criteria adopted at Sec.  
170.314(a)(1), (a)(18), (a)(19), or (a)(20);
    (ii) At Sec.  170.314(a)(3);
    (iii) At Sec.  170.314(a)(5) through Sec.  170.314(a)(8);
    (iv) Both Sec.  170.314(b)(1) and (2); or, both Sec.  170.314(b)(8) 
and Sec.  170.314(h)(1); or Sec.  170.314(b)(1) and (2) combined with 
either Sec.  170.314(b)(8) or Sec.  170.314(h)(1), or both Sec.  
170.314(b)(8) and Sec.  170.314(h)(1);
    (v) At Sec.  170.314(b)(7);
    (vi) At Sec.  170.314(c)(1) through Sec.  170.314(c)(3);
    (vii) At Sec.  170.314(d)(1) through Sec.  170.314(d)(8);
    (4) Has been certified to the certification criteria at Sec.  
170.314(c)(1) and (2):
    (i) For no fewer than 9 clinical quality measures covering at least 
3 domains from the set selected by CMS for eligible professionals, 
including at least 6 clinical quality measures from the recommended 
core set identified by CMS; or
    (ii) For no fewer than 16 clinical quality measures covering at 
least 3 domains from the set selected by CMS for eligible hospitals and 
critical access hospitals.
* * * * *


Sec.  170.102  [Amended]

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


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


Sec.  170.202  Transport standards.

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

Sec.  170.205  [Amended]

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


Sec.  170.207  [Amended]

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


Sec.  170.210  [Amended]

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

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


Sec.  170.299  Incorporation by reference.

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


Sec.  170.302  [Removed and Reserved]

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


Sec.  170.304  [Removed and Reserved]

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


Sec.  170.306  [Removed and Reserved]

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

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


Sec.  170.314  2014 Edition electronic health record certification 
criteria.

* * * * *
    (a) * * *
    (1) * * *
    (iii) Diagnostic imaging.
* * * * *
    (18) Optional--computerized provider order entry--medications. 
Enable a user to electronically record, change, and access medication 
orders.
    (19) Optional--computerized provider order entry--laboratory. 
Enable a user to electronically record, change, and access laboratory 
orders.
    (20) Optional--computerized provider order entry--diagnostic 
imaging. Enable a user to electronically record, change, and access 
diagnostic imaging orders.
    (b) * * *
    (8) Optional--Transitions of care. (i) Send and receive via edge 
protocol. EHR technology must be able to electronically:
    (A) Send transitions of care/referral summaries through a method 
that conforms to the standard specified at Sec.  170.202(d) and that 
leads to such summaries being processed by a service that has 
implemented the standard specified in Sec.  170.202(a); and
    (B) Receive transitions of care/referral summaries through a method 
that conforms to the standard specified at Sec.  170.202(d) from a 
service that has implemented the standard specified in Sec.  
170.202(a).
    (ii)(A) Display. EHR technology must be able to electronically 
display in human readable format the data included in transition of 
care/referral summaries received and formatted according to any of the 
following standards (and applicable implementation specifications) 
specified in: Sec.  170.205(a)(1) through (3).
    (B) Section views. Extract and allow for individual display each 
additional section or sections (and the accompanying document header 
information) that were included in a transition of care/referral 
summary received and formatted in accordance with the standard adopted 
at Sec.  170.205(a)(3).
    (iii) Create. Enable a user to electronically create a transition 
of care/referral summary formatted according to the standard adopted at 
Sec.  170.205(a)(3) that includes, at a minimum, the Common MU Data Set 
and the following data expressed, where applicable, according to the 
specified standard(s):
    (A) Encounter diagnoses. The standard specified in Sec.  170.207(i) 
or, at a minimum, the version of the standard specified Sec.  
170.207(a)(3);
    (B) Immunizations. The standard specified in Sec.  170.207(e)(2);
    (C) Cognitive status;
    (D) Functional status;
    (E) Ambulatory setting only. The reason for referral; and referring 
or transitioning provider's name and office contact information; and
    (F) Inpatient setting only. Discharge instructions.
    (9) Optional--clinical information reconciliation and 
incorporation--(i) Correct patient. Upon receipt of a transition of 
care/referral summary formatted according to the standard adopted at 
Sec.  170.205(a)(3), EHR technology must be able to demonstrate that 
the transition of care/referral summary received is or can be properly 
matched to the correct patient.

[[Page 54479]]

    (ii) Reconciliation. Enable a user to electronically reconcile the 
data that represent a patient's active medication, problem, and 
medication allergy list as follows. For each list type:
    (A) Electronically and simultaneously display (i.e., in a single 
view) the data from at least two list sources in a manner that allows a 
user to view the data and their attributes, which must include, at a 
minimum, the source and last modification date;
    (B) Enable a user to create a single reconciled list of 
medications, medication allergies, or problems;
    (C) Enable a user to review and validate the accuracy of a final 
set of data; and
    (D) Upon a user's confirmation, automatically update the list, and 
electronically incorporate the following data expressed according to 
the specified standard(s):
    (1) Medications. At a minimum, the version of the standard 
specified in Sec.  170.207(d)(2);
    (2) Problems. At a minimum, the version of the standard specified 
in Sec.  170.207(a)(3);
    (3) Medication allergies. At a minimum, the version of the standard 
specified in Sec.  170.207(d)(2).
* * * * *
    (e) * * *
    (1) * * *
    (i) * * *
    (C) * * *
    (1) Electronically transmit the ambulatory summary or inpatient 
summary (as applicable to the EHR technology setting for which 
certification is requested) created in paragraph (e)(1)(i)(B)(1) of 
this section in accordance with at least one of the following:
    (i) The standard specified in Sec.  170.202(a).
    (ii) Through a method that conforms to the standard specified at 
Sec.  170.202(d) and that leads to such summary being processed by a 
service that has implemented the standard specified in Sec.  
170.202(a).
    (2) Inpatient setting only. Electronically transmit transition of 
care/referral summaries (as a result of a transition of care/referral) 
selected by the patient (or their authorized representative) in 
accordance with at least one of the following:
    (i) The standard specified in Sec.  170.202(a).
    (ii) Through a method that conforms to the standard specified at 
Sec.  170.202(d) and that leads to such summary being processed by a 
service that has implemented the standard specified in Sec.  
170.202(a).
* * * * *
    (f) * * *
    (7) Optional--Ambulatory setting only--Transmission to public 
health agencies--syndromic surveillance. EHR technology must be able to 
electronically create syndrome-based public health surveillance 
information for electronic transmission.
    (i) Optional. That contains the following data:
    (A) Patient demographics;
    (B) Provider specialty;
    (C) Provider address;
    (D) Problem list;
    (E) Vital signs;
    (F) Laboratory test values/results;
    (G) Procedures;
    (H) Medication list; and
    (I) Insurance.
    (ii) [Reserved]
    (g) * * *
    (1) Optional--Automated numerator recording. For each meaningful 
use objective with a percentage-based measure, EHR technology must be 
able to create a report or file that enables a user to review the 
patients or actions that would make the patient or action eligible to 
be included in the measure's numerator. The information in the report 
or file created must be of sufficient detail such that it enables a 
user to match those patients or actions to meet the measure's 
denominator limitations when necessary to generate an accurate 
percentage.
* * * * *
    (3) Safety-enhanced design. User-centered design processes must be 
applied to each capability an EHR technology includes that is specified 
in the following certification criteria: Sec.  170.314(a)(1), (2), (6) 
through (8), (16) and (18) through (20) and (b)(3), (4), and (9).
* * * * *
    (h) Transport methods--(1) Optional--Applicability Statement for 
Secure Health Transport. Enable health information to be electronically 
sent and electronically received in accordance with the standard 
specified in Sec.  170.202(a).
    (2) Optional--Applicability Statement for Secure Health Transport 
and XDR/XDM for Direct Messaging. Enable health information to be 
electronically sent and electronically received in accordance with the 
standards specified in Sec.  170.202(a) and (b).
    (3) Optional--SOAP Transport and Security Specification and XDR/XDM 
for Direct Messaging. Enable health information to be electronically 
sent and electronically received in accordance with the standards 
specified in Sec.  170.202(b) and (c).

Subpart D--[Removed and Reserved]

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

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


Sec.  170.501  Applicability.

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

0
15. Section 170.503 is amended by revising paragraphs (b)(1) and (e)(1) 
and (2) to read as follows:


Sec.  170.503  Requests for ONC-AA status and ONC-AA ongoing 
responsibilities.

* * * * *
    (b) * * *
    (1) A detailed description of the accreditation organization's 
conformance to ISO/IEC17011 (incorporated by reference in Sec.  
170.599) and experience evaluating the conformance of certification 
bodies to ISO/IEC 17065 (incorporated by reference in Sec.  170.599).
* * * * *
    (e) * * *
    (1) Maintain conformance with ISO/IEC 17011 (incorporated by 
reference in Sec.  170.599);
    (2) Verify that the certification bodies it accredits and ONC-ACBs 
conform to, at a minimum:
    (i) For fiscal years 2014 and 2015, ISO/IEC Guide 65 (incorporated 
by reference in Sec.  170.599); and
    (ii) For fiscal year 2016 and subsequent years, ISO/IEC 17065 
(incorporated by reference in Sec.  170.599).
* * * * *

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


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

* * * * *
    (l) Display the ONC Certified HIT Certification and Design Mark on 
all certifications issued under the ONC HIT Certification Program in a 
manner that complies with the Criteria and Terms of Use for the ONC 
Certified HIT Certification and Design Mark, and ensure that use of the 
mark by HIT developers whose products are certified under the ONC HIT 
Certification Program is compliant with the Criteria

[[Page 54480]]

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

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


Sec.  170.550  EHR Module certification.

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


Sec.  170.550  [Amended]

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

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


Sec.  170.599  Incorporation by reference.

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

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