[Federal Register Volume 79, Number 38 (Wednesday, February 26, 2014)]
[Proposed Rules]
[Pages 10879-10946]
From the Federal Register Online via the Government Printing Office [www.gpo.gov]
[FR Doc No: 2014-03959]



[[Page 10879]]

Vol. 79

Wednesday,

No. 38

February 26, 2014

Part II





Department of Health and Human Services





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





45 CFR Part 170





Voluntary 2015 Edition Electronic Health Record (EHR) Certification 
Criteria; Interoperability Updates and Regulatory Improvements; 
Proposed Rule

Federal Register / Vol. 79 , No. 38 / Wednesday, February 26, 2014 / 
Proposed Rules

[[Page 10880]]


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

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Office of the Secretary

45 CFR Part 170

RIN 0991-AB92


Voluntary 2015 Edition Electronic Health Record (EHR) 
Certification Criteria; Interoperability Updates and Regulatory 
Improvements

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

ACTION: Notice of proposed rulemaking with comment period.

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

SUMMARY: This notice of proposed rulemaking introduces the beginning of 
the Office of National Coordinator for Health Information Technology's 
(ONC's) more frequent approach to health information technology 
certification regulations. Under this approach ONC intends to update 
certification criteria editions every 12 to 18 months in order to 
provide smaller, more incremental regulatory changes and policy 
proposals. This approach gives stakeholders greater and earlier 
visibility into our regulatory direction before compliance is required, 
provides more time for public input on policy proposals under 
consideration for future rulemakings, and enables our certification 
processes to more quickly adopt newer industry standards that can 
enhance interoperability.
    The 2015 Edition EHR certification criteria proposed in this rule 
would be voluntary. No EHR technology developer who has certified its 
EHR technology to the 2014 Edition would need to recertify to the 2015 
Edition in order for its customers to participate in the Medicare and 
Medicaid EHR Incentive Programs (EHR Incentive Programs). Furthermore, 
eligible professionals, eligible hospitals, and critical access 
hospitals that participate in the EHR Incentive Programs would not need 
to ``upgrade'' to EHR technology certified to 2015 Edition in order to 
have EHR technology that meets the Certified EHR Technology (CEHRT) 
definition. Instead, the 2015 Edition EHR certification criteria would 
accomplish three policy objectives: 1) They would enable a more 
efficient and effective response to stakeholder feedback; 2) they would 
incorporate ``bug fixes'' to improve on 2014 Edition EHR certification 
criteria in ways designed to make our rules clearer and easier to 
implement; and 3) they reference newer standards and implementation 
specifications that reflect our commitment to promoting innovation and 
enhancing interoperability.
    Specific revisions to the ONC HIT Certification Program are also 
included in this proposed rule. These proposals focus on: Improving 
regulatory clarity; simplifying the certification of EHR Modules that 
are designed for purposes other than achieving meaningful use; and 
discontinuing the use of the Complete EHR definition starting with the 
2015 Edition.

DATES: To be assured consideration, written or electronic comments must 
be received at one of the addresses provided below, no later than 5 
p.m. on April 28, 2014.

ADDRESSES: You may submit comments, identified by RIN 0991-AB92, by any 
of the following methods (please do not submit duplicate comments). 
Because of staff and resource limitations, we cannot accept comments by 
facsimile (FAX) transmission.
     Federal eRulemaking Portal: Follow the instructions for 
submitting comments. Attachments should be in Microsoft Word, Microsoft 
Excel, or Adobe PDF; however, we prefer Microsoft Word. http://www.regulations.gov.
     Regular, Express, or Overnight Mail: Department of Health 
and Human Services, Office of the National Coordinator for Health 
Information Technology, Attention: 2015 Edition EHR Standards and 
Certification Criteria Proposed Rule, Hubert H. Humphrey Building, 
Suite 729D, 200 Independence Ave. SW., Washington, DC 20201. Please 
submit one original and two copies.
     Hand Delivery or Courier: Office of the National 
Coordinator for Health Information Technology, Attention: 2015 Edition 
EHR Standards and Certification Criteria Proposed Rule, Hubert H. 
Humphrey Building, Suite 729D, 200 Independence Ave. SW., Washington, 
DC 20201. Please submit one original and two copies. (Because access to 
the interior of the Hubert H. Humphrey Building is not readily 
available to persons without federal government identification, 
commenters are encouraged to leave their comments in the mail drop 
slots located in the main lobby of the building.)
    Enhancing the Public Comment Experience: To enhance the 
accessibility and ease with which the public may comment on this 
proposed rule, a copy will be made available in Microsoft Word format. 
We believe this version will make it easier for commenters to access 
and copy portions of the proposed rule for use in their individual 
comments. Additionally, a separate document will be made available for 
the public to use to provide comments on the proposed rule. This 
document is meant to provide the public with a simple and organized way 
to submit comments on the certification criteria, associated standards 
and implementation specifications, and respond to specific questions 
posed in the preamble of the proposed rule. While use of this document 
is entirely voluntary, we encourage commenters to consider using the 
document in lieu of unstructured comments or to use it as an addendum 
to narrative cover pages. Roughly 30% of the public comments submitted 
to our 2014 Edition notice of proposed rulemaking used the provided 
template, which greatly assisted in our ability to rapidly process and 
more accurately categorize public comments. Because of the technical 
nature of this proposed rule, we believe that use of the document may 
facilitate our review and understanding of the comments received. The 
Microsoft Word version of the proposed rule and the document that can 
be used for providing comments can be found at http://www.regulations.gov as part of this proposed rule's docket and on ONC's 
Web site (http://www.healthit.gov).
    Inspection of Public Comments: All comments received before the 
close of the comment period will be available for public inspection, 
including any personally identifiable or confidential business 
information that is included in a comment. Please do not include 
anything in your comment submission that you do not wish to share with 
the general public. Such information includes, but is not limited to: A 
person's social security number; date of birth; driver's license 
number; state identification number or foreign country equivalent; 
passport number; financial account number; credit or debit card number; 
any personal health information; or any business information that could 
be considered proprietary. We will post all comments that are received 
before the close of the comment period at http://www.regulations.gov.
    Docket: For access to the docket to read background documents or 
comments received, go to http://www.regulations.gov or the Department 
of Health and Human Services, Office of the National Coordinator for 
Health Information Technology, Hubert H. Humphrey Building, Suite 729D, 
200 Independence Ave. SW., Washington, DC 20201 (call ahead to the 
contact listed below to arrange for inspection).

[[Page 10881]]


FOR FURTHER INFORMATION CONTACT: Steven Posnack, Director, Federal 
Policy Division, Office of Policy and Planning, Office of the National 
Coordinator for Health Information Technology, 202-690-7151.

SUPPLEMENTARY INFORMATION:

Commonly Used Acronyms

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

Table of Contents

I. Executive Summary
    A. Purpose of Regulatory Action
    B. Summary of Major Provisions
    1. Overview of the 2015 Edition EHR Certification Criteria
    2. 2017 Edition Rulemaking
    3. ONC HIT Certification Program
II. Background
    A. Statutory Basis
    1. Standards, Implementation Specifications, and Certification 
Criteria
    2. HIT Certification Programs
    B. Regulatory History
    1. Standards, Implementation Specifications, and Certification 
Criteria Rules
    2. Medicare and Medicaid EHR Incentive Programs Rules
    3. ONC HIT Certification Programs Rules
III. Provisions of the Proposed Rule Affecting Standards, 
Implementation Specifications, and Certification Criteria
    A. 2015 Edition EHR Certification Criteria
    B. 2014 Edition to 2015 Edition Equivalency Table
    C. Gap Certification Eligibility Table for 2015 Edition EHR 
Certification Criteria
    D. HIT Definitions
    1. CEHRT and Base EHR Definitions
    2. Complete EHR
    3. Common MU Data Set
    4. Cross-Referenced FDA Definitions
IV. Provisions of the Proposed Rule Affecting the ONC HIT 
Certification Program
    A. Applicability
    B. Non-MU EHR Technology Certification
    C. ONC Regulations FAQ 28
    1. MU EHR Modules
    2. Complete EHRs
    D. Patient List Creation Certification Criteria
    E. ISO/IEC 17065
    F. ONC Certification Mark
    G. ``Certification Packages'' for EHR Modules
V. Other Topics for Consideration for the 2017 Edition Certification 
Criteria Rulemaking
    A. Additional Patient Data Collection
    B. Medication Allergy Coding
    C. Certification Policy for EHR Modules and Privacy and Security 
Certification Criteria
    D. Provider Directories
    E. Oral Liquid Medication Dosing
    F. Medication History
    G. Blue Button +
    H. 2D Barcoding
    I. Duplicate Patient Records
    J. Disaster Preparedness
    K. Certification of Other Types of HIT and for Specific Types of 
Health Care Settings
    1. Other Types of HIT
    2. Specific Types of Health Care Settings
VI. Removal of the 2011 Edition EHR Certification Criteria and 
Related Standards, Terms, and Requirements and the Temporary 
Certification Program
    A. 2011 Edition EHR Certification Criteria
    B. Temporary Certification Program
VII. Response to Comments
VIII. Collection of Information Requirements
IX. Regulatory Impact Statement
    A. Statement of Need
    B. Overall Impact
    1. Executive Orders 12866 and 13563--Regulatory Planning and 
Review Analysis
    2. Regulatory Flexibility Act
    3. Executive Order 13132--Federalism
    4. Unfunded Mandates Reform Act of 1995
    C. Request for Comments on 2017 Impact Analysis Methods

I. Executive Summary

A. Purpose of Regulatory Action

    On December 6, 2013, CMS announced its intention \1\ to pursue 
rulemaking to modify the start date of meaningful use (MU) Stage 3 for 
some eligible professionals (EPs), eligible hospitals (EHs), and 
critical access hospitals (CAHs). As part of this announcement, CMS and 
ONC also expressed an expectation that our joint rulemaking processes 
to establish Stage 3 policy and supporting EHR certification criteria 
would result in published proposed rules in late fall 2014. Given the 
new (and later than originally planned) regulatory timeline, we (ONC) 
determined that initiating a more frequent rulemaking approach for the 
adoption of certification criteria would provide an opportunity to 
respond to stakeholder concerns regarding our prior rulemakings. Along 
these lines, we believe a more frequent rulemaking approach would help 
address both the amount of time that it takes to publish updates to our 
certification regulations and the corresponding impact that the 
infrequent, long-cycle approach has had on EHR technology development 
and deployment.
---------------------------------------------------------------------------

    \1\ http://www.cms.gov/eHealth/ListServ_Stage3Implementation.html,
---------------------------------------------------------------------------

    In the past, ONC has issued certification (program and criteria) 
regulations solely to support the EHR Incentive Programs. As a result, 
we have gained five years of process experience and stakeholder 
feedback. We have learned that as health information technology (HIT or 
health IT) continues to evolve, a two to three-year regulatory cycle is 
sub-optimal. Moreover, because these rulemakings have been less 
frequent, our regulations have had to take into account one to two 
years' worth of industry effort prior to the rulemaking and established 
policy that anticipates industry readiness one to two years post-
rulemaking. This approach has created cycles of significant peaks and 
valleys from a health IT development standpoint; resulted in missed 
opportunities to improve interoperability and programmatic alignment 
because of mismatched regulatory and standards balloting cycle 
timelines; and adversely affected EHR technology developers' ability to 
strategically plan their development and product rollout processes due 
to uncertain regulatory timelines.
    To address these challenges, we believe that a more incremental, 
frequent, and scheduled approach to publishing proposed and final rules 
(that is, every 12 to 18 months) would benefit the industry. We 
anticipate, similar to this 2015 Edition rulemaking, that some of these 
incremental rules would be voluntary in an effort to intentionally give 
EHR technology developers more time to plan, develop, and implement 
updated EHR technology for their customers. Overall,

[[Page 10882]]

we believe this approach will enable ONC to:
    (A) Adapt our regulations to more effectively and efficiently 
respond to stakeholder feedback and to support HHS healthcare delivery 
reform and transformation programs that may seek to leverage health IT 
certification;
    (B) Better our regulations by making ``bug fixes'' and other 
regulatory improvements as part of a more frequent rulemaking cycle;
    (C) Chart a course toward enhanced interoperability, information 
exchange, quality improvement, patient engagement, and patient safety 
that gives health IT developers more ability to predict ONC's potential 
next steps; and
    (D) Deliver smaller, incremental regulatory requirements that are 
easier to integrate into software development cycles.
    The 2015 Edition rulemaking begins ONC's new regulatory approach. 
The proposals for the 2015 Edition in this proposed rule improve on the 
2014 Edition EHR certification criteria in numerous ways. Moreover, the 
proposed 2015 Edition EHR certification criteria would be voluntary. In 
other words, no EHR technology developer who has certified its EHR 
technology to the 2014 Edition would need to recertify to the 2015 
Edition in order for its customers to participate in the EHR Incentive 
Programs. Correspondingly, eligible professionals (EPs), eligible 
hospitals (EHs), and critical access hospitals (CAHs) that participate 
in the EHR Incentive Programs would not need to ``upgrade'' to EHR 
technology certified to 2015 Edition in order to have EHR technology 
that meets the Certified EHR Technology definition nor to standards or 
implementation specifications included in the 2015 Edition. As a 
result, EHR technology developers and EPs, EHs, and CAHs would have the 
opportunity to move ahead to the 2015 Edition at their own pace and on 
their own terms. Proposed new capabilities, standards-based 
requirements, and public comment solicitations on potential future 
certification criteria also provide EHR technology developers with 
advance visibility and time to react to the potential requirements ONC 
is considering for our next planned rulemaking--the 2017 Edition 
certification criteria (which would be proposed to support meaningful 
use Stage 3 proposals).
    We believe the benefits of moving to the 2015 Edition for EHR 
technology developers and EPs, EHs, and CAHs would be three-fold:
    (1) The 2015 Edition EHR certification criteria (as proposed) 
include updated capabilities, standards, and implementation guides 
(IGs) designed to enhance interoperability;
    (2) Certain certification criteria changes in the 2015 Edition (as 
compared to the 2014 Edition and discussed in greater detail later) are 
designed to spur innovation, open new market opportunities, and provide 
more choices to EPs, EHs, and CAHs when it comes to electronic health 
information exchange.
    (3) EHR technology developers would be able to implement regulatory 
updates earlier than if we would have otherwise waited another year to 
propose them under the new rulemaking timeline for the 2017 Edition/MU 
Stage 3. Along those lines, EHR technology developers that seek 2015 
Edition certifications for some or all capabilities may be able to seek 
``gap certification'' for those capabilities if they remain unchanged 
as part of the eventual 2017 Edition. Thus, EHR technology developer 
resources and time investments could be more spread out and lead to 
greater efficiency and time saved through the certification process 
later on. We note, however, the availability and scope of gap 
certification for 2015 Edition certified products to the 2017 Edition 
is contingent both on the outcome of the 2017 Edition rulemaking and 
the discretion of ONC-ACBs. For further explanation and discussion of 
gap certification, please see section III.C. ``Gap Certification 
Eligibility Table for 2015 Edition EHR Certification Criteria'' of the 
preamble.

B. Summary of Major Provisions

1. Overview of the 2015 Edition EHR Certification Criteria
    The proposed 2015 Edition EHR certification criteria include many 
improvements over the 2014 Edition EHR certification criteria (note: 
hereafter, all certification criteria editions will simply be referred 
to by the edition year (e.g., 2015 Edition). Yet, they do not entirely 
overhaul the full suite of certification criteria. From a 2014 Edition 
perspective, we are proposing to adopt roughly 60% of the 2014 Edition 
EHR certification criteria without change as part of the 2015 Edition. 
The remaining certification criteria proposals for the 2015 Edition 
generally fall into four general categories:
    (1) Clarifying revisions--consisting of clarifying regulatory text 
revisions. These include updating a certification criterion to reflect 
guidance in an already-issued frequently asked question (FAQ);
    (2) Standards updates--to have a certification criterion reference 
a new standard or IG that has been published since the Standards, 
Implementation Specifications, and Certification Criteria for 
Electronic Health Record Technology, 2014 Edition; Revisions to the 
Permanent Certification Program for Health Information Technology final 
rule (``2014 Edition Final Rule'') was published in September 2012 (77 
FR 54163 Sept. 4, 2012).
    In these instances, we have considered the proposed standards 
consistent with the requirements of the National Technology Transfer 
and Advancement Act (NTTAA) of 1995 (15 U.S.C. 3701 et. seq.) and the 
Office of Management and Budget (OMB) Circular A-119,\2\ to use, 
wherever practical, technical standards that are developed or adopted 
by voluntary consensus standards bodies to carry out policy objectives 
or activities, with certain exceptions. The NTTAA and OMB Circular A-
119 provide exceptions to selecting only standards developed or adopted 
by voluntary consensus standards bodies, namely when doing so would be 
inconsistent with applicable law or otherwise impractical. In this 
proposed rule, we have proposed to adopt or refer to voluntary 
consensus standards, except for the following government-unique 
standards: The OMB Standards for Maintaining, Collecting, and 
Presenting Federal Data on Race and Ethnicity; the transport standards 
proposed in Sec.  170.202; the standard that identifies the data 
elements referenced by clinical quality measures (Sec.  170.204(c)); 
and certain standards related to the protection of electronic health 
information identified in Sec.  170.210. We are aware of no voluntary 
consensus standards that would serve as alternatives to these standards 
for the purposes that we have identified;
---------------------------------------------------------------------------

    \2\ http://www.whitehouse.gov/omb/circulars_a119.
---------------------------------------------------------------------------

    (3) Restructuring--to make the certification criteria clearer and 
to improve market opportunities for diverse stakeholders to get EHR 
technology certified.
    (4) New certification criteria proposals--consisting of a few new 
certification criteria that represent new functionality when compared 
to the 2014 Edition as well as some new certification criteria that are 
the result of splitting certain 2014 Edition certification criteria.

[[Page 10883]]

2. 2017 Edition Rulemaking
    To give the industry advance notice of potential proposals under 
consideration for future certification criteria editions and 
regulations (e.g., 2017 Edition), we solicit public comment on 
revisions we are considering to many existing certification criteria. 
That is, certification criteria that have been adopted as part of the 
2014 Edition and proposed as part of the 2015 Edition. We include a 
separate preamble section that discusses and requests public comments 
on potential functionality and requirements for the 2017 Edition (``V. 
Other Topics for Consideration for the 2017 Edition Certification 
Criteria Rulemaking''). However, please note that although we will 
consider the comments we receive on these issues as we develop 
proposals for future rulemaking, we do not plan to respond to those 
comments in the final rule for the 2015 Edition that we expect will 
follow this proposed rule.
3. ONC HIT Certification Program
    We propose several modifications to the ONC HIT Certification 
Program's policies. We also solicit public comment on several important 
future program policy issues we intend to consider for our 2017 Edition 
rulemaking. We are proposing to simplify the certification of EHR 
Modules that are designed for purposes other than achieving meaningful 
use and to discontinue the ``Complete EHR'' certification concept, 
which would begin with the 2015 Edition. Every additional ONC HIT 
Certification Program proposal we have included focuses on clarifying 
regulatory text, updating existing program polices, and providing 
clarity for the market as it relates to EHR technology certified under 
the program.

C. Costs and Benefits

    Our estimates indicate that this proposed rule is not an 
economically significant rule as its overall costs would be less than 
$100 million in any one year. We have, however, estimated the costs and 
benefits of the proposed rule. The estimated costs expected to be 
incurred by EHR technology developers to develop and prepare EHR 
technology to be tested and certified in accordance with the 2015 
Edition EHR certification criteria (and the standards and 
implementation specifications they include) are represented in monetary 
terms in Table 1 below. Because the 2015 Edition is not the baseline 
certification criteria edition required by the CEHRT definition (as the 
2014 Edition is), and because we expect our next rulemaking to adopt a 
2017 Edition would commence in late calendar year 2014 and conclude in 
2015, we do not believe that a large number of EHR technology 
developers would seek to be tested and certified to the 2015 Edition. 
We estimate that development and preparation efforts to the 2015 
Edition would be split evenly over calendar years 2014 and 2015 and 
would be confined to these years because, as noted, we expect to issue 
a 2017 Edition final rule in 2015 and expect that the majority of EHR 
development and preparation efforts at that time would shift towards 
meeting the 2017 Edition. The dollar amounts expressed in Table 1 are 
expressed in 2014 dollars.
    While we do not expect a majority of EHR technology developers to 
seek testing and certification to the 2015 Edition, it would still 
provide several significant benefits to patients, health care 
providers, and EHR technology developers. Our proposals incorporate 
stakeholder feedback on particular 2014 Edition issues identified as 
unnecessarily impeding innovation. Our proposed revisions also seek to 
continue to improve EHR technology's interoperability through the 
adoption of updated standards and implementation specifications. 
Furthermore, our proposal to separate the ``content'' and ``transport'' 
capabilities in the 2015 Edition ``transitions of care'' certification 
criterion (compared to the 2014 Edition version of that certification 
criterion) is aimed at significantly improving the market availability 
of electronic health information exchange services. Our proposed 2015 
Edition ``view, download, transmit to 3rd party'' certification 
criterion includes a greater focus on enabling a patient to choose 
where they want to send their health information. We believe these 
proposed revisions would open new market opportunities for EPs, EHs, 
and CAHs to select best of breed products as well as reduce EHR 
technology developer burdens related to certification. Our proposals 
and requests for comment in this proposed rule also signal to the 
industry the future direction we hope to go in with our certification 
criteria and certification program. This advanced visibility can better 
assist EHR technology developers plan for the future.

  Table 1--Distributed Total Development and Preparation Costs for EHR Technology Developers (2-Year Period)--
                                                 Totals Rounded
----------------------------------------------------------------------------------------------------------------
                                                                                                  Total average
                  Year                     Ratio (percent)   Total low cost    Total high cost    cost estimate
                                                             estimate  ($M)    estimate  ($M)         ($M)
----------------------------------------------------------------------------------------------------------------
2014....................................                50              9.82             46.63             28.23
2015....................................                50              9.82             46.63             28.23
                                         -----------------------------------------------------------------------
    2-Year Totals.......................  ................             19.65             93.26             56.46
----------------------------------------------------------------------------------------------------------------

II. Background

A. Statutory Basis

    The Health Information Technology for Economic and Clinical Health 
(HITECH) Act, Title XIII of Division A and Title IV of Division B of 
the American Recovery and Reinvestment Act of 2009 (the Recovery Act) 
(Pub. L. 111-5), was enacted on February 17, 2009. The HITECH Act 
amended the Public Health Service Act (PHSA) and created ``Title XXX--
Health Information Technology and Quality'' (Title XXX) to improve 
health care quality, safety, and efficiency through the promotion of 
HIT and electronic health information exchange.
1. Standards, Implementation Specifications, and Certification Criteria
    The HITECH Act established two new Federal advisory committees, the 
HIT Policy Committee (HITPC) and the HIT Standards Committee (HITSC) 
(sections 3002 and 3003 of the PHSA, respectively). Each is responsible 
for advising the National Coordinator for Health Information Technology 
(National Coordinator) on different aspects of standards, 
implementation specifications, and certification criteria. The HITPC is 
responsible for, among other duties, recommending priorities for the 
development, harmonization, and recognition of standards, 
implementation specifications, and certification criteria. Main

[[Page 10884]]

responsibilities of the HITSC include recommending standards, 
implementation specifications, and certification criteria for adoption 
by the Secretary under section 3004 of the PHSA consistent with the 
ONC-coordinated Federal Health IT Strategic Plan.
    Section 3004 of the PHSA identifies a process for the adoption of 
health IT standards, implementation specifications, and certification 
criteria and authorizes the Secretary to adopt such standards, 
implementation specifications, and certification criteria. As specified 
in section 3004(a)(1), the Secretary is required, in consultation with 
representatives of other relevant Federal agencies, to jointly review 
standards, implementation specifications, and certification criteria 
endorsed by the National Coordinator under section 3001(c) and 
subsequently determine whether to propose the adoption of any grouping 
of such standards, implementation specifications, or certification 
criteria. The Secretary is required to publish all determinations in 
the Federal Register.
    Section 3004(b)(3) of the PHSA titled ``Subsequent Standards 
Activity'' provides that the ``Secretary shall adopt additional 
standards, implementation specifications, and certification criteria as 
necessary and consistent'' with the schedule published by the HITSC. We 
consider this provision in the broader context of the HITECH Act to 
grant the Secretary the authority and discretion to adopt standards, 
implementation specifications, and certification criteria that have 
been recommended by the HITSC and endorsed by the National Coordinator, 
as well as other appropriate and necessary HIT standards, 
implementation specifications, and certification criteria. Throughout 
this process, the Secretary intends to continue to seek the insights 
and recommendations of the HITSC.
2. HIT Certification Programs
    Section 3001(c)(5) of the PHSA provides the National Coordinator 
with the authority to establish a certification program or programs for 
the voluntary certification of HIT. Specifically, section 3001(c)(5)(A) 
specifies that the ``National Coordinator, in consultation with the 
Director of the National Institute of Standards and Technology, shall 
keep or recognize a program or programs for the voluntary certification 
of health information technology as being in compliance with applicable 
certification criteria adopted under this subtitle'' (i.e., 
certification criteria adopted by the Secretary under section 3004 of 
the PHSA).
    The certification program(s) must also ``include, as appropriate, 
testing of the technology in accordance with section 13201(b) of the 
[HITECH] Act.'' Overall, section 13201(b) of the HITECH Act requires 
that with respect to the development of standards and implementation 
specifications, the Director of the National Institute of Standards and 
Technology (NIST), in coordination with the HITSC, ``shall support the 
establishment of a conformance testing infrastructure, including the 
development of technical test beds.'' The HITECH Act also indicates 
that ``[t]he development of this conformance testing infrastructure may 
include a program to accredit independent, non-Federal laboratories to 
perform testing.''

B. Regulatory History

1. Standards, Implementation Specifications, and Certification Criteria 
Rules
    The Secretary issued an interim final rule with request for 
comments titled, ``Health Information Technology: Initial Set of 
Standards, Implementation Specifications, and Certification Criteria 
for Electronic Health Record Technology'' (75 FR 2014, Jan. 13, 2010) 
(the ``S&CC January 2010 interim final rule''), which adopted an 
initial set of standards, implementation specifications, and 
certification criteria. After consideration of the public comments 
received on the S&CC January 2010 interim final rule, a final rule was 
issued to complete the adoption of the initial set of standards, 
implementation specifications, and certification criteria and realign 
them with the final objectives and measures established for meaningful 
use (MU) Stage 1 (formally titled: Health Information Technology: 
Initial Set of Standards, Implementation Specifications, and 
Certification Criteria for Electronic Health Record Technology; Final 
Rule, 75 FR 44590 (July 28, 2010) and referred to as the ``2011 Edition 
Final Rule''). The 2011 Edition Final Rule also established the first 
version of the Certified EHR Technology (CEHRT) definition. Subsequent 
to the 2011 Edition Final Rule (October 13, 2010), we issued an interim 
final rule with a request for comment to remove certain implementation 
specifications related to public health surveillance that had been 
previously adopted in the 2011 Edition Final Rule (75 FR 62686).
    The standards, implementation specifications, and certification 
criteria adopted by the Secretary in the 2011 Edition Final Rule 
established the capabilities that CEHRT must include in order to, at a 
minimum, support the achievement of MU Stage 1 by EPs, EHs, and CAHs 
under the Medicare and Medicaid EHR Incentive Programs Stage 1 final 
rule (the ``EHR Incentive Programs Stage 1 final rule'') (see 75 FR 
44314 for more information about MU and the Stage 1 requirements).
    Subsequently, the Secretary issued a notice of proposed rulemaking 
with request for comments titled ``Health Information Technology: 
Standards, Implementation Specifications, and Certification Criteria 
for Electronic Health Record Technology, 2014 Edition; Revisions to the 
Permanent Certification Program for Health Information Technology'' (77 
FR 13832, March 7, 2012) (the ``2014 Edition NPRM''), which proposed 
new and revised standards, implementation specifications, and 
certification criteria. After consideration of the public comments 
received on the 2014 Edition NPRM, a final rule was issued to adopt the 
2014 Edition set of standards, implementation specifications, and 
certification criteria and realign them with the final objectives and 
measures established for MU Stage 2 as well as MU Stage 1 revisions 
(Health Information Technology: Standards, Implementation 
Specifications, and Certification Criteria for Electronic Health Record 
Technology, 2014 Edition; Revisions to the Permanent Certification 
Program for Health Information Technology; (77 FR 54163 Sept. 4, 2012) 
(the ``2014 Edition Final Rule''). On December 7, 2012, an interim 
final rule with a request for comment was jointly issued by ONC and CMS 
to update certain standards that had been previously adopted in the 
2014 Edition final rule, as well as add an alternative measure for MU 
Stage 2, correct the regulation text, and modify the case number 
threshold exemption policy for clinical quality measure reporting under 
the EHR Incentive Program (77 FR 72985).
    The standards, implementation specifications, and certification 
criteria adopted by the Secretary in the 2014 Edition final rule 
established the capabilities that CEHRT must include in order to, at a 
minimum, support the achievement of MU Stage 2 by EPs, EHs, and CAHs 
under the Medicare and Medicaid EHR Incentive Programs Stage 2 final 
rule (the ``EHR Incentive Programs Stage 2 final rule'') (see 77 FR 
53968 for more information about the MU Stage 2 requirements).
    On November 4th, 2013 the Secretary published an interim final rule 
with a request for comment, 2014 Edition Electronic Health Record 
Certification

[[Page 10885]]

Criteria: Revision to the Definition of ``Common Meaningful Use (MU) 
Data Set'' (78 FR 65884), to make a minor revision to the Common MU 
Data Set definition. This revision was intended to allow more 
flexibility with respect to the representation of dental procedures 
data for EHR technology testing and certification.
2. Medicare and Medicaid EHR Incentive Programs Rules
    On January 13, 2010, CMS published the EHR Incentive Programs Stage 
1 proposed rule (75 FR 1844). The rule proposed the criteria for Stage 
1 of MU and regulations associated with the incentive payments made 
available under Division B, Title IV of the HITECH Act. Subsequently, 
CMS published a final rule (75 FR 44314) for the EHR Incentive Programs 
on July 28, 2010, simultaneously with the publication of the 2011 
Edition Final Rule. The EHR Incentive Programs Stage 1 final rule 
established the objectives, associated measures, and other requirements 
that EPs, EHs, and CAHs must satisfy to demonstrate MU during Stage 1.
    On March 7, 2012, CMS published the EHR Incentive Programs Stage 2 
proposed rule (77 FR 13698). Subsequently, CMS published a final rule 
(77 FR 53968) for the EHR Incentive Programs on Sept. 4, 2012, 
simultaneously with the publication of the 2014 Edition final rule. The 
EHR Incentive Programs Stage 2 final rule established the objectives, 
associated measures, and other requirements that EPs, EHs, and CAHs 
must satisfy to demonstrate MU during Stage 2 as well as revised MU 
Stage 1.
    As described above in Section II.B.1, ONC and CMS jointly issued an 
interim final rule with a request for comment on December 7, 2012 (77 
FR 72985). The interim final rule updates certain standards that had 
been previously adopted in the 2014 Edition final rule, adds an 
alternative measure for MU Stage 2, corrects the regulation text, and 
modifies the case number threshold exemption policy for clinical 
quality measure reporting under the EHR Incentive Program.
3. ONC HIT Certification Program Rules
    On March 10, 2010, ONC published a proposed rule (75 FR 11328) 
titled, ``Proposed Establishment of Certification Programs for Health 
Information Technology'' (the ``Certification Programs proposed 
rule''). The rule proposed both a temporary and permanent certification 
program for the purposes of testing and certifying HIT. It also 
specified the processes the National Coordinator would follow to 
authorize organizations to perform the certification of HIT. A final 
rule establishing the temporary certification program was published on 
June 24, 2010 (75 FR 36158) (the ``Temporary Certification Program 
final rule'') and a final rule establishing the permanent certification 
program was published on January 7, 2011 (76 FR 1262) (``the Permanent 
Certification Program final rule'').
    On May 31, 2011, ONC published a proposed rule (76 FR 31272) titled 
``Permanent Certification Program for Health Information Technology; 
Revisions to ONC-Approved Accreditor Processes.'' The rule proposed a 
process for addressing instances where the ONC-Approved Accreditor 
(ONC-AA) engaged in improper conduct or did not perform its 
responsibilities under the permanent certification program, addressed 
the status of ONC-Authorized Certification Bodies in instances where 
there may be a change in the accreditation organization serving as the 
ONC-AA, and clarified the responsibilities of the new ONC-AA. All these 
proposals were finalized in a final rule published on November 25, 2011 
(76 FR 72636).
    The 2014 Edition Final Rule made changes to the permanent 
certification program. The final rule adopted a proposal to change the 
Permanent Certification Program's name to the ``ONC HIT Certification 
Program,'' revised the process for permitting the use of newer versions 
of ``minimum standard'' code sets, modified the certification processes 
ONC-Authorized Certification Bodies (ONC-ACBs) need to follow for 
certifying EHR Modules in a manner that provides clear implementation 
direction and compliance with the new certification criteria, and 
reduced regulatory burden by eliminating the certification requirement 
that every EHR Module be certified to the ``privacy and security'' 
certification criteria.

III. Provisions of the Proposed Rule Affecting Standards, 
Implementation Specifications, and Certification Criteria

A. 2015 Edition EHR Certification Criteria

General Context
    This rule proposes new, revised, and unchanged certification 
criteria that would establish the technical capabilities and related 
standards and implementation specifications that could be implemented 
as part of an EP, EH, or CAH's CEHRT and their demonstration of either 
MU Stage 1 or MU Stage 2. We refer to these new, revised, and unchanged 
certification criteria as the ``2015 Edition EHR certification 
criteria'' or ``2015 Edition'' and propose to add this term and its 
definition to Sec.  170.102. Additionally, we propose to codify the 
2015 Edition EHR certification criteria in section 170.315 to set them 
apart and make it easier for stakeholders to quickly determine the 
certification criteria the 2015 Edition includes.
    We discuss the new, revised, and unchanged certification criteria 
that we propose to adopt as the 2015 Edition EHR certification criteria 
below. We specify where the proposed certification criteria would be 
included in Sec.  170.315. We also propose a substantive revision to 
the 2014 Edition syndromic surveillance certification criterion adopted 
at Sec.  170.314(f)(3).
    As we have in prior rulemakings, we include a table at the 
beginning of the discussion of each certification criterion or criteria 
that specifies the MU objective the proposed 2015 Edition EHR 
certification criterion or criteria supports. We also indicate in the 
table whether the criterion is ``eligible'' or ``ineligible'' for ``gap 
certification'' between the 2014 Edition and 2015 Edition under the ONC 
HIT Certification Program depending on whether it would be considered 
``unchanged'' between editions. We provide accompanying rationale for 
the proposed certification criteria, including citing the 
recommendations of the HITPC and HITSC, where appropriate.
    In contrast to our prior rulemakings, we discuss each certification 
criterion in the chronological order in which it would appear in the 
Code of Federal Regulations. In other words, the preamble that follows 
will discuss the proposed certification criteria in Sec.  170.315(a) 
first, then Sec.  170.315(b), and so on. This approach is designed to 
improve the preamble's readability and the ease with which commenters 
can reference back to sections of the proposed rule's preamble when 
necessary.
    We propose, and readers should interpret, that the following terms 
used in proposed 2015 Edition EHR certification criteria have the same 
meanings we adopted in the 2014 Edition Final Rule (77 FR 54168-54169), 
in response to public comment: ``user,'' ``record,'' ``change,'' 
``access,'' ``incorporate,'' ``create,'' ``transmit.'' Similarly, we 
propose that the scope of a 2015 Edition certification criterion is the 
same as the scope previously assigned to a 2014 Edition certification 
criterion (for further explanation, see the discussion at 77 FR 54168). 
That is,

[[Page 10886]]

certification to proposed 2015 Edition EHR certification criteria at 
Sec.  170.315 would occur at the second paragraph level of the 
regulatory section and encompass all paragraph levels below the second 
paragraph level. We also propose to continue to use the same specific 
descriptions for the different types of ``data summaries'' established 
in the 2014 Edition Final Rule (77 FR 54170-54171) for the proposed 
2015 Edition EHR certification criteria (i.e., ``export summary,'' 
``transition of care/referral summary,'' ``ambulatory summary,'' 
``inpatient summary,'' and ``clinical summary.''
Applicability--Sec.  170.300
    Section 170.300 establishes the applicability of subpart C--
Certification Criteria for Health Information Technology. We propose to 
revise paragraph (d) of Sec.  170.300 to add in a reference to Sec.  
170.315, which would clarify which specific capabilities within a 
certification criterion included in Sec.  170.315 have general 
applicability (i.e., apply to both ambulatory and inpatient settings) 
or apply only to an inpatient setting or an ambulatory setting.

 Computerized Provider Order Entry

    Section 3000 of the Public Health Service Act, as added by section 
13101 of the HITECH Act, requires that computerized provider order 
entry (CPOE) capabilities be included in CEHRT. We included CPOE 
capabilities in the Base EHR definition, which is part of the CEHRT 
definition, under 45 CFR Sec.  170.102. Within the 2011 and 2014 
Editions, we adopted CPOE certification criteria that require EHR 
technology to be capable of performing CPOE for medication, laboratory, 
and radiology/imaging orders. Based on stakeholder feedback since the 
2014 Edition Final Rule, we understand that this approach can prevent 
EHR technology developers from creating more efficient, provider-
specific ``adaptations'' of EHR technology that support CPOE.\3\ For 
example, a mobile adaptation of CPOE currently must include all of the 
capabilities listed in the 2014 Edition CPOE certification criterion 
(i.e., the adaptation must be capable of performing CPOE for each of 
the three types of orders (medication, laboratory and radiology/
imaging)) even though the EHR technology developer's customers may only 
wish to use the mobile adaptation to enter medication orders away from 
the office.
---------------------------------------------------------------------------

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

    Similarly, we can understand why our approach to CPOE certification 
can be interpreted by some providers as inconsistent with the 
flexibility provided in the FY/CY 2014 CEHRT definition under Sec.  
170.102. For example, the MU Stage 2 CPOE objective for EPs includes 
three associated measures (one measure for each of the three types of 
orders) and exclusions for each of those three measures. An EP who 
could potentially meet an exclusion for one or two of the measures 
would still need to possess EHR technology certified to the 2014 
Edition CPOE certification criterion (that is, CEHRT that includes CPOE 
capabilities for each of the three types of orders). Additionally, the 
MU Stage 1 CPOE objective for EPs does not include measures for 
laboratory and radiology orders, which means EPs attempting this 
objective also do not necessarily require these additional certified 
CPOE capabilities. For these reasons, we propose for the 2015 Edition 
to split the ``computerized provider order entry'' certification 
criterion into three separate certification criteria with each 
criterion focused on one of the three order types. Certification 
criteria focused on each order type would permit EHR technology 
developers to develop order-specific CPOE adaptations and provide EPs, 
EHs, and CAHs with significantly more implementation flexibility. If an 
EP expects to meet the MU exclusion for one or two of the MU measures 
(i.e., writing fewer than 100 of each order type during an EHR 
reporting period), they could choose to adopt EHR technology certified 
only to the 2015 Edition CPOE certification criterion for the order 
types reflected in the measure(s) they expect to demonstrate for MU. 
This approach would permit an EP to meet the Base EHR definition 
requirements and CEHRT definition without having to adopt EHR 
technology that includes certified CPOE capabilities they would not 
expect to use for MU.
    We caution, however, that the additional flexibility that this 
proposed approach enables also comes with potential risk for EPs who 
expect to qualify for one or more of the exclusions from the CPOE 
measures discussed above, but do not ultimately satisfy the exclusion 
criteria based on the number of orders written during an EHR reporting 
period. EPs who choose to possess EHR technology that is not certified 
for each of the three types of orders may risk not having EHR 
technology that meets the CEHRT definition if they ultimately fail to 
meet one or more MU exclusions. In most cases, we expect that EPs' 
scope of practice and the MU measures they need to meet will inform 
their decision (and corresponding responsibility) to adopt EHR 
technology certified to the now separately proposed CPOE capabilities. 
For example, a chiropractor may never or rarely place medication and 
laboratory orders and, thus, would not necessarily need EHR technology 
certified to the specific proposed CPOE certification criteria for 
those order capabilities. Conversely, an EP practicing obstetrics and 
gynecology may need EHR technology certified for all three CPOE order 
types. Overall, we emphasize that EHR technology developers need to be 
aware that this additional certification flexibility and subsequent 
certification decisions could have corresponding impacts on EPs who are 
ultimately responsible for ensuring that their EHR technology meets the 
CEHRT definition.
    The 2015 Edition ``CPOE'' certification criteria omit the ``at a 
minimum'' language included in the 2014 Edition and 2011 Edition CPOE 
certification criteria. This language was included in prior editions to 
indicate that EHR technology developers could include capabilities that 
support other types of orders. We believe this language is extraneous 
because we have consistently maintained that certification criteria 
(and certification in general) serve as minimum requirements or a 
baseline. As has always been the case, EHR technology developers may 
include capabilities in their EHR technology that go beyond all 
certification requirements.

 Computerized Provider Order Entry--Medications
MU Objective
    Use computerized provider order entry (CPOE) for medication, 
laboratory, and radiology orders directly entered by any licensed 
healthcare professional who can enter orders into the medical record 
per state, local and professional guidelines to create the first record 
of the order.
2015 Edition EHR Certification Criterion
    Sec.  170.315(a)(1) (Computerized physician order entry--
medications).
Gap Certification Status
    Eligible.

    As discussed above, we propose to adopt a 2015 Edition CPOE 
certification criterion specific to medication ordering. This proposed 
criterion is structured substantially similar to the 2014 Edition 
version, except it does not reference laboratory and radiology/imaging 
orders.

[[Page 10887]]

 Computerized Provider Order Entry--Laboratory
MU Objective
    Use CPOE for medication, laboratory, and radiology orders directly 
entered by any licensed healthcare professional who can enter orders 
into the medical record per state, local and professional guidelines to 
create the first record of the order.
2015 Edition EHR Certification Criterion
    Sec.  170.315(a)(2) (Computerized physician order entry--
laboratory).
Gap Certification Status
    Ineligible.

    The Clinical Laboratory Improvement Amendments (CLIA) of 1988 
amended the Public Health Service Act and revised the federal program 
for certification and oversight of clinical laboratory testing. CLIA 
applies to all clinical laboratories in the United States (in addition 
to some international laboratories that receive specimens from the 
United States for specialized testing not available in the United 
States) that perform examinations of materials derived from the human 
body for the purpose of providing information for the diagnosis, 
prevention, or treatment of any disease or impairment of, or the 
assessment of the health of human beings. Certain CLIA requirements 
focus on the communication and receipt of test orders (under pre-
analytic systems) and test results (under post-analytic systems) 
between an ordering provider and a clinical laboratory. Since the 
implementing regulations for CLIA were established at a time when paper 
was the dominant method of communication for laboratory orders and 
results (test requisitions and patient reports), the CLIA regulations 
governing these activities require each laboratory to establish and 
follow written policies and procedures for an ongoing mechanism to 
monitor, assess, and, when indicated, correct identified problems.
    As electronic methods for ordering and reporting clinical 
laboratory information become more prevalent and commonplace it is 
important to ensure that the intent of the CLIA regulations can be 
fully supported by EHR technology. This is especially important with 
regard to patient safety, the accurate, reliable ordering of clinical 
laboratory testing, and the accurate, reliable, and timely reporting of 
clinical laboratory test results. In light of the accelerating movement 
toward the electronic exchange of clinical information (including the 
transmission of laboratory orders and results), CMS issued guidance \4\ 
to clarify specific sections of the CLIA regulations. This guidance 
specified that clinical laboratories should test and verify the 
accuracy and reliability of each interface to an EHR technology. Since 
there are thousands of EHR technologies implemented across provider 
organizations and each likely has more than one laboratory interface, 
the task of testing both orders and reporting interfaces can be 
expensive, labor intensive, and time consuming. Additionally, CLIA 
requires periodic review of these interfaces so this is not a one-time 
procedure.
---------------------------------------------------------------------------

    \4\ http://www.cms.gov/Medicare/Provider-Enrollment-and-Certification/SurveyCertificationGenInfo/Downloads/SCLetter10-12.pdf.
---------------------------------------------------------------------------

    As a step toward addressing these issues, we propose to expand 
(compared to the 2014 Edition versions) the 2015 Edition certification 
criteria focused on the exchange of laboratory orders and results 
(Sec. Sec.  170.315(a)(2) and (b)(4) and (5)). These revised 2015 
Edition certification criteria propose certain CLIA-specific 
requirements and include updated laboratory exchange standards. CLIA-
specific requirements have been included in the ``electronic 
incorporation of lab results'' standard at Sec.  170.205(j)(2) and the 
``laboratory orders'' standard at Sec.  170.205(l)(1) and we reference 
these standards in the appropriate proposed certification criteria. 
Inclusion of CLIA-specific requirements and updated standards will 
allow for a more comprehensive evaluation of EHR technology's 
capabilities in regards to supporting compliance with the CLIA 
regulations. We believe, upon adoption of the 2015 Edition, it would be 
possible for CMS to issue additional guidance to further clarify how 
CLIA requirements related to ongoing interface testing could be met if 
EHR technology were to be certified to these more comprehensive 2015 
Edition certification criteria. Accordingly, we propose a ``CPOE--
laboratory'' certification criterion as well as ``incorporate 
laboratory tests and values/results,'' and ``transmission of electronic 
laboratory tests and values/results to ambulatory providers'' 
certification criteria (discussed later in this preamble) to include 
more comprehensive capabilities focused on ensuring EHR technology's 
ability to perform capabilities consistent with corresponding CLIA 
regulatory requirements.
    For the 2015 Edition ``CPOE--laboratory'' certification criterion, 
we propose to adopt, for the ambulatory setting, the HL7 Version 2.5.1 
Implementation Guide: S&I Framework Laboratory Orders from EHR, Release 
1-US Realm, Draft Standard for Trial Use, November 2013 (S&I Framework 
LOI).\5\ Due to the absence of a consensus standard for the purpose of 
sending laboratory orders from EHRs to labs, this standard was 
developed in conjunction with laboratories representative of the 
industry, EHR technology developers, and provider stakeholders through 
an open consensus-based process under the Standards and 
Interoperability Framework (S&I Framework) and was balloted and 
approved through HL7, a standards development organization. We propose 
to adopt the S&I Framework LOI standard at Sec.  170.205(l)(1). We also 
propose to require the use of, at a minimum, the version of Logical 
Observation Identifiers Names and Codes (LOINC[supreg]) adopted at 
Sec.  170.207(c)(2) (version 2.40) as the vocabulary standard for 
laboratory orders. Last, we propose that laboratory orders must include 
all the information for a test requisition as specified at 42 CFR 
493.1241(c)(1) through (c)(8). The use of these standards and 
compliance with these requirements should greatly improve the 
interoperability of laboratory orders sent from ambulatory EHR 
technology to a laboratory and laboratory compliance with CLIA.
---------------------------------------------------------------------------

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

 Computerized Provider Order Entry--Radiology/Imaging
MU Objective
    Use CPOE for medication, laboratory, and radiology orders directly 
entered by any licensed healthcare professional who can enter orders 
into the medical record per state, local and professional guidelines to 
create the first record of the order.
2015 Edition EHR Certification Criterion
    Sec.  170.315(a)(3) (Computerized physician order entry--radiology/
imaging).
Gap Certification Status
    Eligible.

    As discussed above, we propose to adopt a 2015 Edition CPOE 
certification criterion specific to radiology/imaging ordering. This 
proposed criterion is structured substantially similar to the 2014 
Edition version, except it does not reference laboratory and medication 
orders.
 Drug-Drug, Drug-Allergy Interaction Checks
MU Objective
    Implement drug-drug and drug-allergy interaction checks.
2015 Edition EHR Certification Criterion

[[Page 10888]]

    Sec.  170.315(a)(4) (Drug-drug, drug-allergy interaction checks).
Gap Certification Status
    Eligible.

    We propose to adopt a 2015 Edition certification criterion that is 
the same as the 2014 Edition version. However, we do solicit public 
comment on several related issues.
    The 2014 Edition Drug-Drug, Drug-Allergy Interaction Checks 
certification criterion (45 CFR 170.314(a)(2)) requires EHR technology 
to be able to automatically and electronically indicate to a user any 
drug-drug and drug-allergy contraindications (``DDI/DAI''), where such 
contraindications are based on a patient's medication list and 
medication allergy list. The criterion further requires that such 
checks occur before a medication order is completed and acted upon 
during computerized provider order entry (CPOE). The criterion also 
requires that EHR technology certified to this criterion be able to 
adjust severity levels for drug-drug interaction checks and that such 
ability be limited to an identified set of users or available as a 
system administrative function.
    Because DDI/DAI checks are intended to identify potential medical 
errors before they occur, these checks can be valuable tools for 
improving patient safety and for improving overall health outcomes. In 
order for DDI/DAI checks to be effective, however, action must be taken 
in response to a notification. When health care providers ignore a 
notification for DDI/DAI, the very benefit that such checks provide is 
eliminated.
    Given the positive impact we believe DDI/DAI checks can have on 
patient safety, we are considering whether a future certification 
criterion edition could require DDI/DAI capable EHR technology to track 
user responses to DDI/DAI notifications (``response tracking'') and 
whether commenters believe this would be a positive potential step 
toward improving user experience with DDI/DAI checking. The purpose of 
including this type of capability in a certification criterion would be 
to equip health care providers with response data that they could use 
to improve their own performance and the safe use of their EHR 
technology. With such response tracking data, health professionals 
could analyze the notifications that are often ignored or missed and 
could work with clinicians to learn why they ignored or missed them. 
Understanding clinician decisions related to DDI/DAI notifications also 
can help health professionals make such notifications more effective, 
and potentially eliminate ineffective notification methods. This 
information also may be helpful for EHR technology developers as they 
design DDI/DAI checks and notifications.
    We therefore seek comment on whether we should consider adopting a 
certification criterion as part of a future edition of certification 
criteria that would require EHR technology to be able to track health 
professionals' responses to the DDI/DAI checks that are performed and 
whether such a capability should track if and when the health 
professional viewed, accepted, declined, ignored, overrode, or 
otherwise commented on the product of a DDI/DAI check. We also seek 
comment on who should be permitted to review the data collected by the 
DDI/DAI check tracking capability, who should be able to adjust its 
configuration settings, whether the data tracked should be limited in 
scope or specificity, and whether EHR technology should be able to 
track when an adverse event occurs for which a DDI/DAI check was missed 
or ignored.
    Last, we seek comment on whether a DDI/DAI tracking capability 
should only track inaction or responses related to certain drug-drug 
and drug-allergy reactions, such as only tracking DDI/DAI alerts that 
if missed or ignored would cause severe reactions in patients. We also 
seek comment on what factors, definitions, standards, or existing 
consensus should be considered in determining whether a likely DDI/DAI 
reaction should be considered severe.
 Demographics
MU Objective
    Record the following demographics: preferred language; sex; race; 
ethnicity; date of birth; and for the inpatient setting only, date and 
preliminary cause of death in the event of mortality in the EH or CAH.
2015 Edition EHR Certification Criterion
    Sec.  170.315(a)(5) (Demographics)
Gap Certification Status
    Ineligible.

    We propose to adopt a 2015 Edition ``demographics'' certification 
criterion that revises the 2014 Edition version. Our two proposals for 
the 2015 Edition criterion address a new standard for recording 
preferred language and that EHR technology must be capable of enabling 
a user to electronically record, change, and access the date of death 
and the preliminary cause of death.
Preliminary Cause of Death and Date of Death
    We propose to include in the 2015 Edition the capability to enable 
a user to electronically record, change, and access the ``date of 
death'' as a required capability that EHR technology designed for the 
inpatient setting must demonstrate. We previously included this 
capability as part of the 2011 Edition ``demographics'' certification 
criterion and inadvertently omitted it from the 2014 Edition. Thus, 
this change would more accurately track the data required by the 
meaningful use criteria. To note, this functionality would be in 
addition to the inclusion in the 2015 Edition ``demographics'' 
certification criterion of the same capability to enable a user to 
electronically record, change, and access ``preliminary cause of 
death'' in case of mortality as is included in the 2014 Edition 
``demographics'' certification criterion.
Preferred Language
    Based on specific HITSC recommendations, we adopted ISO 639-2 
constrained by ISO 639-1 for recording preferred language in the 2014 
Edition ``demographics'' certification criterion. More specifically, 
this means that EHR technology is required to be capable of using the 
alpha-3 codes of ISO 639-2 to represent the corresponding alpha-2 code 
in ISO-639-1. To provide further clarity, we issued FAQ 27 \6\ in which 
we stated that where both a bibliographic code and terminology code are 
present for a required ISO 639-2 language, EHR technology is expected 
to be capable of representing the language in accordance with the (T) 
terminology codes (ISO 639-2/T) for the purposes of certification.
---------------------------------------------------------------------------

    \6\ http://www.healthit.gov/policy-researchers-implementers/27-question-10-12-027.
---------------------------------------------------------------------------

    After we issued FAQ 27, we issued FAQ 43 \7\ in which we 
acknowledge that our constrained approach to the use of ISO 639-2 
unintentionally excluded multiple languages that are currently in use, 
such as sign language and Hmong. Additionally, ISO 639-2 is meant to 
support written languages, which may not be the language with which 
patients instinctively respond when asked for their preferred language. 
To improve this situation, we propose to adopt one of the following 
three options for the 2015 Edition ``demographics'' certification 
criterion:
---------------------------------------------------------------------------

    \7\ http://www.healthit.gov/policy-researchers-implementers/43-question-11-13-043.

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

[[Page 10889]]

    Option 1: Adopt ISO 639-2 \8\ codes--in full--as part of 
certification to the 2015 Edition ``demographics'' certification 
criterion. We note, however, that as mentioned in FAQ 43, the ISO-639-2 
standard was ``intended for written languages primarily.'' For 
instance, ``Chinese'' is represented by its official language, 
Mandarin, in the code list. This would not account for the commonly 
spoken Cantonese language/dialect or other spoken Chinese languages/
dialects. As a result, EHR technology developers may find that 
particular spoken languages are not in all cases sufficiently supported 
by the constrained standard we adopted for 2014 Edition certification. 
We have proposed this option in our regulatory text and propose to 
adopt the full ISO-639-2 codes at Sec.  170.207(g)(2). Note, to 
implement this proposal, we would have to modify the regulatory text 
hierarchy in Sec.  170.207(g) to designate the standard referenced by 
the 2014 Edition version of this certification criterion at Sec.  
170.207(g) to be at Sec.  170.207(g)(1).
---------------------------------------------------------------------------

    \8\ http://www.loc.gov/standards/iso639-2/iso639-2ra.html
---------------------------------------------------------------------------

    Option 2: Adopt ISO 639-3.\9\ We chose not to adopt ISO 639-3 as 
part of the 2014 Edition ``demographics'' certification criterion in 
response to one comment on our proposed 2014 Edition criterion because 
we believed it exceeded the baseline necessary for certification and we 
had insufficient stakeholder feedback. ISO 639-3 is a code set that 
aims to define three-letter identifiers for all known human languages. 
ISO 639-3 attempts to provide as complete an enumeration of languages 
as possible, including living, extinct, ancient, and constructed 
languages, whether major or minor, written or unwritten. We seek 
comment on its appropriateness as the baseline standard for recording 
preferred language as part of the 2015 Edition ``demographics'' 
certification criterion.
---------------------------------------------------------------------------

    \9\ http://www-01.sil.org/iso639-3/
---------------------------------------------------------------------------

    Option 3: Adopt Request for Comments (RFC) 5646.\10\ RFC 5646 
entitled ``Tags for Identifying Languages, September 2009'' is the 
coding system that is commonly used to encode languages on the web and 
is the most current RFC for this purpose and listed as a ``best current 
practice.'' The first part of the code relies on the shortest ISO-639 
code for the language. That means a 2-character code if the language is 
specified in ISO 639-1 or a 3-character code from ISO 639-2 or -3, if 
the language is only listed in one of those two ISO codes. We are also 
aware that RFC 5646 supports dialects.
---------------------------------------------------------------------------

    \10\ http://www.rfc-editor.org/info/rfc5646
---------------------------------------------------------------------------

    We welcome comments on which standard should be required for 
recording preferred language as part of the 2015 Edition 
``demographics'' certification criterion. Additionally, we propose in a 
later section of this rule that the chosen standard would also become 
the preferred language standard for the ``Common MU Data Set'' 
definition. Please see section III.D.3 ``Common MU Data Set'' of this 
preamble for further discussion of this associated proposal.
 Vital Signs, Body Mass Index, and Growth Charts
MU Objective
    Record and chart changes in the following vital signs: height/
length and weight (no age limit); blood pressure (ages 3 and over); 
calculate and display body mass index (BMI); and plot and display 
growth charts for patients 0-20 years, including BMI.
2015 Edition EHR Certification Criterion
    Sec.  170.315(a)(6) (Vital signs, body mass index, and growth 
charts)
Gap Certification Status
    Eligible
    We propose to adopt a 2015 Edition certification criterion that is 
the same as the 2014 Edition version. However, we solicit public 
comment on the following issues. In the 2014 Edition Final Rule (77 FR 
54203), we declined to revise the certification criterion at Sec.  
170.314(a)(4) in response to comments that recommended we require EHR 
technology to record vital signs in standardized vocabularies (e.g., 
LOINC, SNOMED CT, and UCUM). At the time, we believed that it was too 
complex and burdensome for technology developers to map workflows, 
templates, and forms used to capture vital signs to standardized 
vocabularies. We also expressed concern that such a requirement could 
cause EHR technology developers to map vital signs to a standardized 
terminology in one workflow but perhaps not others. We were concerned 
that such an approach could cause providers to be forced to use a given 
workflow, form, or template to achieve MU that is inconsistent with 
optimal workflow and usability. However, we noted that EHR technology 
developers would not be precluded from using standardized vocabularies 
to meet this 2014 Edition EHR certification criterion.
    We have continued to receive stakeholder feedback that we should 
consider adopting standardized vocabularies for recording vital signs 
(e.g., LOINC for observations). However, we have also received feedback 
that we should continue to allow flexibility in how vital signs are 
recorded. As a result, we solicit comment on whether we should adopt 
standardized vocabularies for recording vital signs (specifically, 
whether we should adopt LOINC (for observations), SNOMED CT (for 
qualitative results), and UCUM (for units of measure)) in this 
certification criterion for the 2017 Edition. In addition to these 
vocabularies, we also solicit comment on whether other vocabularies 
would be better for recording vital signs.
    In the 2014 Edition Final Rule, we stated that we intended to 
require that EHR technology be able to record all vital signs according 
to standardized technologies in the next EHR certification criteria 
edition (77 FR 54203). This was intended to be an incremental step 
toward interoperability at a more granular level. At the time of 
publication, we anticipated that the next certification criteria 
edition would be published with the MU Stage 3 rulemaking. However, 
given our modified approach to the rulemaking timeline discussed at the 
beginning of the preamble, we are using this intermediate 2015 Edition 
rulemaking to solicit more detailed comment on this issue to inform our 
policy decisions for the 2017 Edition.
    For recording vital signs, we are considering two different 
approaches:
     Option 1 would be to require that EHR technology be able 
to record vital signs data natively using the aforementioned standards 
as part of the vital signs certification criterion. For the majority of 
our 2014 Edition certification criteria, we only require vocabulary 
standard(s) be used as part of a transmission rather than natively 
within the EHR. While it is not the norm, we have already set precedent 
for certain 2014 Edition certification criteria (e.g., smoking status) 
to require EHR technology to demonstrate the ability to natively record 
data in a particular standard as opposed to only having to apply that 
standard when data is exchanged. One potential benefit of this approach 
is that the standardized vocabularies are applied to the data as it is 
collected (e.g., to provide contextual information about the data to 
assist with interpretation). A downside, however, is that it could 
require more upfront work on the part of providers to capture the data 
in a standardized way and that certain local approaches to data 
collection may need to be discontinued.
     Option 2 would be to require that EHR technology be able 
to represent such data in the aforementioned standards in any 
certification criterion

[[Page 10890]]

that references vital signs when such data would be exchanged. For 
example, when exchanging a summary care record, the EHR technology 
would need to ensure blood pressure is represented in the CCDA 
formatted summary care record in the appropriate standard. Presumably, 
this option would be less burdensome on providers. It would also 
continue to allow them to collect vitals in local and non-standardized 
ways within their own EHR technology. However, it could also result in 
lost precision regarding the context associated with the vitals 
recorded.
    Last, additional feedback we have received from stakeholders 
indicated that if we were to pursue option 2, we would be best served 
to require EHR technology to record additional metadata related to the 
context around how the vital signs were collected. Stakeholders 
indicated that this additional information would provide context and 
comparability for the data if a standard vocabulary is not used when 
the data is recorded. For recording vitals, it is our understanding 
that unless particular contextual information associated with data 
collection is captured locally, data may be misinterpreted by a 
receiving party.
    Without certain kinds of contextual information, vitals data cannot 
be cross-walked or coded correctly. For example, a single blood 
pressure measurement may not represent a patient's true blood pressure. 
In older patients, the American Heart Association (AHA) \11\ recommends 
taking the patient's blood pressure twice while standing, recording the 
average of the two, and then taking the patient's blood pressure twice 
while sitting and using the sitting average as the final reading. The 
standing average is to be used as a reference point only. If this 
information (e.g., whether the patient was sitting or standing, if the 
measure is the first, second, or average) is not recorded in the EHR 
along with the blood pressure measurement itself, the readings may not 
be correctly understood by a receiving party, such as another provider 
or caregiver. Therefore, we are also soliciting comment on whether we 
should prioritize our attention toward making sure EHR technology can 
capture this kind of contextual information or other metadata and what 
kinds of data would be best or most helpful for EHR technology 
certification to require. Please note we are not proposing that blood 
pressure must be recorded according to the AHA's recommendations. 
Rather, we use their recommendations to illustrate how contextual 
information about vital signs may be important to prevent 
misinterpretation. Finally, we solicit comments on whether vocabularies 
(and other metadata) are sufficient for the reuse of more granular data 
elements and whether continued work through initiatives (e.g., the 
Clinical Information Modeling Initiative (CIMI), Fast Health 
Interoperable Resources (FHIR)) to support capturing clinical entity 
models or other approaches for representing more granular data elements 
is needed.
---------------------------------------------------------------------------

    \11\ New AHA Recommendations for Blood Pressure Measurement. Am 
Fam Physician. 2005 Oct 1;72(7):1391-1398.
---------------------------------------------------------------------------

 Problem List
MU Objective
    Maintain an up-to-date problem list of current and active 
diagnoses.
2015 Edition EHR Certification Criterion
    Sec.  170.315(a)(7) (Problem list)
Gap Certification Status
    Eligible

    We propose to adopt a 2015 Edition certification criterion that is 
the same as the 2014 Edition version.
 Medication List
MU Objective
    Maintain active medication list.
2015 Edition EHR Certification Criterion
    Sec.  170.315(a)(8) (Medication list)
Gap Certification Status
    Eligible

    We propose to adopt a 2015 Edition EHR certification criterion that 
is the same as the 2014 Edition version.
 Medication Allergy List
MU Objective
    Maintain active medication allergy list.
2015 Edition EHR Certification Criterion
    Sec.  170.315(a)(9) (Medication allergy list)
Gap Certification Status
    Eligible

    We propose to adopt a 2015 Edition certification criterion that is 
the same as the 2014 Edition version.
 Clinical Decision Support
MU Objective
    Use clinical decision support to improve performance on high-
priority health conditions.
2015 Edition EHR Certification Criterion
    Sec.  170.315(a)(10) (Clinical decision support)
Gap Certification Status
    Ineligible

    We propose to adopt a 2015 Edition certification criterion that 
revises the 2014 Edition version in several ways. The 2014 Edition EHR 
certification criterion for CDS (Sec.  170.314(a)(8)) requires EHR 
technology to perform certain capabilities based on ``demographics'' 
data. Since the 2014 Edition Final Rule's publication, we have received 
many clarifying questions on whether EHR technology presented for 
certification must demonstrate the capability to use more than one of 
the demographics data categories listed in the ``Demographics'' 
certification criterion adopted at Sec.  170.314(a)(3). Similar to the 
proposed 2015 Edition ``Patient List Creation'' certification 
criterion's modification of the 2014 Edition version, we are also 
proposing to adopt a 2015 Edition CDS certification criterion that 
incorporates the guidance we provided in FAQ 39.\12\ Specifically, the 
text of the 2015 Edition ``CDS'' certification criterion provides that 
EHR technology must demonstrate the capability to use at least one of 
the more specific data categories included in the ``demographics'' 
certification criterion (45 CFR 170.315(a)(5)) (e.g., sex or date of 
birth).
---------------------------------------------------------------------------

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

    The 2014 Edition EHR certification criterion for CDS also requires 
EHR technology to provide Infobutton \13\-enabled diagnostic and 
therapeutic reference information (Sec.  170.314(a)(8)(ii)(2)) in 
accordance with one of the Infobutton implementation specifications at 
Sec.  170.204(b)(1) or Sec.  170.204(b)(2). Since the 2014 Edition 
Final Rule's publication, we received clarifying feedback that the 
Infobutton standard does not support vital signs and medication 
allergies data for linked referential CDS and subsequently issued FAQ 
34 \14\ to clarify how 2014 Edition testing and certification would 
handle this limitation.\15\ As a result, we propose that the 2015 
Edition CDS certification criterion will not require compliance with 
the Infobutton-enabled capability for vital signs nor medication 
allergies data. We also propose to discontinue referencing ``laboratory 
values/results'' data as we understand from stakeholder feedback that 
the Infobutton standard cannot support this specific data. Further, we 
propose to adopt the HL7 Implementation Guide: Service-Oriented 
Architecture Implementations of the Context-aware Knowledge Retrieval 
(Infobutton) Domain, Release 1, August 2013 (at Sec.  170.204(b)(3)) in

[[Page 10891]]

place of the older version referenced by the 2014 Edition certification 
criterion.
---------------------------------------------------------------------------

    \13\ ``Infobutton'' is typically the shorthand name used to 
refer to the formal standard's name: HL7 Version 3 Standard: 
Context-Aware Retrieval Application (Infobutton).
    \14\ http://www.healthit.gov/policy-researchers-implementers/34-question-12-12-034.
    \15\ http://www.healthit.gov/policy-researchers-implementers/34-question-12-12-034.
---------------------------------------------------------------------------

Health eDecisions Proposal
    Launched in June 2012, an ONC Standards & Interoperability 
Framework initiative known as Health eDecisions (HeD) focused on 
defining and harmonizing standards that could facilitate the emergence 
of systems and services for shareable CDS. Since that time, the HeD 
Working Group has developed two use cases with functional requirements, 
defined and balloted relevant standards, developed IGs, and is in the 
process of conducting pilots and performing data collection for 
analysis.
    HeD use case (UC) 1 defines the functional requirements needed to 
build a standard schema for the contents of three ``CDS Knowledge 
Artifact'' \16\ types: event condition action (ECA) rules, order sets, 
and documentation templates.\17\ UC 1 is based on the scenario of a 
``CDS Knowledge Artifact supplier'' making a computable CDS Knowledge 
Artifact available to a ``CDS Artifact integrator.'' The HeD Working 
Group created the HL7 Implementation Guide: Clinical Decision Support 
Knowledge Artifact Implementation Guide, Release 1 (January 2013) 
(``HeD standard'') \18\ as a companion document for the CDS Knowledge 
Artifact schema (described in the HeD standard IG). The HeD standard 
includes additional background, contextual information, and detailed 
documentation and guidance to support schema implementation.\19\ 
Overall, implementation of the HeD standard would greatly assist the 
industry in producing and sharing machine readable files for 
representations of clinical guidance.
---------------------------------------------------------------------------

    \16\ A CDS Knowledge Artifact is the encoding of structured CDS 
content as a rule to support clinical decision making in many areas 
of the health care system, including quality and utilization 
measures, disease outbreaks, comparative effectiveness analysis, 
efficacy of drug treatments, and monitoring health trends.
    \17\ HL7 Implementation Guide: Clinical Decision Support 
Knowledge Artifact Implementation Guide, Release 1 (January 2013) 
(``HeD standard'').
    \18\ http://wiki.siframework.org/file/detail/implementation_guide_working_final_042413_lse_uploaded-1.docx.
    \19\ Background documents and implementation guides can be found 
at http://wiki.siframework.org/Health+eDecisions+Homepage.
---------------------------------------------------------------------------

    HeD UC 2 defines the interface requirements needed to send patient 
data and receive CDS guidance based on one scenario: a request for 
clinical guidance made to a CDS guidance supplier.\20\ The HeD Working 
Group considered the following interactions with a CDS guidance 
supplier: drug dosing calculation; immunization forecasting; disease 
management; quality measure evaluation; transition of care support; 
prediction rule evaluation (e.g., APACHE score, AHRQ Pneumonia Severity 
Index); and severity of illness assessment (e.g., Charlson Index). The 
HeD Working Group created the HL7 Decision Support Service 
Implementation Guide, Release 1, Version 1 (December 2013) \21\, which 
defines SOAP and REST Web service interfaces for CDS guidance services. 
The implementation of this IG would promote systems whereby a health 
care provider can send a question about a patient to a CDS guidance 
supplier and receive CDS guidance back in near real-time.
---------------------------------------------------------------------------

    \20\ HL7 Decision Support Service Implementation Guide, Release 
1, Version 1 (December 2013).
    \21\ http://wiki.siframework.org/file/view/20130830_DSS_IG_R1_for_201309_ballot.zip/448259852/20130830_DSS_IG_R1_for_201309_ballot.zip.
---------------------------------------------------------------------------

    The functionality discussed above could significantly enhance the 
scalability and time to market of new clinical knowledge and improve 
care. We also believe, with the progress made by the HeD initiative 
since its launch, that this proposed rule serves as an opportunity to 
propose the HeD standard for testing and certification. Further, its 
proposal as part of the 2015 Edition permits EHR technology developers 
and other interested stakeholders to provide feedback on its readiness 
for inclusion in the 2017 Edition.
    We therefore propose to adopt the HL7 Implementation Guide: 
Clinical Decision Support Knowledge Artifact Implementation Guide, 
Release 1 (January 2013) (``HeD standard'') as a standard at Sec.  
170.204(d) and to require that EHR technology be able to electronically 
process a CDS artifact formatted in the HeD standard. We also propose 
to adopt the HL7 Decision Support Service Implementation Guide, Release 
1, Version 1 (December 2013) as a standard at Sec.  170.204(e) and to 
require that EHR technology demonstrate the ability to make an 
information request, send patient data, and receive CDS guidance 
according to the interface requirements defined in the Decision Support 
Service IG. To supplement our proposals, we solicit comment on:
     What specifically ONC should focus on when it comes to 
testing and certification for acceptance and incorporation of CDS 
Knowledge Artifacts;
     The feasibility of implementing the interface requirements 
defined in the Decision Support Service IG to make an information 
request, send patient data, and receive CDS guidance in near real-time;
     The ease with which EHR technology could be developed to 
consume CDS Knowledge Artifacts;
     Whether we should work to distinguish between complex CDS 
Knowledge Artifacts and simple Knowledge Artifacts and to require only 
acceptance and incorporation of simple Knowledge Artifacts in the 2015 
Edition, with increasing expectations of more complex capabilities in 
future editions;
     The ability to store and auto-configure a CDS Knowledge 
Artifact in EHR technology; and
     The ability to map the CDS Knowledge Artifact standard to 
data within the EHR technology (including medications, laboratory, and 
allergies information).
 Electronic Notes
MU Objective
    Record electronic notes in patient records.
2015 Edition EHR Certification Criterion
    Sec.  170.315(a)(11) (Electronic notes)
Gap Certification Status
    Ineligible

    We propose to adopt a 2015 Edition certification criterion that 
revises the 2014 Edition version. We propose a 2015 Edition 
``electronic notes'' certification criterion that would include one new 
requirement compared to the 2014 Edition ``electronic notes'' 
certification criterion. Specifically, for the 2015 Edition 
certification criterion, we propose that EHR technology have the 
capability to search for information across separate notes within the 
EHR technology rather than just within one particular note. This 
expanded requirement is intended to reduce the time providers spend 
looking for specific patient information. The requirement to search 
across notes is not limited to a specific method. Instead, we are 
primarily concerned that the outcome expressed is demonstrated. We 
expect and encourage EHR technology developers to create innovative 
ways to achieve this functionality. As with the 2014 Edition 
``electronic notes'' certification criterion, ``search'' continues to 
mean the ability to search free text and data fields of electronic 
notes.
    While we propose to adopt the ``search across notes'' capability 
for the 2015 Edition, we request comment on the following:
     Whether this functionality should extend to all patient 
electronic notes stored in the EHR or just to a specific patient's 
electronic notes or specific types of patient notes;

[[Page 10892]]

     Whether we should require this functionality in the 2015 
Edition or wait to include it in a potential 2017 Edition ``electronic 
notes'' certification criterion; and
     Health care provider opinions on whether the availability 
of such functionality (either searching across a specific patient's 
electronic notes stored in the EHR or all patients' electronic notes 
stored in an EHR) is so widespread that it would be unnecessary to 
require it as a condition of certification. We note that the 
``electronic notes'' objective and measure for MU Stage 2 requires that 
notes be text searchable, but does not require searching across 
electronic notes.
     Whether additional metadata should be required as part of 
electronic notes (such as the HL7 R2 header) to assist in both 
searching of notes, but also to make exporting electronic notes for 
patient data portability easier.
 Drug Formulary Checks
MU Objective
    Implement drug formulary checks.
2015 Edition EHR Certification Criterion
    Sec.  170.315(a)(12) (Drug formulary checks)
Gap Certification Status
    Eligible

    We propose to adopt a 2015 Edition certification criterion that is 
the same as the 2014 Edition version. However, we solicit public 
comment on the following issues. In the 2014 Edition EHR certification 
criteria final rule, we strongly encouraged EHR technology developers 
to use the updated Medicare Part D e-prescribing standards, including a 
new version of the NCPDP Formulary and Benefit standard (NCPDP 
Formulary and Benefit Standard 3.0), if or when it was finalized as an 
official Part D E-Prescribing standard (77 FR 45022). At the time, we 
did not believe it was necessary to require the use of the NCPDP 
Formulary and Benefit Standard 3.0 if/when it became the official Part 
D E-Prescribing standard as a condition of certification because our 
certification criterion was flexible and permitted EHR technology to 
access and store external drug formularies in support of meaningful 
use.
    CMS agreed with comments on the CY 2013 Physician Fee Schedule 
proposed rule that suggested the adoption of the NCPDP Formulary and 
Benefit Standard 3.0 as the official Part D E-Prescribing standard 
should be delayed until after July 1, 2014, which was expected to be 
the ``sunset date'' when NCPDP would cease to support version 1.0 (77 
FR 68892). Furthermore, CMS determined that it should also delay 
recognition of the NCPDP Formulary and Benefit Standard 3.0 as a 
backward compatible version of NCPDP Formulary and Benefits Standard 
1.0 because it did not believe that two versions of a standard should 
be used over an extended period of time (77 FR 68892). Having come 
within a year of the originally proposed sunset date, CMS recently re-
proposed and finalized a proposal to recognize NCPDP Formulary and 
Benefit Standard v.3.0 as a backward compatible version of NCPDP 
Formulary and Benefit Standard 1.0 for the period of July 1, 2014 
through February 28, 2015, and to retire version 1.0 and adopt version 
3.0 as the official Part D E-Prescribing standard on March 1, 2015 (77 
FR 74787-74789).\22\
---------------------------------------------------------------------------

    \22\ CMS originally proposed retiring V1.0 on July 1, 2014, but 
subsequently decided to postpone the retirement date to March 1, 
2015, in response to comments to allow the industry adequate time to 
implement the necessary changes and testing to implement v3.0 (78 FR 
74789).
---------------------------------------------------------------------------

    The NCPDP Formulary and Benefit Standard 3.0 includes updates based 
on industry feedback and new or modified business needs. For a full 
discussion of the changes that were made to previous versions of the 
NCPDP Formulary and Benefit Standard that NCPDP ultimately developed 
toward NCPDP Formulary and Benefit Standard 3.0, see 77 FR 45023-
45024).
    The HITSC has discussed the current structure of the NCPDP 
Formulary and Benefit Standard v.4.0 \23\ and has noted potential 
limitations. These include: \24\
---------------------------------------------------------------------------

    \23\ V.4.0 has minor changes compared to v.3.0, including 
removal of values from an unused diagnosis code, typographical 
changes, and a change to the standard length of the name field. CMS 
has proposed adopting v.3.0 (CY2014 Physician Fee Schedule proposed 
rule), which includes the substantive changes from previous 
versions.
    \24\ Clinical Operations Workgroup Update to the HITSC on June 
19, 2013. http://www.healthit.gov/FACAS/sites/faca/files/clinical_operations_wg_update_062013_0.pdf.
---------------------------------------------------------------------------

     That large files are needed to provide the formulary and 
benefit data;
     that the data are submitted in batch rather than in real-
time;
     the provider cannot see patient-specific variations in 
drug-specific benefits;
     an assumption that the patient's current drug plan is 
identified through a successful eligibility check based on a five-point 
identifier rather than the actual pharmacy data;
     the inability to detect differences in primary and 
secondary prescription benefit coverage;
     that the provider must manually pull updated formulary and 
benefit data rather than being pushed the updates.
    In order to resolve the limitations of NCPDP Formulary and Benefit 
Standard v.4.0, the HITSC has discussed that a new or updated standard 
or transaction is needed for EHRs to develop the functionality to run 
patient-specific formulary checks against the patient's actual drug 
benefit for a specific drug and dose in a timely manner. However, this 
is a long-term potential suggestion. Despite the NCPDP Formulary and 
Benefit Standard v.4.0's limitations, it does support providers' 
ability to know what drugs are included in the formulary, which can 
assist them in helping patients make decisions about their care. In the 
meantime, the NCPDP Formulary and Benefit Standard v.3.0 appears to be 
the best standard available for this particular use case. As described 
above, CMS has recently finalized a proposal to recognize NCPDP 
Formulary and Benefit Standard v.3.0 as a backward compatible version 
of NCPDP Formulary and Benefit Standard 1.0 starting on July 1, 2014, 
and v.4.0 includes minor changes compared to v.3.0.
    For a long-term potential solution, the NCPDP Telecommunications 
Standard used for pharmacy-to-payer transactions may offer some 
solutions when used in conjunction with the NCPDP Formulary and Benefit 
Standard v.4.0, specifically for certifying patient-level eligibility 
and prescription drug benefits with detailed information defining 
reimbursement or denial of compensation with explanations. However, to 
date, the NCPDP Telecommunications Standard has been used mostly for 
real-time billing of pharmacy transactions.
    In light of these circumstances and challenges, we solicit comment 
on whether we should leave this certification criterion as-is (in its 
flexible form) as we consider 2017 Edition policy or if it would be 
advantageous for us to adopt a standard in this 2015 Edition 
certification criterion for which compliance would be required. We also 
solicit comment on:
     The appropriateness of using the NCPDP Telecommunications 
Standard in conjunction with the NCPDP Formulary and Benefit Standard 
v.3.0 or v.4.0 to support expanded use cases such as real-time benefit 
checks; and
     Whether there are other standards or solutions that can 
address the potential limitations identified by HITSC and the use case 
of real-time benefit checks.
 Smoking Status
MU Objective
    Record smoking status for patients 13 years old or older.
2015 Edition EHR Certification Criterion

[[Page 10893]]

    Sec.  170.315(a)(13) (Smoking status)
Gap Certification Status
    Eligible

    We propose to adopt a 2015 Edition certification criterion that is 
the same as the 2014 Edition version.
 Image Results
MU Objective
    Imaging results and information are accessible through Certified 
EHR Technology.
2015 Edition EHR Certification Criterion
    Sec.  170.315(a)(14) (Image results)
Gap Certification Status
    Eligible

    We propose to adopt a 2015 Edition certification criterion that is 
the same as the 2014 Edition version.
 Family Health History
MU Objective
    Record patient family health history as structured data.
2015 Edition EHR Certification Criterion
    Sec.  170.315(a)(15) (Family health history)
Gap Certification Status
    Ineligible

    We propose to adopt a 2015 Edition certification criterion that 
revises the 2014 Edition version. The 2014 Edition ``family health 
history'' certification criterion requires EHR technology to 
demonstrate that it is capable of enabling a user to electronically 
record, change, and access a patient's family health history according 
to certain standards. In support of the MU Stage 2 requirement that 
family health history be captured in structured data, we adopted two 
standards for recording family health history: Systematized 
Nomenclature of Medicine--Clinical Terms (SNOMED CT[supreg]) terms for 
familial conditions and the HL7 Pedigree standard. In adopting SNOMED 
CT[supreg], we acknowledged that HL7 Pedigree was a relatively new 
standard and that an implementation guide had not yet been 
published.\25\ As such, we stated that the use of SNOMED CT[supreg] was 
perhaps the best intermediate step for coding family health history in 
structured data if one was not to use the HL7 Pedigree standard.\26\
---------------------------------------------------------------------------

    \25\ 77 FR 54174 (September 4, 2012).
    \26\ 77 FR 54174 (September 4, 2012).
---------------------------------------------------------------------------

    In April 2013, an HL7 Pedigree IG, HL7 Version 3 Implementation 
Guide: Family History/Pedigree Interoperability, Release 1,\27\ was 
published. With the publication of this IG, we propose to adopt a 2015 
Edition ``family health history'' certification criterion that requires 
solely the recording of family health history according to the HL7 
Pedigree standard and the HL7 Version 3 Implementation Guide: Family 
History/Pedigree Interoperability, Release 1 (i.e., it omits SNOMED 
CT[supreg] as an option). We believe that convergence to this single 
standard and IG will ensure more precise electronic recording of family 
health history data and, more importantly, improve the interoperability 
of family health history information. As part of the 2014 Edition Final 
Rule, we incorrectly assigned the HL7 Pedigree standard to Sec.  
170.207 where we adopt ``vocabulary'' standards. Accordingly, for the 
2015 Edition proposal we have placed the HL7 Pedigree standard and its 
IG in Sec.  170.205(m)(1) to more accurately place it in the 
``content'' exchange standards section.
---------------------------------------------------------------------------

    \27\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=301.

 Patient List Creation
MU Objective
    Use clinically relevant information to identify patients who should 
receive reminders for preventive/follow-up care.
2015 Edition EHR Certification Criterion
    Sec.  170.315(a)(16) (Patient list creation)
Gap Certification Status
    Eligible

    We propose to adopt a 2015 Edition ``patient list creation'' 
certification criterion that revises the 2014 Edition version to 
incorporate our guidance provided in FAQ 39.\28\ Specifically, the text 
of the 2015 Edition ``patient list creation'' certification criterion 
provides that EHR technology must demonstrate its capability to use at 
least one of the more specific data categories included in the 
``demographics'' certification criterion (45 CFR 170.315(a)(5)) (e.g., 
sex or date of birth).
---------------------------------------------------------------------------

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

    For a potential 2017 Edition ``patient list creation'' 
certification criterion, we request comment on four issues for EHR 
technology certification:
    (1) Whether patient communication preferences should be a 
requirement for the inpatient setting;
    (2) Whether a minimum list of patient communication preferences 
should be more specifically defined in order to require that EHR 
technology be capable of creating patient reminder lists based on a 
patient's preferred communication medium (e.g., electronically through 
secure email or a patient portal, paper/regular mail, or phone);
    (3) Whether EHR technology should be able to use a patient's 
preferred language as a filter; and
    (4) Because this certification criterion also supports the 
meaningful use objective and measure related to ``patient reminders,'' 
whether we should include within this certification criterion or adopt 
a new certification criterion that would require EHR technology be able 
to provide patient reminders according to identified patient 
preferences and preferred language (for example, if the patient 
preference for a reminder was ``email'' and preferred language was 
English, the EHR technology would have to demonstrate that it could 
send reminders in English via email).
 Patient-Specific Education Resources
MU Objective
    Use clinically relevant information from Certified EHR Technology 
to identify patient-specific education resources and provide those 
resources to the patient.
2015 Edition EHR Certification Criterion
    Sec.  170.315(a)(17) (Patient-specific education resources)
Gap Certification Status
    Ineligible

    We propose to adopt a 2015 Edition ``patient-specific education 
resources'' certification criterion that revises the 2014 Edition 
version in three ways. Our first proposal is to adopt this 
certification without the requirement that EHR technology be capable of 
electronically identifying patient-specific education resources based 
on ``laboratory values/results.'' We understand from stakeholder 
feedback on the 2014 Edition version of this criterion that the 
Infobutton standard cannot support this level of data specificity, and 
we do not expect EHR technology developers to develop an alternative 
method that could electronically identify patient-specific education 
resources based on laboratory values/results. Our second proposal is to 
adopt the HL7 Implementation Guide: Service-Oriented Architecture 
Implementations of the Context-aware Knowledge Retrieval (Infobutton) 
Domain, Release 1, August 2013. This is the updated IG of the Draft 
Standard for Trial Use (DSTU) version we adopted for the 2014 Edition 
``patient-specific education resources'' certification criterion. To 
clearly distinguish this IG in the regulation text from the DSTU 
version, we propose a technical amendment to Sec.  170.204(b)(2) to 
note that the version is the DSTU version. Finally, our third proposal 
is to revise the regulation text to be more consistent with the intent 
and interpretation of the 2014 Edition certification criterion 
regulation text we expressed in the 2014

[[Page 10894]]

Edition final rule.\29\ The text of the 2015 Edition certification 
criterion makes clear that the EHR technology must demonstrate the 
capability to electronically identify patient-specific education 
resources using Infobutton and an alternative method that does not rely 
on Infobutton. To note, we propose that the guidance we provided in FAQ 
40 \30\ would still be applicable to the 2015 Edition ``patient-
specific education resources'' certification criterion.
---------------------------------------------------------------------------

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

    We request comment on whether we should adopt a different approach 
related to the methods EHR technology uses to electronically identify 
patient-specific education resources for the 2015 Edition, a potential 
2017 Edition ``patient-specific education resources'' certification 
criterion, or both. The 2014 Edition and the proposed 2015 Edition EHR 
certification criteria require EHR technology to demonstrate the 
capability to electronically identify for a user patient-specific 
education resources using Infobutton and an alternative method. We seek 
comment on whether we should: (1) Maintain this approach; (2) require 
EHR technology to demonstrate only the use of Infobutton, but permit 
EHR technology to be certified to other methods upon an EHR technology 
developer's request for the purpose of an EP, EH, or CAH being able to 
use the alternative certified method for MU (to count such use toward 
meeting the measure); or (3) certify only the use of Infobutton and 
consult with CMS regarding a meaningful use policy change that would 
permit the use of any method (certified or not) to electronically 
identify patient-specific education resources, provided that the EP, 
EH, or CAH has EHR technology certified to perform the Infobutton 
capability.
    We also seek comment on whether we should require that EHR 
technology be capable of providing patient-specific education resources 
in a patient's preferred language in the 2015 Edition, in a potential 
2017 Edition certification criterion, or in both.
 Electronic Medication Administration Record
MU Objective
    Automatically track medications from order to administration using 
assistive technologies in conjunction with an electronic medication 
administration record (eMAR).
2015 Edition EHR Certification Criterion
    Sec.  170.315(a)(18) (Inpatient setting only--electronic medication 
administration record)
Gap Certification Status
    Eligible

    We propose to adopt a 2015 Edition certification criterion that is 
the same as the 2014 Edition version.
 Advance Directives
MU Objective
    Record whether a patient 65 years old or older has an advance 
directive.
2015 Edition EHR Certification Criterion
    Sec.  170.315(a)(19) (Inpatient setting only--advance directives)
Gap Certification Status
    Eligible

    We propose to adopt a 2015 Edition certification criterion that is 
the same as the 2014 Edition version.
 Implantable Device List
MU Objective
    N/A
2015 Edition EHR Certification Criterion
    Sec.  170.315(a)(20) (Implantable Device List)
Gap Certification Status
    Ineligible

    We propose to adopt a new 2015 Edition certification criterion that 
would require EHR technology to be able to record and display a unique 
device identifier (UDI) \31\ and other information about a patient's 
implantable devices. This proposed certification criterion represents a 
first step towards enabling EHR technology to facilitate the widespread 
capture and use of UDI data to prevent device-related medical errors, 
improve the ability of hospitals and clinicians to respond to device 
recalls and device-related patient safety information, and achieve 
other important patient safety and public health benefits consistent 
with the fundamental aims of the HITECH Act \32\ and the July 2, 2013 
HHS Health Information Technology Patient Safety Action and 
Surveillance Plan.\33\
---------------------------------------------------------------------------

    \31\ A UDI is a unique numeric or alphanumeric code that 
consists of two parts: (1) A device identifier (DI), a mandatory, 
fixed portion of a UDI that identifies the labeler and the specific 
version or model of a device, and (2) a production identifier (PI), 
a conditional, variable portion of a UDI that identifies one or more 
of the following when included on the label of a device: The lot or 
batch number within which a device was manufactured; the serial 
number of a specific device; the expiration date of a specific 
device; the date a specific device was manufactured; the distinct 
identification code required by 21 CFR Sec.  1271.290(c) for a human 
cell, tissue, or cellular and tissue-based product (HCT/P) regulated 
as a device. http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/UniqueDeviceIdentification/.
    \32\ Specifically, the certification criteria supports the 
National Coordinator's responsibility under the HITECH Act to ensure 
that the nation's health IT infrastructure supports activities that 
``reduce[] medical errors,'' ``improve[] health care quality,'' 
``improve[] public health activities,'' and ``facilitate[] the early 
identification and rapid response to public health threats and 
emergencies . . . .'' 42 U.S.C. Sec.  300jj-11(b)(2) & (7).
    \33\ Available at http://www.healthit.gov/policy-researchers-implementers/health-it-and-patient-safety. The first objective of 
the Health IT Patient Safety Plan is to ``use health IT to make care 
safer.'' See id. at 7. The Plan specifically contemplates that ONC 
will update its standards and certification criteria to improve 
safety-related capabilities and add new capabilities that enhance 
patient safety.
---------------------------------------------------------------------------

    FDA issued the Unique Device Identification System Final Rule on 
September 24, 2013.\34\ This FDA rule implements a statutory directive 
to establish a ``unique device identification system'' for medical 
devices that will enable adequate identification of devices through 
distribution and use.\35\ It accomplishes this objective by requiring 
that a UDI be included on the label of most medical devices distributed 
in the United States. In addition, for each device with a UDI, a 
standard set of identifying elements will be publicly available through 
the FDA's Global Unique Device Identification Database (GUDID).\36\ FDA 
is scheduled to fully implement the UDI system for devices that are 
implantable, life-saving, and life sustaining by September 2015.\37\
---------------------------------------------------------------------------

    \34\ 78 FR 58786.
    \35\ 21 U.S.C. Sec.  360i(f).
    \36\ The FDA's draft guidance on the GUDID is available at 
http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/UniqueDeviceIdentification/.
    \37\ Pursuant to 21 U.S.C. Sec.  360i(f), FDA must implement the 
Unique Device Identification System Final Rule with respect to 
devices that are implantable, life-saving, and life sustaining not 
later than two years after the rule was finalized. Other 
implementation and compliance dates are detailed in the final rule.
---------------------------------------------------------------------------

    We believe that EHR technology will play a key role in the 
widespread adoption and utilization of UDIs and that its use of UDIs 
can help reduce device-related medical errors and provide other 
significant patient safety, health care quality, and public health 
benefits. Specifically, EHR technology could be leveraged in 
conjunction with automated identification and data capture (AIDC) 
technology or other technologies to streamline the capture and exchange 
of UDIs and associated device data in clinical and administrative 
workflows. Moreover, patients' UDI data in EHR technology could pave 
the way for new CDS and help health care providers more rapidly and 
accurately identify a patient's devices and key information about the 
safe and effective use of such devices. Further, EHR technology could 
facilitate better and more accurate reporting of adverse events and 
other information to reporting systems and registries and

[[Page 10895]]

enable more effective corrective and preventative action in response to 
device recalls and alerts and other device-related information related 
to patient safety.\38\
---------------------------------------------------------------------------

    \38\ These and other potential benefits of UDIs and the UDI 
system established by FDA are described in detail in the Unique 
Device Identification System Notice of Proposed Rulemaking, 77 FR 
40736.
---------------------------------------------------------------------------

    We recognize that additional standards and technical specifications 
will be required to support the full range of capabilities contemplated 
above. Indeed, efforts to identify or develop these standards are 
already underway.\39\ Nevertheless, we believe that it is both feasible 
and important for EHR technology developers to begin implementing at 
least the baseline functionality necessary to capture, store, and 
retrieve UDIs and other contextually relevant information associated 
with a patient's medical devices, specifically implantable devices. By 
their nature, these devices cannot be inspected with the naked eye and 
are more susceptible to misidentification, which can result in patient 
harm. Moreover, once a device is implanted, it is separated from its 
UDI, which is attached only to the device's labeling and not directly 
marked on the device itself. Under the FDA's accelerated implementation 
timeline, UDIs will be available for all implantable devices no later 
than September 2015.
---------------------------------------------------------------------------

    \39\ For example, the HL7 Technical Steering Committee has 
initiated a UDI Task Force to ensure that UDI is implemented in a 
consistent and interoperable manner across the suite of HL7 
standards. See http://hl7tsc.org/wiki/index.php?title=TSC_Minutes_and_Agendas. FDA is collaborating with the Engelberg Center for 
Health Care Reform at the Brookings Institute to develop a roadmap 
for the successful adoption and implementation of UDI throughout the 
healthcare system. See http://www.brookings.edu/about/centers/health/projects/development-and-use-of-medical-devices/udi. AHRQ has 
incorporated UDI and associated data attributes in its Common 
Formats for adverse event reporting. See http://www.pso.ahrq.gov/formats/brochurecmnfmt.htm . Also see AHRQ Data Dictionary, Common 
Formats Hospital Version 1.2, at 87, available at https://www.psoppc.org/c/document_library/get_file?p_l_id=375680&folderId=431263&name=DLFE-15061.pdf. Through an S&I 
Framework Structured Data Capture Initiative, ONC, FDA, and other 
stakeholders are pursuing the inclusion of UDI data in FDA adverse 
event reporting. See http://wiki.siframework.org/Structured+Data+Capture+Initiative. The inclusion of UDI data in FDA 
adverse event reporting is being pursued through an ONC S&I 
Framework Structured Data Capture Initiative, see http://wiki.siframework.org/Structured+Data+Capture+Initiative.
---------------------------------------------------------------------------

    We propose to adopt a 2015 Edition certification criterion focused 
on EHR technology's ability to record UDI information about implantable 
devices. More specifically, EHR technology would have to enable a user 
to electronically record the UDI of an implantable device and other 
relevant information (such as a procedure note or additional 
information about the device) as part of a patient's ``implantable 
device list.'' EHR technology would also be required to allow a user to 
electronically access and view a patient's list of UDIs and other 
relevant information associated with a patient's implantable devices. 
In addition, the EHR technology would need to be able to parse the UDI 
in order to extract and allow a user to view the ``device identifier'' 
and ``production identifier'' portions of the UDI. The purpose of this 
requirement is to ensure that a user will be able to use the device 
identifier to manually retrieve associated data elements from an 
authoritative source based on the GUDID, once available and, similarly, 
to ensure that a user will be able to manually use the production 
identifier in the event of a device recall. We expect that EHR 
technology would be able to automate these processes once appropriate 
standards and technical specifications are developed.
    As previously indicated, we believe EHR technology should also 
facilitate the UDI's exchange in order to increase the overall 
availability and reliability of information about patients' implants 
and other devices. Thus, we propose to reference ``the UDI(s) for a 
patient's implantable device(s)'' in the following proposed 2015 
Edition EHR certification criteria which also propose the adoption of 
the newest version of the Consolidated CDA.\40\ We understand that this 
data can already be accommodated in the current Consolidated CDA 
version and is best placed in the ``Product Instance'' data element 
which is part of the Procedures template (see section 5.65 of the 
current Consolidated CDA version adopted at 45 CFR 170.205(a)(3) and 
incorporated by reference at 45 CFR 170.299(f)(8)). We seek comment 
from Consolidated CDA experts on whether there is a better location to 
place this information so that we may provide updated guidance in a 
final rule or FAQ. For clarity and context purposes each impacted 
proposed certification criterion will include a reminder about our 
proposal here. However, to reduce redundancy, this proposal and its 
rationale serves as the basis for the UDI's inclusion in each of those 
criteria.
---------------------------------------------------------------------------

    \40\ This version is Release 2 of the Draft Standard for Trial 
Use, which is discussed in further detail under the 2015 Edition 
``transitions of care'' certification criterion.
---------------------------------------------------------------------------

     170.315(b)(1)--Transitions of care.
     170.315(b)(6)--Data portability.
     170.315(e)(1)--View, download, and transmit to third 
party.
     170.315(e)(2)--Clinical summary.
    We have also proposed elsewhere in this Proposed Rule to modify 
Sec.  170.102 to include new definitions for ``implantable device,'' 
``unique device identifier,'' ``device identifier,'' and ``production 
identifier.'' This will prevent any interpretation ambiguity and ensure 
that each term's specific meaning reflects the same meaning given to 
them in the Unique Device Identification System Final Rule and in 21 
CFR 801.3.
    We seek public comment on additional EHR technology capabilities we 
are considering including as part of the 2017 Edition rulemaking. Based 
on stakeholder input and in consultation with FDA, we believe that the 
following EHR technology capabilities could help achieve our stated 
objectives:
     Record a minimum set of data elements for each UDI in a 
patient's implantable device list, including:
    [cir] Labeler Name (Manufacturer);
    [cir] Brand Name;
    [cir] Version or Model;
    [cir] Global Medical Device Nomenclature Name;
    [cir] Single Use indicator;
    [cir] Labeled as containing natural rubber latex or dry natural 
rubber; and
    [cir] MRI Safety Status.
     Accept electronic UDI data via automatic identification 
and data capture (AIDC) or other assistive technologies used in health 
care systems (e.g., bar code scanners and radio frequency 
identification).
     Use the device identifier portion of the UDI to obtain and 
incorporate GUDID device identification attributes in the patient's 
implantable device list.
     Use the device identifier or production identifier 
portions of the UDI to generate lists of patients with a particular 
implantable device.
     Make a UDI and its associated identification attributes 
accessible to the EHR technology for reporting purposes (e.g., adverse 
event reporting, registry population, recalls).
     Exchange a UDI and UDI data with procedure reporting 
systems (including adverse event incident reporting systems and medical 
specialty reporting systems) and other systems that associate a patient 
with a device.
     Expand these and other capabilities to additional types of 
devices used by patients.
    We solicit comment on whether to propose these capabilities (or a 
subset thereof) for adoption in a subsequent rulemaking. We also 
request comment on other standards, capabilities, or certification 
criteria that we have not

[[Page 10896]]

identified but that would further our stated aims. Finally, we 
specifically seek input on the list of data elements that we have 
identified and whether we should propose these or other data elements 
in connection with this criterion.

 Transitions of Care
MU Objective
    The EP, EH, or CAH who transitions their patient to another setting 
of care or provider of care or refers their patient to another provider 
of care should provide summary care record for each transition of care 
or referral.
2015 Edition EHR Certification Criteria
    Sec.  170.315(b)(1) (Transitions of care)
Gap Certification Status
    Ineligible

    We propose to adopt a single 2015 Edition certification criterion 
for ``transitions of care'' (ToC). This proposed criterion would 
include significant modifications when compared to the two related 2014 
Edition criteria adopted in the 2014 Edition Final Rule. This proposed 
criterion also reflects corresponding structural and clarifying changes 
that we have made to the proposed 2015 Edition ``clinical information 
reconciliation and incorporation'' certification criterion (discussed 
right after this criterion) and to the ``view, download, transmit to 
third party (VDT)'' certification criterion.
    Our overall rationale for these proposed modifications is three-
fold: 1) to further improve interoperability for ToC; 2) to improve the 
market availability of certified electronic exchange services for 
transport (and, thus, increase EPs, EHs, and CAHs' abilities to choose 
such services to demonstrate MU) by decoupling the 2014 Edition's ToC 
requirement to demonstrate both ``content'' and ``transport'' 
capabilities together in order to meet the two ToC certification 
criteria; and 3) to make the work-flow sequence we had in mind when we 
drafted the 2014 Edition criterion (at 45 CFR 170.314(b)(1)) clearer.
    Interoperability for ToC is one of ONC's top priorities. ONC 
follows the definition of ``interoperability'' provided by the 
Institute for Electrical and Electronics Engineering Computer 
Dictionary which defines interoperability to mean: ``the ability of two 
or more systems or components to exchange information and to use the 
information that has been exchanged.'' \41\ With the adoption of a 
single content standard (Consolidated CDA) and ``transport''/
transmission standards as part of the 2014 Edition ToC certification 
criteria as well as the requirement that all EHR technology be 
certified to support transmissions in accordance with the Applicability 
Statement for Secure Health Transport (the primary Direct Project 
specification),\42\ we made significant strides toward this definition.
---------------------------------------------------------------------------

    \41\ See IEEE Standard Computer Dictionary: A Compilation of 
IEEE Standard Computer Glossaries (New York, NY: 1990).
    \42\ http://wiki.directproject.org/file/view/Applicability+Statement+for+Secure+Health+Transport+v1.1.pdf.
---------------------------------------------------------------------------

    With that in mind, the 2014 Edition certification criteria and 
corresponding MU Stage 2 measures have generated a significant amount 
of questions, requests for clarifications, and feedback related to how 
the ToC certification requirements could be improved in light of on-
the-ground experience and challenges. We have reviewed and considered 
all of this feedback since the 2014 Edition Final Rule and now propose 
a suite of changes that we believe will address stakeholder concerns as 
well as enhance interoperability for this priority use case.
``Decoupling'' Content and Transport
    In the 2014 Edition Final Rule, we adopted two ToC certification 
criteria. The first, Sec.  170.314(b)(1), requires EHR technology to be 
able to ``receive, display, and incorporate'' transition of care/
referral summaries. The second, Sec.  170.314(b)(2), requires EHR 
technology to be able to ``create and transmit'' transition of care/
referral summaries.
    These two 2014 Edition certification criteria require that EHR 
technology be able to ``receive'' and ``transmit'' a Consolidated CDA 
(``transition of care/referral summary'') in accordance with the 
Applicability Statement for Secure Health Transport (the primary Direct 
Project specification). Beyond the required transport standard (the 
primary Direct Project specification), we also included the option for 
EHR technology to be tested and certified to two other transport 
capabilities (i.e., Direct +XDR/XDM and SOAP + XDR/XDM).
    As we indicated at the beginning of the preamble, the ``scope'' of 
a certification criterion begins at the second paragraph level of the 
regulatory section and encompasses all paragraph levels below the 
second paragraph level. Therefore, all capabilities under Sec.  
170.314(b)(1) and (b)(2)--including the transmission capabilities--must 
be demonstrated to meet each criterion as a whole. This means that 
under the 2014 Edition there is no way for EHR technology to be 
certified solely to perform the transport capabilities specified in 
each criterion.
    Since the 2014 Edition Final Rule's publication, ONC has received 
specific feedback that this constraint or the ``binding'' of transport 
and content capabilities within the scope of a single certification 
criterion could impede innovation and limit EPs, EHs, and CAHs' market 
choices for electronic health information exchange services. 
Stakeholders also indicated that we had incorrectly imposed the 
coupling of technical capabilities that can be adequately performed by 
two different systems. They stated that content capabilities and 
transport capabilities should be separately tested and certified as the 
standard that supports one may change over time while the other remains 
the same.
    This issue is best illustrated by the requirement in both 2014 
Edition ToC criteria that EHR technology demonstrate its conformance to 
the primary Direct Project specification. As shown in the figure below, 
the primary Direct Project specification is not an ``end-to-end'' 
specification. Rather, the primary Direct Project specification is 
applicable to capabilities that are typically performed by what are 
called Health Information Service Providers or

[[Page 10897]]

HISPs. At times, an EHR technology may be designed with fully 
integrated HISP functions, but it is equally likely that third-party 
intermediaries will perform these capabilities. As a result, our 2014 
Edition ToC criteria have resulted in HISP functionality being built 
into EHR technology (or, conversely, EHR functionality being built into 
a HISP solely for the HISP to meet the certification criteria).
     Figure 1: The primary Direct Project specification's 
applicability.
[GRAPHIC] [TIFF OMITTED] TP26FE14.000

    We agree with stakeholder feedback that we should enable transport 
capabilities to be tested and certified separately from content 
capabilities. We also believe that permitting separate testing and 
certification for these capabilities would enable more transport-
specific services to be certified as EHR Modules and, thus, would 
provide EPs, EHs, and CAHs with more choices in terms of the electronic 
health information exchange services they can use to demonstrate MU. 
Accordingly, we propose to adopt a single 2015 ToC certification 
criterion that focuses on content capabilities (create, receive, and 
display) and an EHR technology's ability to connect to a service that 
is conformant with the primary Direct Project specification through the 
use of a newly developed, ``ONC Implementation Guide for Direct Edge 
Protocols, Version 1.0, January 10, 2014'' (IG for Direct Edge 
Protocols),\43\ which we propose to adopt at Sec.  170.202(e). This 
proposal, in addition to our proposed revisions to the Base EHR 
definition to reference the 2015 Edition, continues to maintain and 
reinforce our overall policy that Certified EHR Technology must be able 
to perform transmissions in accordance with the primary Direct Project 
specification. The difference is that it enables transport capabilities 
to be separately tested and certified and separately implemented by 
EPs, EHs, and CAHs as a means to meet the Certified EHR Technology 
definition. We discuss our specific ``transmission'' certification 
criteria later in the preamble and our proposal to include them in a 
new regulatory paragraph ``(h)'' within Sec.  170.315.
---------------------------------------------------------------------------

    \43\ http://wiki.directproject.org/file/detail/Implementation+Guide+for+Direct+Edge+Protocols+v1.0.pdf.
---------------------------------------------------------------------------

Edge Protocol for EHR to HISP Connectivity for ``Direct'' Transmissions
    As illustrated by Figure 1 and the arrows labeled with ``edge,'' 
the primary Direct Project specification focuses on HISP-to-HISP 
transactions and not on EHR-to-HISP transactions. Since the 2014 
Edition Final Rule, the stakeholder community that participates in the 
Direct Project has produced a new implementation guide to clarify for 
EHR technology developers the standardized protocols that should be 
used to connect to a HISP (i.e., EHR-to-HISP).
    This new implementation guide specifies that both a ``Direct Edge 
System'' (i.e., EHR technology) and a ``Direct HISP System'' must 
support at least one of the following protocols: IMAP4, POP3, SMTP, or 
IHE XDR.
    While we propose a separate certification criterion for conformance 
to the primary Direct Project specification, we seek to maintain the 
same policy outcome we set in the 2014 Edition (i.e., that every EHR 
technology certified to ToC is capable of performing transmissions in 
accordance with the primary Direct Project specification). As a result, 
we propose that the 2015 Edition ToC certification criterion specify 
that EHR technology demonstrate it can send and receive transition of 
care/referral summaries in a transmission--that conforms to the IG for 
Direct Edge Protocols--which is used by a service that has implemented 
the primary Direct Project specification.
    In other words, testing and certification to this portion of 
proposed 2015 Edition ToC certification criterion would require that 
EHR technology be able connect to a HISP following the IG for Direct 
Edge Protocols and enable that HISP to subsequently transmit the 
transition of care/referral summary using the primary Direct Project 
specification to a recipient. We emphasize that while the standard 
adopted at Sec.  170.202(a) is still referenced in this proposed 
criterion, its reference is to solely express the technical outcome we 
expect to be demonstrated by EHR technology--that a transmission from 
EHR-to-HISP is successful in that the HISP can subsequently transmit 
the transition of care/referral summary. Again, these proposed 
revisions are to make clear that as a result of our proposal, we would 
no longer require testing and certification to the primary Direct 
Project specification as a condition of meeting this certification 
criterion.
Updated Consolidated CDA Standard
    As expressed in the 2014 Edition Final Rule, the Consolidated CDA 
standard is now the single standard permitted for certification and the 
representation of summary care records. It is referenced in four 
proposed 2015 Edition certification criteria (ToC, VDT, Clinical 
Summary, Data Portability). Industry stakeholders have continued to 
work to improve and refine the Consolidated CDA standard since the 2014 
Edition Final Rule.\44\ An updated version, HL7 Implementation Guide 
for CDA[supreg] Release 2: Consolidated CDA Templates for Clinical 
Notes (US Realm), Draft Standard for Trial Use, Release 2.0,\45\ was 
balloted in August and September 2013. A reconciliation of comments 
received during balloting will be completed prior to the issuance of a 
final rule for this proposed rule. The currently balloted version 
includes the following changes which we believe provide important 
clarifications and enhancements:
---------------------------------------------------------------------------

    \44\ http://wiki.siframework.org/Companion+Guide+to+Consolidated+CDA+for+MU2.
    \45\ Access to the standard can be found at the following link, 
which requires the creation of an HL7 account: http://www.hl7.org/documentcenter/public/ballots/2013SEP/downloads/CDAR2_IG_CCDA_CLINNOTES_DSTUR2_D1_2013SEP.zip.
---------------------------------------------------------------------------

     Addition of new structural elements: new document sections 
and data entry templates:
    [cir] New Document Templates for: Care Plan; Referral Note; 
Transfer Summary.
    [cir] New Sections for: Goals; Health Concerns; Health Status 
Evaluation/Outcomes; Mental Status; Nutrition; Physical Findings of 
Skin.
    [cir] New organizers and many new entries (e.g. Wound Observation).
     Some sections/entries were deprecated (i.e., not in use 
any longer).

[[Page 10898]]

     Updates to (versioning of) template/section/entry object 
identifiers (OIDs).
    [cir] This includes new chapter describing HL7's approach to 
template versioning.
     Tighter data constraints/requirements.
    [cir] For example, some data elements with a ``MAY'' requirement 
now have a ``SHOULD'' requirement. Likewise, some with a ``SHOULD'' 
requirement now have a ``MUST'' requirement.
     Updated Vocabulary/Value Set constraints.
    [cir] For example: two SNOMED CT codes were added to Current 
Smoking Status value set and Tobacco Use value set to support the 2014 
Edition vocabulary requirements for patient smoking status.
    [cir] NLM's VSAC was named as reference for Value Sets used in 
CCDA.
    Accordingly, we propose to adopt the updated Consolidated CDA 
standard in Sec.  170.205(a)(4) and we propose to reference its use in 
the proposed 2015 Edition ToC certification criterion as well as the 
three other certification criteria previously mentioned. We also 
propose to require (for reasons already provided as part our proposal 
for the ``implantable device list'' certification criterion) that EHR 
technology must be capable of including the UDI(s) for a patient's 
implantable device(s) as data within a created Consolidated CDA 
formatted document.
Shifting ``Incorporation'' From ToC to Clinical Information 
Reconciliation
    The 2014 Edition ToC certification criterion at Sec.  
170.314(b)(1)(A) and (B) requires EHR technology to demonstrate 
``[u]pon receipt of a transition of care/referral summary formatted 
according to the standard adopted at Sec.  170.205(a)(3)'' that it can 
properly match the transition of care/referral summary received to the 
correct patient; and electronically incorporate medications, problems, 
and medication allergy data. At the beginning of the 2014 Edition Final 
Rule we responded to comments on our proposed description for 
``incorporate'' (77 FR 54168-54169) and stated that, ``[w]e had revised 
our description of incorporation to reflect the common interpretation 
commenters stated they assigned to the term. Thus, when the term 
incorporate is used within a certification criterion it is intended to 
mean to electronically process structured information from another 
source such that it is combined (in structured form) with information 
maintained by EHR technology and is subsequently available for use 
within the EHR technology by a user.''
    We also responded to comments on this issue at 77 FR 54218 and 
offered a more nuanced response in the context of the 2014 Edition ToC 
certification criterion at Sec.  170.314(b)(1) and the clinical 
information reconciliation certification criterion at Sec.  
170.314(b)(4):

    [A]s we clarified in the beginning of this final rule, we 
intended for the term ``incorporate'' to mean that EHR technology 
would be able to process the structured data contained in those 
three Consolidated CDA sections (medications, problems, medication 
allergies) such that it could be combined (in structured form) with 
data already maintained by EHR technology and would subsequently be 
available for use, such as to be used as part of the clinical 
information reconciliation capabilities (expressed in the 
certification criterion adopted at (Sec.  170.314(b)(4)).

    Stakeholders have indicated confusion regarding this preamble 
explanation and questioned the workflow assumption we had in mind when 
placing the ``incorporation'' capability in the ToC certification 
criterion. They indicated that in a typical workflow, inbound data is 
first reconciled and then incorporated (which makes it subsequently 
available for use within the EHR technology). Thus, our explanation 
that incorporated information as part of the ToC certification 
criterion would ``subsequently be available for use, such as to be used 
as part of the clinical information reconciliation capabilities'' 
misstated the workflow.
    To avoid future confusion, the proposed 2015 Edition ToC 
certification no longer references the 2014 Edition's ``incorporation'' 
capabilities at Sec.  170.314(b)(1)(A) and (B) and instead, we propose 
to place those capabilities in the proposed 2015 Edition ``clinical 
information reconciliation and incorporation'' certification criterion. 
We believe this revision will clarify the interplay between these two 
certification criteria and will clear up any misconceptions about the 
anticipated workflow. The specific capabilities for ``section views'' 
expressed at Sec.  170.314(b)(1)(C) would continue to remain as part of 
our proposed 2015 Edition ToC criterion because they focus on content 
capabilities.
ToC Interoperability and MU Stage 2 ``Cross-Vendor'' Exchange Proposals
    As part of the EHR Incentive Programs Stage 2 proposed rule, CMS 
proposed a new measure for its ``Transitions of Care objective'' that 
would have limited the new measure's numerator to only permit 
electronic transmissions to count if they were made to recipients that 
were: ``(1) Not within the organization of the transmitting provider; 
and (2) did not have Certified EHR Technology from the same EHR 
vendor'' (77 FR 13724). This proposal sought to use the EHR Incentive 
Programs to reward this outcome and, by virtue of setting this outcome, 
give EPs, EHs, and CAHs as well as EHR technology developers an 
explicit reason to implement solutions that promote interoperable 
electronic health information exchange.
    Public comment on these proposals raised numerous concerns, 
including (among other issues) geographic market share constraints and 
undue burden because both limitations would be hard to do determine in 
an automated way. In response, CMS ultimately decided not to retain 
either of the proposed numerator limitations (77 FR 54019). CMS did, 
however, adopt a third ToC measure for MU Stage 2 that requires EPs, 
EHs, and CAHs to ``conduct one or more successful electronic exchanges 
of a summary of care document, which is counted in measure 2 with a 
recipient who has EHR technology designed by a different EHR technology 
developer than the sender's EHR technology certified to 45 CFR 
170.314(b)(2); or conduct one or more successful tests with the CMS 
designated test EHR during the EHR reporting period.''
    While the measurement burden associated with the ``cross vendor'' 
numerator limitation proved too difficult a concept to implement, we 
have continued to consider ways to reach this same outcome. First, we 
keep in mind that the proposed cross-vendor numerator limitation was 
imposed on the ``sender.'' The sender, upon transmission of a summary 
care record, would need to know if the recipient had a different EHR 
technology developer's product than they did in order to determine 
whether that transmission could be counted in the numerator. Second, we 
considered solutions. One theoretical solution we considered would be 
to automate the sender's measurement. This would require EHR technology 
(through certification) to send an acknowledgement with the EHR 
technology developer's name or other identifier upon receipt of a 
summary care record. This ``solution,'' however, would require 
modifications to existing technical standards and would be insufficient 
(and really a partial solution) because EPs, EHs, and CAHs, can (today) 
electronically transmit summary care records to non-MU providers for 
ToC and count such transmissions in their numerator. Thus, health care 
providers who have no incentive to adopt CEHRT would not necessarily 
have the capability to

[[Page 10899]]

respond with this kind of acknowledgement and there would still be 
situations where EPs, EHs, and CAHs would have to manually count 
transmissions.
    As we took a step back to assess this proposal's viability, we 
realized its purpose would be to solve a measurement problem and not an 
interoperability problem. Thus, we reassessed the true ``problem'' we 
(ONC) were trying to solve--interoperability--and, more specifically, 
the ``use'' aspect of the interoperability definition we follow. Given 
that our 2014 Edition ToC certification criteria require EHR technology 
to be able to receive and transmit Consolidated CDAs in accordance with 
the primary Direct Project specification, EPs, EHs, and CAHs will have 
the ability to ``exchange'' with any other EHR technology. However, it 
remains unclear whether each individual EP, EH, or CAH will be able to 
effectively use the Consolidated CDA it receives. While the 
Consolidated CDA is the only standard we permit for summary care record 
creation, its specifications permit a certain level of optionality and 
variability. As a result, while two different certified EHR 
technologies can accomplish ``exchange'' with a validly implemented 
Consolidated CDA, the recipient may be unable to correctly or 
accurately parse a part or all of the Consolidated CDA. Early feedback 
from a handful of stakeholders has indicated that such events do occur.
    We believe that EHR technology certification can improve this 
aspect of interoperability and, in turn, get us closer to the ultimate 
outcome that was intended by the original MU Stage 2 proposal--which is 
that an EP, EH, or CAH could both exchange a Consolidated CDA with any 
other EHR technology and be able to subsequently use the Consolidated 
CDA it receives. This is a fundamental capability needed beyond MU and 
will be critical to help advance delivery reform goals. Achieving this 
interoperability goal also closes a gap that meaningful use policy is 
not well positioned to impact (i.e., the capabilities of a recipient of 
electronically transmitted health information).
    To do this, we propose to adopt a ``performance standard'' that 
would require EHR technology to successfully electronically process 
validly formatted Consolidated CDAs no less than 95% of the time. Note 
that this creates different capability requirements for certification 
within this criterion for ``receive'' than it does for the capabilities 
associated with creation of a Consolidated CDA for transmission. In 
other words, for certification, EHR technology would be permitted to 
create a Consolidated CDA that conformed to a particular and acceptable 
variation of the Consolidated CDA standard (given the optionality in 
the standard). However, for receipt of Consolidated CDAs, EHR 
technology would need to be able to receive no less than 95% of all of 
the possible variations that could be implemented under the standard. 
We also clarify that this performance standard's scope would be limited 
to the Consolidated CDAs' implementation of the data we require in this 
certification criterion (i.e., testing for the performance standard 
would not go beyond the header requirements and specific data required 
by the certification criterion). This proposed outcome has the effect 
of requiring EHR technology to be resilient when it comes to receiving 
Consolidated CDAs that have been configured differently (i.e., able to 
handle differently formatted Consolidated CDA without failing). While 
it is not unreasonable (from a user's perspective) to expect their EHR 
technology to perform with 99% or greater accuracy when it comes to 
processing Consolidated CDAs, we believe that 95% would be an 
appropriate initial performance threshold to adopt while still ensuring 
that users are not adversely impacted by poor performance. As discussed 
in the S&CC January 2010 interim final rule (75 FR 2021), we defined 
the term ``standard'' in 45 CFR 170.102 and stated, ``[w]e believe the 
types of standards envisioned by Congress in the HITECH Act that would 
be most applicable to HIT are standards that are technical, functional, 
or performance-based.''
    Accordingly, we propose to adopt this new performance standard in 
section 212 of part 170 entitled ``Performance Standards for Health 
Information Technology.'' Further, we propose to reference this 
performance standard in the proposed 2015 Edition ToC certification 
criterion as a capability that must be demonstrated to meet the 
certification criterion.
    We seek comment on whether the performance level should be set to 
95% and request that commenters provide accompanying rationale for why 
it should be lower or higher. Further, our early thoughts around the 
testing approach for this part of the certification criterion are that 
it would involve EHR technology receiving some number of Consolidated 
CDAs (e.g., 100 to 1000) each formatted slightly (but validly) 
differently, or produced by different EHR technologies previously 
through testing, or both. Given that testing could be conducted in 
numerous different ways, we seek input on and suggestions on the best 
way(s) to test this proposal. We also seek input from industry 
stakeholders on the best ways to identify additional guidance for the 
Consolidated CDA that will further reduce its implementation 
variability and, ultimately, make achieving this performance standard 
simply a byproduct of implementing a tightly specified implementation 
guide.
    While there is still a risk that EHR technology developers could 
deploy electronic transmission capabilities in ways that continue to 
make it difficult for EPs, EHs, and CAHs to exchange Consolidated CDAs 
with EHR technologies designed by different EHR technology developers, 
we believe that this proposal in combination with potential future 
proposals in MU to increase electronic exchange requirements can 
achieve the overall outcome EPs, EHs, and CAHs expect--that they will 
be able to exchange summary care records and upon receipt be able to 
use them without additional burden.
``Create'' and Patient Matching Data Quality
    In 2011, both the HITPC and HITSC made recommendations to ONC on 
patient matching. The HITPC made recommendations in the following five 
categories: Standardized formats for demographic data fields, 
internally evaluating matching accuracy, accountability, developing, 
promoting and disseminating best practices, and supporting the role of 
the individual/patient.\46\ The HITSC made four recommendations: 
Detailing patient attributes that could be used for matching (in order 
to understand the standards that are needed), data quality, formats for 
these data elements, and what data are returned from a match 
request.\47\ The standards recommended by the HITSC are as follows:
---------------------------------------------------------------------------

    \46\ http://www.healthit.gov/sites/default/files/hitpc-transmittal-letter-priv-sectigerteam-020211.pdf.
    \47\ http://www.healthit.gov/FACAS/sites/default/files/standards-certification/8_17_2011Transmittal_HITSC_Patient_Matching.pdf.
---------------------------------------------------------------------------

     Basic Attributes: Given Name; Last Name; Date of Birth; 
Administrative Gender.\48\
---------------------------------------------------------------------------

    \48\ Despite its inclusion of the word ``gender,'' 
``Administrative Gender'' is generally used in standards to 
represent a patient's ``sex'' as male, female, or undifferentiated. 
See: http://ushik.ahrq.gov/ViewItemDetails?system=hitsp&itemKey=83680000.
---------------------------------------------------------------------------

     Other Attributes: Insurance Policy Number; Medical Record 
Number; Social Security Number (or last 4 digits); Street Address; 
Telephone Number; Zip Code.

[[Page 10900]]

     Potential Attributes: Email Address; Voluntary 
Identifiers; Facial Images; Other Biometrics.
    In July 2013, ONC launched an initiative to reinvigorate public 
discussion around patient matching, to perform a more detailed analysis 
of patient matching practices, and to identify the standards, services, 
and policies that would be needed to implement the HITPC and HITSC's 
recommendations. Although this initiative's first phase focused on a 
common set of patient attributes that could be leveraged from current 
data and standards referenced in our certification criteria, we 
recognize that additional, broader industry needs exist when it comes 
to methods related to patient matching and the attributes with which 
matching is performed. Some of these broader needs include the ability 
to link patient data across time for a longitudinal record, linking 
across different data sources in a health information exchange 
organization/network, and linking administrative data to clinical data 
for outcomes research. Additionally, new matching techniques that are 
beginning to leverage novel and large data sources suggest that now is 
the right time to review patient matching needs across the industry at 
large and how EHR technology can be one part of the solution.
    Given these initial findings, we propose to include a limited set 
of standardized data as a part of the ``Create'' portion of the ToC 
criterion to improve the quality of the data included in outbound 
summary care records. We seek comment on additional data to include and 
other constraints that could be applied to this data to improve its 
quality. To be clear, this proposal does not require EHR technology to 
capture the data upon data entry, but rather at the point when the data 
is exchanged (an approach commonly used for matching in HL7 
transactions, IHE specifications,\49\ Consolidated CDA (C-CDA) 
specification, and the eHealth Exchange). The proposed standardized 
data include: First name, last name, middle name (or middle initial in 
cases where only it exists/is used), suffix, date of birth, place of 
birth, maiden name, current address, historical address, phone number, 
and sex. Additional feedback we have received suggests that use of data 
elements that do not change over time (e.g., place of birth, maiden 
name) could improve the patient matching results. In the bulleted list 
below, we identify more constrained specifications for some of the 
standardized data we propose. Based on our own research, we do not 
believe that the proposed constraints to these data conflict with the 
Consolidated CDA. That being said, some proposed constraints may 
further restrict the variability as permitted by existing 
specifications and others may create new restrictions that do not 
currently exist within the Consolidated CDA. We propose that:
---------------------------------------------------------------------------

    \49\ http://www.ihe.net/Technical_Frameworks/.
---------------------------------------------------------------------------

     For ``last name/family name'' the CAQH Phase II Core 258: 
Eligibility and Benefits 270/271 Normalizing Patient Last Name Rule 
version 2.1.0 \50\ (which addresses whether suffix is included in the 
last name field) be followed.
---------------------------------------------------------------------------

    \50\ http://www.caqh.org/pdf/CLEAN5010/258-v5010.pdf.
---------------------------------------------------------------------------

     For ``suffix,'' that the suffix should follow the CAQH 
Phase II Core 258: Eligibility and Benefits 270/271 Normalizing Patient 
Last Name Rule version 2.1.0 (JR, SR, I, II, III, IV, V, RN, MD, Ph.D., 
ESQ) \51\ and that if no suffix exists, the field should be marked as 
null.
---------------------------------------------------------------------------

    \51\ http://www.caqh.org/pdf/CLEAN5010/258-v5010.pdf.
---------------------------------------------------------------------------

     For ``date of birth,'' that the year, month and date of 
birth should be required fields while hour, minute and second should be 
optional fields. If hour, minute and second are provided then either 
time zone offset should be included unless place of birth (city, 
region, country) is provided; in the latter local time is assumed. If 
date of birth is unknown, the field should be marked as null.
     For ``current address'' and ``historical address,'' be 
represented in United States Postal Service (USPS) \52\ format. And, if 
a historical address is unavailable, that the value should be entered 
as null.
---------------------------------------------------------------------------

    \52\ http://pe.usps.com/text/pub28/.
---------------------------------------------------------------------------

     For ``phone numbers,'' the ITU format specified in ITU-T 
E.123 \53\ and ITU-T E.164 \54\ be followed and that the capture of 
home, business, and cell phone numbers be allowed.\55\ Further, that if 
multiple phone numbers are present in the patient's record, all should 
be included in the Consolidated CDA and transmitted.
---------------------------------------------------------------------------

    \53\ http://www.itu.int/rec/T-REC-E.123-200102-I/e.
    \54\ http://www.itu.int/rec/T-REC-E.164-201011-I/en.
    \55\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=186.
---------------------------------------------------------------------------

     For ``sex'' we propose to require developers to follow the 
HL7 Version 3 Value Set for Administrative Gender, which includes M 
(Male), (Female) and UN (Undifferentiated) as options.\56\
---------------------------------------------------------------------------

    \56\ http://phinvads.cdc.gov/vads/ViewValueSet.action?oid=2.16.840.1.113883.1.11.1.
---------------------------------------------------------------------------

    We seek comment on the proposed standardized data to improve 
patient matching, including whether other data or constraints on 
proposed data should be modified to better support patient matching 
practices and work flow. For example, stakeholders have suggested that 
using the United States Postal Service (USPS) ``Address Information'' 
application program interface (API) that standardizes addresses as a 
way to ensure addresses are formatted in a consistent manner. While we 
believe this idea has merit, the USPS terms and conditions \57\ 
currently appear to exclude this API's use for this purpose because it 
only permits users to ``use the USPS Web site, APIs and USPS data to 
facilitate USPS shipping transactions only.'' Similarly, we request 
comment on how to best handle or anticipate changes to the way in which 
data may be represented in other rapidly evolving standards approaches. 
For instance, we are aware that V2 and V3 HL7 standards use an 
identical format for date of birth, but the more recent Fast Health 
Interoperable Resources (FHIR) standards framework uses a different 
format. Others have suggested that we need to adopt international 
standards for address, for military purposes or for patients who live 
outside of the U.S., but have health care delivered within the U.S. 
More specifically, USPS expects numbers for ZIP code. Thus, we would be 
interested in stakeholder feedback regarding what standards could best 
support international addresses (for example, ISO 19160-4 \58\ which 
appears on a trajectory to reference/include to Universal Postal Union 
(UPU) S42).\59\
---------------------------------------------------------------------------

    \57\ https://secure.shippingapis.com/registration/.
    \58\ http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=64242.
    \59\ http://www.upu.int/uploads/tx_sbdownloader/sheetAddressingS42InternationalAddressingStandardsFactSheetEn.pdf.
---------------------------------------------------------------------------

    In addition, we seek comment on approaches to address other 
recommendations from the HITSC. For example, data quality is an 
important aspect of patient matching success. We seek comment on 
methods that leverage the certification program, ways to test and 
measure data quality, and approaches to sharing best practices for 
improving data quality.
    Finally, we seek comment on additional findings from the 2013 
Patient Matching Initiative that include studying non-traditional 
attributes to understand the potential for matching improvement, 
developing open source algorithms for testing purposes or use by EHR 
technology developers, the development of a formalized structure for 
establishing best practices, advancing consumer engagement with and 
access to their demographic data

[[Page 10901]]

and attributes for correction or approval, and developing and/or 
disseminating options and training materials that improve data quality.
 Clinical Information Reconciliation and Incorporation
MU Objective
    The EP, EH, or CAH who receives a patient from another setting of 
care or provider of care or believes an encounter is relevant should 
perform medication reconciliation.
2015 Edition EHR Certification Criterion
    Sec.  170.315(b)(2) (Clinical information reconciliation and 
incorporation)
Gap Certification Status
    Ineligible
    We propose to adopt a 2015 Edition certification criterion that 
revises the 2014 Edition version. As discussed in more detail directly 
above in the 2015 Edition ToC certification criterion section Shifting 
``Incorporation'' From ToC to Clinical Information Reconciliation 
``reconciliation'' and ``incorporation'' capabilities were referenced 
in two separate 2014 Edition certification criteria. For the reasons 
discussed in the 2015 Edition ToC section above, we propose that the 
2015 Edition ``clinical information reconciliation and incorporation'' 
certification criterion include the capabilities that are part of the 
2014 Edition ToC certification criterion at Sec.  170.314(b)(1)(A) and 
(B). Again, we believe that this change will make the workflow designed 
to meet this certification criterion clearer.
    We also solicit comment on whether for our 2017 Edition rulemaking 
we should broaden the data that this certification criterion requires 
to be reconciled beyond medications, medication allergies, and problems 
and, if so, what other data we should consider referencing. 
Additionally, we solicit comment on whether EHR technology should be 
required to retain the outside/external data source's provenance as 
part of the incorporation process.
 Electronic Prescribing
MU Objective
    Generate and transmit permissible prescriptions electronically 
(eRx).
2015 Edition EHR Certification Criterion
    Sec.  170.315(b)(3) (Electronic prescribing)
Gap Certification Status
    Eligible
    We propose to adopt a 2015 Edition certification criterion that is 
the same as the 2014 Edition version.
 Incorporate Laboratory Tests and Values/Results
MU Objective
    Incorporate clinical laboratory test results into Certified EHR 
Technology as structured data.
2015 Edition EHR Certification Criterion
    Sec.  170.315(b)(4) (Incorporate laboratory tests and values/
results)
Gap Certification Status
    Ineligible
    We propose to adopt a 2015 Edition that includes the HL7 Version 
2.5.1 Implementation Guide: Standards and Interoperability Framework 
Laboratory Results Interface, Release 1 (US Realm) (S&I Framework LRI) 
with Errata \60\ in the 2015 Edition ``transmission of electronic 
laboratory tests and values/results to ambulatory providers'' 
certification criterion. This IG is the same guide adopted for the 
equivalent 2014 Edition certification criteria, but with the errata. 
The errata address technical corrections and clarifications for 
interoperability with the HL7 Version 2.5.1 Implementation Guide: S&I 
Framework Laboratory Orders from EHR, DSTU Release 1, US Realm, 2013 
\61\ and other laboratory domain IGs.
---------------------------------------------------------------------------

    \60\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=279.
    \61\ We have proposed to adopt this implementation guide for the 
2015 Edition ``CPOE for laboratory orders'' certification criterion.
---------------------------------------------------------------------------

    As compared to the 2014 Edition certification criterion, we also 
propose more specific requirements for how EHR technology must be 
capable of electronically displaying the information included in a test 
report. This specificity would improve the consistency with how 
laboratory tests and values/results are displayed, which would also 
assist with laboratory compliance with CLIA as we discuss in more 
detail earlier in this section (III.A) of the preamble under the 
``Computerized Provider Order Entry--Laboratory.'' This functionality 
would require EHR technology to be capable of displaying the following 
information included in laboratory test reports it receives: (1) The 
information for a test report as specified in 42 CFR 493.1291(a)(1) 
through (a)(3) and (c)(1) through (c)(7); the information related to 
reference values as specified in 42 CFR 493.1291(d); the information 
for alerts and delays as specified in 42 CFR 493.1291(g) and (h); and 
the information for corrected reports as specified in 42 CFR 
493.1291(k)(2).
    We propose to adopt the updated S&I Framework LRI at Sec.  
170.205(j)(2), which requires the modification of the regulatory text 
hierarchy in Sec.  170.205(j) to designate the standard referenced by 
the 2014 Edition version of this certification criterion at Sec.  
170.205(j) to be at Sec.  170.205(j)(1). This regulatory structuring of 
the IGs would make the CFR easier for readers to follow.
 Transmission of Electronic Laboratory Tests and Values/Results 
to Ambulatory Providers
MU Objective
    Provide structured electronic laboratory results to eligible 
professionals.
2015 Edition EHR Certification Criterion
    Sec.  170.315(b)(5) (Inpatient setting only--transmission of 
electronic laboratory tests and values/results to ambulatory providers)
Gap Certification Status
    Ineligible
    We propose to adopt a 2015 Edition certification criterion that 
includes the HL7 Version 2.5.1 Implementation Guide: Standards and 
Interoperability Framework Laboratory Results Interface, Release 1 (US 
Realm) (S&I Framework LRI) with Errata \62\ in the 2015 Edition 
``transmission of electronic laboratory tests and values/results to 
ambulatory providers'' certification criterion. This IG is the same 
guide adopted for the equivalent 2014 Edition certification criteria, 
but with the errata. The errata address technical corrections and 
clarifications for interoperability with the HL7 Version 2.5.1 
Implementation Guide: S&I Framework Laboratory Orders from EHR, DSTU 
Release 1, US Realm, 2013 \63\ and other laboratory domain IGs.
---------------------------------------------------------------------------

    \62\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=279
    \63\ We have proposed to adopt this implementation guide for the 
2015 Edition ``CPOE for laboratory orders'' certification criterion.
---------------------------------------------------------------------------

    As compared to the 2014 Edition certification criterion, we also 
propose to include new functionality that would improve the consistency 
with how laboratory tests and values/results are sent, received, and 
displayed. This would also assist with laboratory compliance with CLIA 
as we discuss in more detail earlier in this section (III.A) of the 
preamble under the ``Computerized Provider Order Entry--Laboratory.'' 
This new functionality would require EHR technology to be capable of 
including in the laboratory test reports it creates for electronic 
transmission: (1) The information for a test report as specified in 42 
CFR 493.1291(a)(1) through (a)(3) and (c)(1) through (c)(7); the 
information related to reference values as specified in 42 CFR 
493.1291(d); the information for alerts and delays as specified in 42 
CFR 493.1291(g) and (h); and the information for corrected reports as 
specified in 42 CFR 493.1291(k)(2).

[[Page 10902]]

    We propose to adopt the updated S&I Framework LRI at Sec.  
170.205(j)(2), which requires the modification of the regulatory text 
hierarchy in Sec.  170.205(j) to designate the standard referenced by 
the 2014 Edition version of this certification criterion at Sec.  
170.205(j) to be at Sec.  170.205(j)(1). This regulatory structuring of 
the IGs would make the CFR easier for readers to follow.
 Data Portability
MU Objective
    N/A
2015 Edition EHR Certification Criterion
    Sec.  170.315(b)(6) (Data portability)
Gap Certification Status
    Ineligible
    We propose to adopt a 2015 Edition ``data portability'' 
certification criterion that revises the 2014 Edition version. Our 
first proposal, for consistency across other certification criteria 
revisions, is to also have this certification criterion reference the 
updated Consolidated CDA (Draft Standard for Trial Use, Release 2.0) 
standard we discuss in more detail in the ToC certification criterion 
portion of this preamble. Our second proposal (for reasons already 
provided as part our proposal for the ``implantable device list'' 
certification criterion) is that EHR technology must be capable of 
including the UDI(s) for a patient's implantable device(s) as data 
within a created Consolidated CDA formatted document.
    We also solicit public comment on the following:
    (1) Whether we should rename this certification criterion ``data 
migration.'' Given that the ``view, download, transmit to 3rd party'' 
certification criterion addresses data availability from a patient's 
perspective, this certification criterion has always been more focused 
on data availability from a health care provider's perspective. We 
believe that a more precise label for this certification criterion 
could prevent confusion as to its focus.
    (2) Whether we should consider adding more requirements for the 
2017 Edition version of this certification criterion that we would 
propose in a future rulemaking and what those requirements should be. 
For example, should this criterion focus on an expanded time boundary 
to allow for more longitudinal data to be exported and should it 
reference more data? Can additional electronic notes be included in a 
data portability requirement with the addition of header metadata to 
support export/import functions?
    (3) Whether we should change this certification criterion as part 
of a 2017 Edition proposal to promote a broader range of use cases, 
including: (1) Local access/query (i.e., a provider's ability to access 
their own data through, for example, an API); (2) targeted access/
inter-organizational query (i.e., a provider's ability to query data 
from another provider or specific location, such as when one provider 
performs a ``targeted query'' to obtain a patient's information from 
another provider); and (3) distributed, multi-source access/query 
(i.e., a provider's ability to disseminate queries to multiple 
organizations). This change could result in multiple use case specific 
certification criteria if appropriate.
 Clinical Quality Measures
Electronically Processing eMeasures
    None of our prior rulemakings have included a proposal to adopt 
standards and EHR technology capabilities focused on an EHR 
technology's ability to electronically process clinical quality 
measures (CQMs). Until now, we did not believe that there were mature 
enough standards with which the industry had experience. For our 2017 
Edition rulemaking, we hope to propose for adoption a certification 
criterion focused on EHR technology's ability to electronically process 
CQMs. More specifically, we solicit comment on industry readiness to 
adopt the HL7 Health Quality Measures Format (HQMF) \64\ standard for 
representing a clinical quality measure as an electronic document.
---------------------------------------------------------------------------

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

    Quality measures encoded in the HQMF format are referred to as 
``eMeasures.'' The standard was first brought to HL7 in 2009 through an 
initiative led by the National Quality Forum under CMS contract.\65\ 
HQMF Release 1 (HQMF R1 or R1) defines data elements, structure, 
metadata, logic, and definitions of quality measures so that measure 
developers can encode their measures in this format for EHR queries.
---------------------------------------------------------------------------

    \65\ HL7 Version 3 Standard: Representation of the Health 
Quality Measures Format (eMeasures), Release 1 (HQMF R1).
---------------------------------------------------------------------------

    HQMF Release 2 (HQRF R2 or R2) \66\ was published in December 2013 
and improves upon the HQMF R1. R2 improves readability using business 
names, includes logic sub-trees to avoid inline repetition, improves 
and expands expressivity, replaces poorly understood specific 
occurrences with set operators, and provides expression language 
support. Both R1 and R2 provide human-readable components and machine 
processable components. However, R2 is easier for EHR technology to 
electronically process compared to the prior version. HQMF R1 is 
supported in the Cypress \67\ testing tool, CMS Measure Authoring Tool 
(MAT),\68\ and through XSL Transforms to generate a human readable form 
of eMeasures. The MAT is a publicly available, web-based tool for 
measure developers to create eMeasures, and uses the Quality Data Model 
(QDM) \69\ to define concepts used in quality measures so EHR and other 
clinical electronic systems can consistently interpret and locate the 
data required. ONC and CMS intend to upgrade the Cypress testing tool 
and MAT to support new versions of the standards.
---------------------------------------------------------------------------

    \66\ HL7 Version 3 Standard: Representation of the Health 
Quality Measures Format (eMeasure), Release 2 (December 2013) (HQMF 
R2).
    \67\ http://projectcypress.org/.
    \68\ https://www.emeasuretool.cms.gov/.
    \69\ http://www.qualityforum.org/QualityDataModel.aspx.
---------------------------------------------------------------------------

    In addition to HQMF R2, the HL7 Version 3 Implementation Guide: 
Quality Data Model (QDM)-based Health Quality Measure Format (HQMF), 
Release 1 (US Realm) was published in December 2013 to provide more 
specific guidance to implementers that are using HQMF R2. The QDM-based 
IG describes constraints on the HQMF R2 header and body elements and 
provides a standard structure to construct a quality measure. This 
promotes more accurate and consistent representation of quality 
measures for better care.
    ONC and CMS are currently working with stakeholders to develop a 
unified set of standards that support both clinical quality measurement 
and clinical decision support. This includes a unified data model, a 
unified expression language, and unified meta-data standard. ONC and 
CMS are also working to modularize components of the existing standards 
(e.g., separate expression model, separate data model) so that any 
changes made in the future will affect only the relevant component of 
the standard, and will not require changes to the entire standard. 
Furthermore, modularization will allow the industry to swap out or 
replace components as needed as standards continue to evolve. These 
unified, modularized standards will likely require updates to already 
balloted versions of the quality measurement and CDS standards (e.g., 
HQMF, QRDA, HeD). Pending the availability of these unified standards 
for the 2017 Edition rulemaking, we anticipate proposing their adoption 
to more fully standardize CDS and CQM capabilities in EHR technology.
    We solicit comment on industry support for unified, modularized CDS 
and CQM standards for the 2017 Edition. We also solicit comment on

[[Page 10903]]

what we should require EHR technology to be able to demonstrate for 
certification (e.g., to require that EHR technology be able to 
electronically process any eCQM formatted in a unified, modularized CQM 
standard such as a new HQMF standard). To inform our future rulemaking, 
we also solicit comment on:
     Recommended testing and certification processes for the 
electronic processing of eCQMs;
     A way in which to classify measures so as to select a 
subset of measures that would be easier and simpler to be 
electronically processed by EHR technology in testing and 
certification;
     The ability/readiness of EHR technology to store and 
incorporate an eCQM in HQMF R2;
     The ability/readiness of EHR technology to map the HQMF R2 
standard to data within the EHR technology (including medications, 
laboratory, allergies information).
    With the industry progress made to date with HQMF, we believe that 
this proposed rule provides an opportunity to introduce the HQMF 
standard for public comment. HQMF's broad adoption can help drive 
industry uptake of electronically processing eMeasures versus manually 
coding based on the human readable view of the eMeasures.
Functions and Standards for CQM Certification
    To inform our 2017 Edition rulemaking, we solicit comment on what 
requirements for supplemental data and reporting should be included as 
part of CQM certification criteria. Quality reporting programs such as 
those required by states and CMS programs other than the EHR Incentive 
Programs may require additional supplemental data and capabilities 
beyond what ONC currently requires for certification. For example, the 
HIMSS EHR Association (EHRA) issued a letter to CMS in November 2013, 
citing variances between ONC's certification requirements and a 
supplemental implementation guide CMS issued ``Hospital Quality 
Reporting (HQR) Quality Reporting Document Architecture Category I 
Release 2 Supplementary Implementation Guide.'' \70\ According to EHRA, 
these variances include, but are not limited to:
---------------------------------------------------------------------------

    \70\ http://www.qualitynet.org/dcs/BlobServer?blobkey=id&blobnocache=true&blobwhere=1228890124454&blobheader=multipart%2Foctet-stream&blobheadername1=Content-Disposition&blobheadervalue1=attachment%3Bfilename%3DHQR_QRDAr2_DSTU_ImpGdV2_111513.pdf&blobcol=urldata&blobtable=MungoBlobs.
---------------------------------------------------------------------------

     ``The need to create QRDA-I reports on a per encounter 
basis rather than per patient, as had been required for certification;
     The EHR certification number must be assigned to each QRDA 
submission, an entirely new data element that would need to be added to 
databases and user interfaces in many cases;
     The new requirement to include the NPI/TIN for 
``associated providers'' when the official Data Element Catalog 
referenced as a standard by ONC indicated that the NPI would only be 
required for EPs--again, a new data element with multiple implications 
for software development and provider usage.''
    We also understand that quality reporting programs may require 
changes to existing standards (e.g., data element changes) that require 
industry (e.g., HL7) balloting and approval. These standards 
development timelines may not align with rulemaking cycles and, 
therefore, create discrepancies between what is required for 
certification versus what other programs may adopt. To better 
understand and address this issue in the future, we solicit comment on 
what specific capabilities, reporting requirements, standards, and data 
elements ONC should consider for CQM certification going forward.
Clinical Quality Measures--Capture and Export
MU Objective
    N/A
2015 Edition EHR Certification Criteria
    Sec.  170.315(c)(1) (Clinical quality measures--capture and export)
Gap Certification Status
    Eligible
    We propose to adopt a 2015 Edition certification criterion that is 
the same as the 2014 Edition version. However, we solicit public 
comment on the following in consideration of our upcoming 2017 Edition 
rulemaking. In the 2014 Edition Final Rule, we required that for 
certification to 170.314(c)(1) EHR technology be able to export a CQM 
data file formatted in accordance with the QRDA Category I standard. We 
solicit public comment on the potential usefulness of broadening the 
export requirement to also include reference to a QRDA Category II 
formatted data file, which would address the bulk reporting of quality 
data that includes the patient level data as outlined in the QRDA 
Category I report. A QRDA Category II report is a multi-patient-level 
quality report. Each report contains quality data for a set of patients 
for one or more quality measures, where the data elements in the report 
are defined by the particular measure(s) being reported on. Whereas a 
QRDA Category I report contains only raw applicable patient data, a 
QRDA Category II report includes flags for each patient indicating 
whether the patient qualifies for a measure's numerator, denominator, 
exclusion, or other aggregate data element. These qualifications can be 
pooled and counted to create the QRDA Category III \71\ report \72\ or 
the QRDA Category II report can be used for bulk or batch reporting of 
quality data.
---------------------------------------------------------------------------

    \71\ ONC has previously adopted the QRDA Categories I and III 
standards.
    \72\ QRDA Category III is used to report aggregate quality 
results (e.g., total number of patients in the numerator, total 
number of patients in the denominator).
---------------------------------------------------------------------------

 Clinical Quality Measures--Import and Calculate
MU Objective
    N/A
2015 Edition EHR Certification Criteria
    Sec.  170.315(c)(2) (Clinical quality measures--import and 
calculate)
Gap Certification Status
    Eligible
    We propose to adopt a 2015 Edition certification criterion that is 
the same as the 2014 Edition version.
 Clinical Quality Measures--Electronic Submission
MU Objective
    N/A
2015 Edition EHR Certification Criteria
    Sec.  170.315(c)(3) (Clinical quality measures--electronic 
submission)
Gap Certification Status
    Eligible
    We propose to adopt a 2015 Edition certification criterion that is 
the same as the 2014 Edition version.
 Clinical Quality Measures--Patient Population Filtering
MU Objective
    N/A
2015 Edition EHR Certification Criteria
    Sec.  170.315(c)(4) (Clinical quality measures--patient population 
filtering)
Gap Certification Status
    Ineligible
    We propose to adopt a new 2015 Edition certification criterion to 
require filtering of CQMs by patient population characteristics. Some 
newer CMS reporting programs may require the capability to support 
additional reporting filters. For example, the CMS Comprehensive 
Primary Care (CPC) initiative provides financial incentives to primary 
care providers in primary care practices who coordinate better care for 
their patients. In the CPC initiative, CMS determines the bonus payment 
based on the performance of an

[[Page 10904]]

``eligible practice site,'' not the individual provider. Similarly, the 
CMS Pioneer Accountable Care Organization (ACO) Model and Physician 
Quality Reporting System (PQRS) group practice reporting option (GPRO) 
provide payment based on ACO and group practice performance, 
respectively. Therefore, we propose to require that EHR technology be 
able to record structured data for the purposes of being able to filter 
CQM results to create different patient population groupings by one or 
a combination of the following patient characteristics:
     Practice site and address;
     Tax Identification Number (TIN), National Provider 
Identifier (NPI), and TIN/NPI combination;
     Diagnosis (e.g., by SNOMED CT code);
     Primary and secondary health insurance, including 
identification of Medicare and Medicaid dual eligibles;
     Demographics including age, sex, preferred language, 
education level, and socioeconomic status.
    To inform our proposal, we solicit comment on whether current CQM 
standards (e.g., QRDA Category I and Category III) can collect metadata 
for the characteristics listed above to filter and create a CQM report 
for a particular characteristic or combination of characteristics. We 
also solicit comment on vocabulary standards that could be used to 
record the characteristics proposed above.
 Authentication, Access Control, and Authorization
MU Objective
    Protect electronic health information created or maintained by the 
Certified EHR Technology through the implementation of appropriate 
technical capabilities
2015 Edition EHR Certification Criterion
    Sec.  170.315(d)(1) (Authentication, access control, and 
authorization)
Gap Certification Status
    Eligible
    We propose to adopt a 2015 Edition certification criterion that is 
the same as the 2014 Edition version. However, we solicit public 
comment on the issue of two-factor authentication to support two use 
cases: e-prescribing of controlled substances and remote provider 
access to EHR technology. In both the 2011 and 2014 Edition final 
rules, ONC's authentication-oriented certification criteria do not 
require that two-factor authentication be demonstrated as a capability 
in order to meet our certification criteria.
E-Prescribing Controlled Substances
    In March 2010, the Drug Enforcement Agency (DEA) published an 
interim final rule entitled ``Electronic Prescriptions for Controlled 
Substances'' \73\ (75 FR 16236). The rule removed the Federal 
prohibition against the electronic prescribing of controlled substances 
and requires a two-factor authentication protocol. Specifically, DEA 
permits authentication protocols that meet NIST LOA 3.\74\
---------------------------------------------------------------------------

    \73\ http://www.deadiversion.usdoj.gov/ecomm/e_rx/faq/faq.htm.
    \74\ The National Institute of Standards and Technology (NIST) 
Special Publication 800-63-2 includes recommendations and guidelines 
for electronic authentication as well as defines four levels of 
authentication. Level 1 is the lowest assurance and Level 4 is the 
highest. Assurance Level 3 (LOA Level 3) provides multifactor remote 
network authentication. http://csrc.nist.gov/publications/drafts/800-63-2/sp800_63_2_draft.pdf.
---------------------------------------------------------------------------

    More recently, the MU Stage 2 final rule (77 FR 53989-90) provided 
EPs participating in Stage 2 with an alternative denominator for the e-
prescribing measure. This alternative allows EPs who are able to 
electronically prescribe controlled substances and want to count these 
prescriptions in the measure to do so.
Remote Provider Access to EHR Technology
    In September 2012, the HITPC made recommendations regarding 
authentication standards that should be in place by the onset of MU 
Stage 3.\75\ The HITPC recommended that ONC should move toward 
requiring multi-factor authentication (meeting LOA 3) by provider users 
who remotely access protected health information. In its 
recommendations, the HITPC described remote access to include the 
following scenarios: ``access from outside of an organization's/
entity's private network, access from an IP address not recognized as 
part of the organization/entity or that is outside of the organization/
entity's compliance environment, and access across a network any part 
of which is or could be unsecure (such as across the open Internet or 
using an unsecure wireless connection).''
---------------------------------------------------------------------------

    \75\ http://www.healthit.gov/FACAS/sites/faca/files/transmittal_092512_pstt_recommendations_provider_authentication.pdf.
---------------------------------------------------------------------------

    Given the DEA's rule and the HITPC recommendations, we seek comment 
on whether we should consider two-factor authentication requirements 
for our 2017 Edition rulemaking. Specifically, we seek comment on:
    (1) Whether we should adopt a general two-factor authentication 
capability requirement for certification. This requirement could 
complement e-prescribing of controlled substances requirements and more 
definitively support security requirements for remote access to EHR 
technology as well as any other EHR technology uses that may require 
two factor authentication. Note, given that DEA has its own 3rd-party 
assessors and available certification process for technology to 
demonstrate compliance with its rules, we have no intention nor do we 
believe that it would be prudent to duplicate DEA regulatory 
requirements in ours. In fact, two ONC-ACBs are also approved by DEA to 
perform its approved certification process.\76\
---------------------------------------------------------------------------

    \76\ http://www.deadiversion.usdoj.gov/ecomm/e_rx/thirdparty.htm.
---------------------------------------------------------------------------

    (2) Whether the HITPC's recommendations are appropriate and 
actionable and, if not, what level of assurance should be the minimum 
required for provider-users seeking remote access to EHR technology.
 Auditable Events and Tamper-Resistance
MU Objective
    Protect electronic health information created or maintained by the 
Certified EHR Technology through the implementation of appropriate 
technical capabilities
2015 Edition EHR Certification Criterion
    Sec.  170.315(d)(2) (Auditable events and tamper-resistance)
Gap Certification Status
    Ineligible
    We propose to adopt a 2015 Edition ``auditable events and tamper-
resistance'' certification criterion that revises the 2014 Edition 
version. The 2014 Edition ``auditable events and tamper-resistance'' 
certification criterion requires (at 45 CFR 170.314(d)(2)(ii)) that EHR 
technology must be set by default to perform the capabilities specified 
in (d)(2)(i)(A) of the criterion, and where applicable, (d)(2)(i)(B) 
and/or (C). The certification criterion, however, does not prohibit an 
EHR technology's audit log from being disabled by a user. Rather, the 
certification criterion requires access controls to be in place to 
restrict the ability to disable the audit log to a limited set of 
identified users and to record the user ID date/time when such a 
command is executed (45 CFR 170.314(d)(2)(i)(B)) to show who last 
``touched'' the audit log before it was disabled.
    In a 2013 report entitled ``Not All Recommended Safeguards Have 
Been Implemented in Hospital EHR Technology (OEI-01-11-00570),'' \77\ 
the HHS Office of the Inspector General (OIG) recommended that we 
should propose a revision to this certification

[[Page 10905]]

criterion to ``require that EHR technology keeps the audit log 
operational whenever the EHR technology is available for updates or 
viewing.'' Further the OIG stated that we should ``ensure that 
providers cannot or do not disable audit logs whenever the EHR 
technology is available for updates or viewing.'' As one basis for this 
recommendation, OIG found that ``ninety-six percent of hospitals 
reported that their audit logs remain operational at all times'' 
despite reporting barriers related to resources, user guides, and 
training.
---------------------------------------------------------------------------

    \77\ https://oig.hhs.gov/oei/reports/oei-01-11-00570.pdf.
---------------------------------------------------------------------------

    In our response to OIG's report, we indicated our concurrence with 
its recommendation. Accordingly, we propose to adopt a 2015 Edition 
``auditable events and tamper-resistance'' certification criterion that 
is similar to its 2014 Edition version, but that requires EHR 
technology to prevent all users from being able to disable the audit 
log through the EHR technology. The phrase ``through the EHR 
technology'' is meant to limit the scope of this capability to what is 
in the EHR technology's control and to be consistent with the same 
scope limitation expressed in the 2014 Edition version of this 
criterion that we placed on ``audit log protection'' at 
170.314(d)(2)(iv) (77 FR 54235).
    In the past, we had heard from stakeholders that there were reasons 
(e.g., performance concerns) to allow for audit logs to be disabled. 
Given that the proposed 2015 Edition certification criterion would 
prohibit that type of action from being performed in order for the EHR 
technology to be certified, we seek public comment on the impact and 
potential unintended consequences of such a change and specific 
examples where disabling an EHR technology's audit log is warranted.
 Audit Report(s)
MU Objective
    Protect electronic health information created or maintained by the 
Certified EHR Technology through the implementation of appropriate 
technical capabilities
2015 Edition EHR Certification Criterion
    Sec.  170.315(d)(3) (Audit report(s))
Gap Certification Status
    Eligible
    We propose to adopt a 2015 Edition certification criterion that is 
the same as the 2014 Edition version. However, we solicit public 
comment on whether the ASTM E2147 standard will continue to remain 
sufficient for EHR technology certification for the 2017 Edition.
    The standards adopted at 45 CFR 170.210(e) and referenced by the 
2014 Edition ``auditable events and tamper-resistance'' and ``audit 
report(s)'' certification criteria require that EHR technology must be 
able to record audit log information as specified in sections 7.2 
through 7.4, 7.6 and 7.7 of the standard adopted at 45 CFR 170.210(h). 
The standard adopted at 45 CFR 170.210(h) is ASTM E2147. Section 7.6 of 
ASTM E2147 specifies that audit log content needs to include the ``type 
of action'' and references six ``actions:'' additions, deletions, 
change, queries, print, and copy. Section 7.7 requires that the audit 
log record when patient data is accessed. So while not explicitly 
referenced in section 7.6, the action of ``access'' or viewing of a 
patient's information is also required to be recorded for 
certification.
    Since the 2014 Edition Final Rule was published, we have received 
stakeholder feedback and questions regarding the actions specified at 
section 7.6 and their relationship to testing and certification in 
specific situations. Generally, these situations all pertained to 
stakeholders seeking confirmation that they should not have to support 
the auditing of capabilities that the EHR technology was not designed 
to perform. Specifically, stakeholders asked if EHR technology could 
still be certified if it were designed without one of the actions 
specified by the standard. For instance if the EHR technology did not 
include a ``copy'' function, did the EHR technology developer still 
need to design the audit log capability to record the ``copy'' action.
    It was not our intention to require EHR technology developers to 
add in audit log functionality solely for certification purposes. We 
have interpreted this certification criterion requirement to mean that 
if the EHR technology does not include a capability for which an 
``action'' is listed that testing and certification can proceed for the 
audit log process without EHR technology showing that it can record 
actions related to a non-existent capability. Any exception such as 
this for 2014 Edition testing is to be documented in the test report 
issued for the EHR technology, which is made publicly accessible on the 
Certified HIT Products List (CHPL) with the EHR technology.
    Stakeholder feedback on this 2014 Edition certification criterion 
has brought up three issues on which we solicit public comment:
    (1) The ``query'' action in section 7.6 of the ASTM E2147 standard 
is not a defined term in the standard's definition section (See section 
3). As a result, we seek comment on whether this ambiguity has caused 
additional burden or challenges for EHR technology developers and how 
EHR technology developers have interpreted the term when designing 
their EHR technology. We also solicit comment on industry knowledge 
related to any plans to revise ASTM E2147 to address this ambiguity.
    (2) Whether we should establish a minimum/baseline set of actions 
that EHR technology must always be capable of being audited. For 
instance, we could see the potential for ``copy,'' ``print,'' and 
``query'' capabilities to not be included in certain EHR technologies. 
Thus, we could set a baseline that within section 7.6's actions, EHR 
technology must always support ``additions, deletions, and changes.''
    (3) Are there other actions that we should consider specifying in 
an updated standard for the 2017 Edition that the current standard does 
not sufficiently address, such as the act of ``transmission''? We do 
not favor this approach because implementing it in regulation would 
cause us to add to the existing standard. Thus, we seek feedback on 
whether the standard is sufficiently up-to-date and appropriately 
specifies all of the actions necessary for EHR audit logs to capture.
    (4) Finally, we seek comment on whether there are any alternative 
standards to ASTM E2147 that we should consider in light of the 
aforementioned concerns and ambiguities.
 Amendments; Automatic Log-Off; Emergency Access; End-User 
Device Encryption; Integrity
MU Objective
    Protect electronic health information created or maintained by the 
Certified EHR Technology through the implementation of appropriate 
technical capabilities
2015 Edition EHR Certification Criteria
    Sec.  170.315(d)(4) (Amendments)
    Sec.  170.315(d)(5) (Automatic Log-Off)
    Sec.  170.315(d)(6) (Emergency access)
    Sec.  170.315(d)(7) (End-User Device Encryption)
    Sec.  170.315(d)(8) (Integrity)
Gap Certification Status
    Eligible (all five referenced)
    We propose to adopt 2015 Edition EHR certification criteria that 
are the same as the 2014 Edition versions for all five of these 
certification criteria.
 Accounting of Disclosures
MU Objective
    Protect electronic health information created or maintained by the 
Certified EHR Technology through the implementation of appropriate 
technical capabilities
2015 Edition EHR Certification Criterion

[[Page 10906]]

    Sec.  170.315(d)(9) (Accounting of Disclosures)
Gap Certification Status
    Eligible
    We propose to adopt 2015 Edition certification criterion that is 
the same text as the 2014 Edition version. However, given our proposal 
to discontinue the Complete EHR concept and the associated regulatory 
definition (discussed later in this preamble), we also propose to 
remove the ``optional'' designation from this certification criterion 
as part of the 2015 Edition because such a designation would no longer 
be necessary. Further, we propose to continue to exclude it from the 
Base EHR definition in order to maintain policy consistency with the 
2014 Edition and for the reasons discussed in our prior rulemakings 
regarding why we made it ``optional'' and excluded it from the Complete 
EHR definition.
 View, Download, and Transmit to Third Party
MU Objective
    EPs
    Provide patients, and their authorized representatives, the ability 
to view online, download, and transmit their health information within 
4 business days of the information being available to the EP
    EHs and CAHs
    Provide patients, and their authorized representative, the ability 
to view online, download, and transmit information about a hospital 
admission
2015 Edition EHR Certification Criterion
    Sec.  170.315(e)(1) (View, download, and transmit to third party)
Gap Certification Status
    Ineligible
    We propose to adopt a 2015 Edition criterion that revises the 2014 
Edition version. The 2014 Edition View, Download and Transmit to Third 
Party (VDT) certification criterion requires EHR technology to provide 
patients (and their authorized representatives) with a secure online 
means to view, download, and transmit their health information to a 3rd 
party of their choice. It also requires EHR technology to keep an 
activity history log of the date and time a view, download, or 
transmission occurred and by whom. For the 2015 Edition version of this 
criterion, we propose several changes.
Clarified Introductory Text
    We propose to make clarifying changes to the introductory text at 
170.315(e)(1) to make it clear that this EHR technology capability is 
patient facing and for patients to use. Accordingly, we propose to 
revise the introductory text to lead with ``Patients (and their 
authorized representatives) must be able to use EHR technology to. . . 
.'' We also propose to use this same phrase at the beginning of each 
specific capability for VDT to reinforce this point.
    For the same reasons discussed in the proposed 2015 Edition ToC 
certification criterion, we propose to reference the updated version of 
the Consolidated CDA (Draft Standard for Trial Use, Release 2.0), which 
we propose for adoption in this certification criterion.
Removing Ambiguity from ``Download''
    We propose to revise the language for ``download'' to leave no room 
for any alternative interpretation. Specifically, we propose revising 
that language to stress that a patient must be able to download an 
ambulatory or inpatient summary in only the human readable format if 
they just want that, in only the Consolidated CDA format if they just 
want that, or in both formats if they want both. Although the 2014 
Edition Final Rule's preamble for the 2014 Edition of this criterion 
expressed that a patient needed to be able to download either as their 
choice (meaning that EHR technology needed to support both methods), 
the ``or'' in the regulation text and our avoidance of using ``and/or'' 
(which can be equally confusing) led stakeholders to misinterpret the 
requirement's meaning when not read with the preamble.
Decoupling Transport and Content
    For the same above-noted reasons we provide in the proposed 2015 
Edition ToC certification criterion, we propose to ``decouple'' the 
transport and content capabilities in the 2015 Edition version of VDT. 
Similar to the ToC revisions, this certification criterion will now 
focus on content requirements and EHR technology's ability to 
demonstrate conformance with the IG for Direct Edge Protocols and 
enable a successful transmission. Certification for transmit is now a 
separate stand-alone requirement that can support ToC as well as VDT. 
The proposed requirements at Sec.  170.315(e)(1)(i)(C):
    (1) clearly express the need to support a patient's ability to 
choose the destination to whom they want to send their health 
information; and
    (2) would require that EHR technology enable a patient to 
accomplish a transmission (of their own health information) that 
conforms to the IG for Direct Edge Protocols and is used by a service 
that has implemented the primary Direct Project specification.
    By ``accomplish,'' we clarify that our expectation and our 
anticipated approach through testing would be that the transmitted 
Consolidated CDA arrives at its destination. This change would permit 
EHR technology developers seeking testing and certification to this 
proposed criterion to demonstrate compliance with the transmission 
requirement without having to be a HISP. They would, however, need to 
show that they can connect to one by conforming to the IG for Direct 
Edge Protocols and that the HISP successfully transmitted the 
ambulatory summary or inpatient summary to the patient's specified 
destination using the Direct Project specification. Demonstrating this 
outcome could be expedited if the EHR technology developer uses a 
service that is certified to enable health information to be 
electronically transmitted in accordance with the primary Direct 
Project specification (under our new proposal for this to be a separate 
certification criterion).
    We clarify that the phrase ``[e]nter a 3rd party destination of 
their choice'' in the certification criterion does not require EHR 
technology to support every possible method a patient could conceivably 
choose. Rather, EHR technology must be able to support at least the 
entry of any ``Direct address,'' which is the minimum required by this 
certification criterion. We also note that from our perspective it is 
unacceptable for this transmission capability to in any way limit a 
patient's ability to send their health information to any existing and 
working ``Direct address.''
    We seek comment on whether we should require another transmission 
method as part of this certification criterion in addition to the one 
just discussed.
Updated Consolidated CDA Version
    We propose, for consistency across other certification criteria 
revisions, to also have this certification criterion reference the 
updated Consolidated CDA standard (Draft Standard for Trial Use, 
Release 2.0) we discuss in more detail in the ToC certification 
criterion portion of this preamble. Similarly, we propose (for reasons 
already provided as part our proposal for the ``implantable device 
list'' certification criterion) that EHR technology must be capable of 
including the UDI(s) for a patient's implantable device(s) as data 
within a created Consolidated CDA formatted document.
View
    As discussed in our proposal for the 2015 Edition ``implantable 
device list''

[[Page 10907]]

certification criterion, we propose to add ``implantable device 
information'' as data that EHR technology would need to be capable of 
making available to a patient under the ``view'' capability.
Activity History Log
    We propose to include two new data points in the 2015 Edition VDT 
criterion related to the activity history log. We propose that the 
addressee to whom an ambulatory summary or inpatient summary was 
transmitted and whether that transmission was successful (or failed) be 
recorded. Although the 2014 Edition VDT criterion requires that the 
action of ``transmit'' be recorded, we did not specify that the 
intended destination be recorded. We believe this transactional history 
is important for patients to be able to access, especially if they 
actively transmit their health information to a 3rd party or another 
health care provider.
WCAG 2.0 Level AA
    Consistent with our belief that all patients should have an equal 
opportunity to access their electronic health information without 
barriers or diminished functionality or quality, we proposed in the 
2014 Edition NPRM (77 FR 13840) that the viewing capability for VDT 
must meet Level AA conformance with the most recent set of the Web 
Content Accessibility Guidelines (WCAG). The most recent set of 
guidelines (WCAG 2.0) were published in 2008 \78\ and are organized 
under 4 central principles with testable ``success criteria:'' 
Perceivable, Operable, Understandable, and Robust. Each guideline 
offers 3 levels of conformance: A, AA, and AAA. WCAG 2.0 Level A (Level 
A) conformance corresponds to the most basic requirements for 
displaying Web content. WCAG 2.0 Level AA (Level AA) conformance 
provides for a stronger level of accessibility by requiring conformance 
with Level A success criteria as well as Level AA specific success 
criteria. WCAG 2.0 Level AAA (Level AAA) conformance comprises the 
highest level of accessibility within the WCAG guidelines and includes 
all Level A and Level AA success criteria as well as success criteria 
unique to Level AAA.
---------------------------------------------------------------------------

    \78\ http://www.w3.org/TR/WCAG20/.
---------------------------------------------------------------------------

    In the 2014 Edition Final Rule (77 FR 54179) we considered public 
comment and ultimately adopted Level A for accessibility, but indicated 
our interest in raising this bar over time. As a result, we propose for 
the 2015 Edition VDT criterion that EHR technology be compliant with 
Level AA. We propose to adopt this standard at Sec.  170.204(a)(2). 
Note, to implement this proposal, we would have to modify the 
regulatory text hierarchy in Sec.  170.204 to designate the 
accessibility standard referenced by the 2014 Edition VDT certification 
criterion at Sec.  170.204(a) to be at Sec.  170.204(a)(1). Level AA 
provides a stronger level of accessibility and addresses areas of 
importance to the disabled community that are not included in Level A. 
For example, success criteria unique to Level AA include specifications 
of minimum contrast ratios for text and images of text, and a 
requirement that text can be resized without assistive technology up to 
200 percent without loss of content or functionality. We recognize that 
Level AA is a step up from Level A and request public comment on 
whether there are particular key elements of Level AA that we could 
adopt as hybrid between Level A and AA in an effort to prioritize key 
focus areas for accessibility improvements.
    We also understand that there are not separate guidelines for 
``mobile accessibility'' and that mobile is considered by the W3C Web 
Accessibility Initiative to be covered by the WCAG 2.0 guidelines.\79\ 
Further, we would note that in September 2013, the W3C published a 
working group note consisting of ``Guidance on Applying WCAG 2.0 to 
Non-Web Information and Communications Technologies (WCAG2ICT).'' \80\ 
We request public comment (especially from EHR technology developers 
that have sought or considered certification to the 2014 Edition VDT 
certification criterion with a ``non-web'' application) on what, if 
any, challenges exist or have been encountered when applying the WCAG 
2.0 standards.
---------------------------------------------------------------------------

    \79\ http://www.w3.org/WAI/mobile/.
    \80\ http://www.w3.org/TR/wcag2ict/.
---------------------------------------------------------------------------

2017 Edition Issues for the VDT Certification Criterion under 
Consideration Images and Non-Text Data
    In the 2014 Edition NPRM we proposed to require EHR technology to 
be capable of enabling images formatted according to the Digital 
Imaging and Communications in Medicine (DICOM) standard to be 
downloaded and transmitted to a third party (77 FR 13840). We stated 
our belief that this specific capability has the potential to empower 
patients to play a greater role in their own care coordination and 
could help assist in reducing the amount of redundant and duplicative 
imaging-oriented tests performed. In response to public comment, 
however, we did not adopt this proposal. In considering improvements 
that could be made to the VDT certification criterion for the 2017 
Edition, we request public comment on whether we should again propose 
to require that images be part of this criterion. More specifically, we 
seek comment on: (1) Whether images for patients need to be of 
diagnostic quality; (2) whether they should be viewable and 
downloadable, but not required to be transmitted; and (3) whether 
cloud-based technology could allow for a link to the image to be made 
accessible. We also seek comment on other non-text data that we could 
require EHR technology to be able to make available to patients such as 
ECG waveforms.
``OpenNotes''
    We also solicit public comment on whether a 2017 Edition VDT 
certification criterion should enable ``OpenNotes'' \81\ functionality 
for EPs, EHs, and CAHs, to give patients the ability to gain access to 
their visit notes. The OpenNotes initiative was led by Beth Israel 
Deaconess Medical Center through a grant from the Robert Wood Johnson 
Foundation whereby ``researchers undertook a year-long trial of 
OpenNotes in which 105 doctors shared their notes with more than 19,000 
patients in Boston, rural Pennsylvania, and Seattle.'' \82\ 
Additionally, in April 2013, the Department of Veterans Affairs 
announced that it had enabled OpenNotes through its My HealtheVet Blue 
Button.\83\
---------------------------------------------------------------------------

    \81\ http://www.myopennotes.org/what-is-opennotes-2/.
    \82\ http://www.rwjf.org/en/grants/grantees/OpenNotes.html.
    \83\ http://www.rwjf.org/en/blogs/pioneering-ideas/2013/04/why_the_va_embraces.html.
---------------------------------------------------------------------------

 Clinical Summary
MU Objective
    Provide clinical summaries for patients for each office visit
2015 Edition EHR Certification Criterion
    Sec.  170.315(e)(2) (Ambulatory setting only--clinical summary)
Gap Certification Status
    Ineligible
    We propose to adopt a 2015 Edition ``clinical summary'' 
certification criterion that revises the 2014 Edition version. 
Specifically, we propose to reflect the clarifications we provided in 
FAQ 33,\84\ require the use of CVX codes for immunizations, and 
reference the updated Consolidated CDA version (Draft Standard for 
Trial Use, Release 2.0) in this criterion for consistency across our 
2015 Edition and for the

[[Page 10908]]

other reasons stated already in the proposed 2015 Edition ToC 
certification criterion. We also propose (for reasons already provided 
as part our proposal for the ``implantable device list'' certification 
criterion) that EHR technology must be capable of including the UDI(s) 
for a patient's implantable device(s) as data within a created 
Consolidated CDA formatted document.
---------------------------------------------------------------------------

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

    The regulation text of the 2015 Edition ``clinical summary'' 
certification criterion clarifies that for medications administered 
during the visit, diagnostic tests pending after the visit and future 
scheduled tests, EHR technology must demonstrate the capability to 
represent the data using the specified vocabulary standard, where 
appropriate. FAQ 33 encourages the use of CVX codes for immunizations 
since the code set was not actually specified in the 2014 Edition 
``clinical summary'' certification criterion. To correct this 
oversight, the 2015 Edition ``clinical summary'' certification 
criterion specifically includes the required use of CVX codes for 
immunizations. For diagnostic tests pending and future scheduled tests, 
we propose to require the use of LOINC[supreg]. We request comment, 
however, on whether LOINC[supreg] can be used to represent all possible 
diagnostic tests pending and future scheduled tests.
    We also reiterate the situational dependency (office visit 
dependent) of certain data that the EHR technology must be able to 
provide, and limit, in the clinical summary to meet the proposed 2015 
Edition certification criterion as well as the 2014 Edition ``clinical 
summary'' certification criterion. Although the regulation text for 
medications, diagnostic tests pending, and future scheduled tests may 
seem redundant with the Common MU Data Set, this data along with 
immunizations is specified separately because EHR technology must have 
the capability to limit this data in a clinical summary it creates to 
only those medications and immunizations administered during the visit 
and/or the diagnostic tests pending and future scheduled tests after 
the visit. In terms of customization of the clinical summary, this 
permits the user to limit this data in the clinical summary if so 
desired by the user. While providing historical data for medications, 
immunizations, and diagnostic tests in the clinical summary may be of 
benefit in certain instances, EHR technology is not required to have 
these capabilities to meet the certification criterion. This 
certification criterion, like the 2014 Edition ``clinical summary'' 
certification criterion, is meant to support the associated MU 
objective and measure that seeks to provide a patient with a record of 
the visit and specific lab tests or specific follow-up actions and 
treatment related to the visit.
 Secure Messaging
MU Objective
    Use secure electronic messaging to communicate with patients on 
relevant health information
2015 Edition EHR Certification Criterion
    Sec.  170.315(e)(3) (Ambulatory setting only--secure messaging)
Gap Certification Status
    Eligible
    We propose to adopt a 2015 Edition certification criterion that is 
the same as the 2014 Edition version.
 Immunization Information
MU Objective
    Capability to submit electronic data to immunization registries or 
immunization information systems except where prohibited, and in 
accordance with applicable law and practice
2015 Edition EHR Certification Criterion
    Sec.  170.315(f)(1) (Immunization information)
Gap Certification Status
    Eligible
    We propose to adopt a 2015 Edition certification criterion that is 
the same as the 2014 Edition version.
 Transmission to Immunization Registries
MU Objective
    Capability to submit electronic data to immunization registries or 
immunization information systems except where prohibited, and in 
accordance with applicable law and practice
2015 Edition EHR Certification Criterion
    Sec.  170.315(f)(2) (Transmission to immunization registries)
Gap Certification Status
    Ineligible
    We propose to adopt a 2015 Edition certification criterion that 
revises the 2014 Edition version. The 2014 Edition EHR certification 
criterion for transmission to immunization registries at Sec.  
170.314(f)(2) references the following IG for immunization messaging: 
HL7 Version 2.5.1: Implementation Guide for Immunization Messaging, 
Release 1.4.
    Since the publication of the 2014 Edition Final Rule, CDC has 
issued an updated IG (HL7 Version 2.5.1: Implementation Guide for 
Immunization Messaging, Release 1.5) that promotes greater 
interoperability between immunization registries and EHR technologies. 
Release 1.5 focuses on known issues from the previous release and 
revises certain HL7 message elements to reduce differences between 
states and jurisdictions for recording specific data elements. 
Specifically, Release 1.5 \85\:
---------------------------------------------------------------------------

    \85\ This IG will be available for review during the public 
comment period at http://www.cdc.gov/EHRmeaningfuluse/guides.html.
---------------------------------------------------------------------------

     Clarifies and tightens conformance statements;
     corrects ACK (acknowledgment) messages to support improved 
messaging back to the EHR about the success/failure of a message;
     includes query and response changes such as V2.7.1 MSH 
user constraints, minimum requirements for a response message, and 
corrected profiles for response to errors and no match situations.
    We believe these improvements are important to the IG and will 
continue to support our ultimate goal for this certification 
criterion--bidirectional immunization data exchange. Given the 
improvements included in the updated IG, we propose to adopt it at 
Sec.  170.205(e)(4) and include it in the 2015 Edition ``transmission 
to immunization registries'' certification criterion at Sec.  
170.315(f)(2).
    We have received stakeholder comments that the immunization 
registry community is moving toward, but has not yet developed fully 
mature standards for bidirectional data exchange that include 
immunization forecasting/CDS. We seek public comment on the maturity of 
bidirectional immunization data exchange activities and whether we 
should propose to include bidirectional immunization data exchange as 
part of the 2015 Edition and/or 2017 Edition.
National Drug Codes for Vaccine Coding
    Our 2014 Edition requires the use of the CVX codes \86\ to record 
vaccines administered.\87\ CDC developed and maintains the list of CVX 
codes. The National Drug Code (NDC) vocabulary serves as a universal 
product identifier for drugs, and FDA publishes the list of NDC numbers 
as part of the NDC Directory.\88\ In our 2011 Edition final rule, 
commenters noted that they were not aware of a mapping from NDC to CVX 
codes (75 FR 44614), and we did not believe that NDC codes were 
appropriate for representing immunizations at the time. However, since 
then CDC has begun a process to map National Drug Codes (NDC) to CVX

[[Page 10909]]

codes.\89\ Stakeholders have expressed support for moving to NDC codes 
for vaccines because NDC codes:
---------------------------------------------------------------------------

    \86\ http://www2a.cdc.gov/vaccines/iis/iisstandards/vaccines.asp?rpt=cvx.
    \87\ Sec.  170.314(b)(2), Sec.  170.314 (b)(7), and Sec.  
170.314(e)(2).
    \88\ http://www.fda.gov/drugs/informationondrugs/ucm142438.htm.
    \89\ http://www2a.cdc.gov/vaccines/iis/iisstandards/vaccines.asp?rpt=ndc.
---------------------------------------------------------------------------

     Are used for pharmaceutical inventory management within 
immunization registries, and therefore built into the immunization 
workflow;
     Are built into 2D barcodes which have been successfully 
piloted for vaccines (see comment solicitation for 2D barcoding for 
more information);
     Can improve safety with better specificity of vaccine 
formulation.
    In addition, FDA has worked with HL7 to improve assignment of NDC 
codes to vaccines to reduce the reuse of NDC codes, an issue which has 
presented itself in the past.
    NDC codes are structured in three parts: labeler, product, and 
packaging subcodes. Thus, historical vaccinations cannot be recorded 
using NDC codes because the exact formulation (e.g., product portion) 
is usually unknown. For example, a patient may report that he or she 
received the influenza vaccine one year ago, but does not know which 
influenza vaccine he or she received. We are aware of two possible 
solutions to record historical vaccinations if we were to move to 
replace CVX with NDC codes:
     Option 1: Continue to use CVX codes for 
historical vaccinations only;
     Option 2: Use the NDC syntax and create a new 
value set for the product portion of the code for vaccines of 
unspecified formula (e.g., influenza vaccine of unspecified formula) 
for historical vaccinations (resulting in an ``NDC-like'' code).
    Given these issues, we solicit comment for the 2017 Edition on 
whether we should move to using NDC codes for vaccines to replace CVX 
and the preferred option for recording historical immunizations. We 
also solicit comment on other vocabularies that could be used to 
replace CVX. For example, we currently require RxNorm for medications 
and medication allergies in the 2014 Edition. We are aware that RxNorm 
codes include NDC codes as attributes, and it is possible to go from an 
NDC to an RxNorm standard normalized name.\90\ Last, in our 2011 
Edition final rule, we noted that CPT codes were not a better 
alternative to CVX because CPT codes are used for billing purposes and 
there is a public mapping of CPT to CVX codes \91\ (75 FR 44614).
---------------------------------------------------------------------------

    \90\ See ``Where does RxNorm get its data?'' at http://www.nlm.nih.gov/research/umls/rxnorm/overview.html.
    \91\ http://www2a.cdc.gov/vaccines/iis/iisstandards/vaccines.asp?rpt=cpt.
---------------------------------------------------------------------------

 Transmission to Public Health Agencies--Syndromic Surveillance
MU Objective
    Capability to submit electronic syndromic surveillance data to 
public health agencies except where prohibited, and in accordance with 
applicable law and practice
Revised 2014 Edition EHR Certification Criterion
    Sec.  170.314(f)(3) (Transmission to public health agencies--
syndromic surveillance)
2015 Edition EHR Certification Criterion
    Sec.  170.315(f)(3) (Transmission to public health agencies--
syndromic surveillance)
Gap Certification Status
    Ineligible if certified prior to the effective date of the 2015 
Edition Final Rule
    Eligible if certified after the effective date of the 2015 Edition 
Final Rule

    We propose to revise the 2014 Edition syndromic surveillance 
certification criterion and adopt an identical 2015 Edition version.
    Electronic syndromic surveillance data is valuable for early 
detection of outbreaks, monitoring disease and condition trends, and 
providing reassurance that an outbreak has not occurred. Syndromic 
surveillance can also inform community efforts to track and control 
chronic conditions. For both MU Stages 1 and 2, EPs may choose the 
``electronic syndromic surveillance data'' objective under the menu 
set. In the MU Stage 2 final rule, CMS stated that very few public 
health agencies were accepting syndromic surveillance data from 
ambulatory, non-hospital providers, and there was no corresponding IG 
available at the time of the final rule's publication (77 FR 54025). 
They also noted that the CDC was working with the syndromic 
surveillance community to develop a new IG for ambulatory reporting of 
syndromic surveillance data, which was expected to be published in 
spring 2013.
    Only a few public health agencies are currently accepting syndromic 
surveillance data from the ambulatory setting using HL7 2.5.1. Due to 
lack of demand, the CDC no longer plans to develop an HL7 2.5.1 IG for 
ambulatory reporting of syndromic surveillance data. Without such an IG 
most public health agencies will not have enough specific guidance to 
build systems to receive syndromic surveillance data from the 
ambulatory setting formatted to HL7 2.5.1. The MU Stage 2 final rule 
states that an EP, EH, or CAH may claim an exclusion if the public 
health agency does not have the capacity to accept reporting (77 FR 
54021). Thus, many EPs may qualify for an exclusion for this objective 
and associated measure and, as a result, would need to choose another 
objective from the menu set on which to report.
    Given the lack of an ambulatory IG for HL7 2.5.1, we propose to 
revise the 2014 Edition certification criterion. The proposed revisions 
to the 2014 Edition certification criterion would allow EHR technology 
designed for the ambulatory setting to be certified to alternative 
standards that support other modes of electronic syndromic surveillance 
data submission. In this regard, we are aware that syndromic 
surveillance data is currently being sent to public health agencies 
through new query-based models, including the QueryHealth 
initiative.\92\ Query-based models take patient level data, de-identify 
it, and aggregate it for population health use. We understand that 
these query-based models use HL7 CDA and QRDA III standards, and do not 
necessarily use the HL7 2.5.1 standard. CDA and QRDA III standards were 
adopted and referenced by 2014 Edition certification criteria and, as a 
result, have become more widely implemented.
---------------------------------------------------------------------------

    \92\ 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 seek to make available 
additional electronic syndromic surveillance submission capabilities in 
order to better support their opportunity to receive credit for the 
syndromic surveillance MU objective. Therefore, we propose to revise 
the 2014 Edition syndromic surveillance certification criterion at 
Sec.  170.314(f)(3) to include the HL7 CDA and QRDA III standards as 
alternative standards to HL7 2.5.1 for EHR technology certification 
designed for the ambulatory setting.
    We propose to revise the 2014 Edition syndromic surveillance 
certification criterion by replacing the referenced IG for the HL7 
2.5.1 standard (for the inpatient setting) with an updated version that 
incorporates an addendum clarifying conformance guidance. Specifically, 
we propose to move to the updated implementation specification PHIN 
Messaging Guide for Syndromic Surveillance: Emergency Department, 
Urgent Care, and Inpatient Settings, Release 1.9 (April 2013) \93\ and 
adopt it at Sec.  170.205(d)(4). We believe that HL7 2.5.1 is the only 
appropriate standard for inpatient setting certification as an IG 
exists and many hospitals and public

[[Page 10910]]

health agencies are using the standard to exchange syndromic 
surveillance data. The alternative HL7 CDA and QRDA III standards we 
propose to include in the revised 2014 Edition syndromic surveillance 
certification criterion for the ambulatory setting are standards we 
have already adopted as part of the 2014 Edition. With respect to the 
HL7 CDA standard, we also propose to adopt it at Sec.  170.205(d)(5), 
which is under the specific syndromic surveillance hierarchy in our 
regulation text. The proposed adoption of this standard here is meant 
to clearly indicate the transmission to which this standard is to be 
applied.
---------------------------------------------------------------------------

    \93\ http://www.cdc.gov/phin/library/guides/PHIN%20MSG%20Guide%20for%20SS%20Final_508readyRelease1_9%2004%2027%202013.pdf.
---------------------------------------------------------------------------

    We propose to adopt a 2015 Edition syndromic surveillance 
certification criterion at Sec.  170.315(f)(3) that includes these same 
standards and is identical to the proposed revised 2014 Edition 
syndromic surveillance certification criterion.
    We solicit comment on whether public health agencies are using the 
QRDA Category I standard to receive query-based syndromic surveillance 
data, and whether ONC should consider adopting the QRDA Category I 
standard for the ambulatory setting.
    The gap certification status indicated in the table for this 
certification criterion is split because we have proposed to modify the 
2014 Edition syndromic surveillance certification criterion. If EHR 
technology is certified prior to the effective date of a final rule for 
this 2015 Edition proposed rule, then it will be certified to the 
current ``unrevised'' version of the 2014 Edition syndromic 
surveillance certification criterion. EHR technology certified to the 
``unrevised'' version of the 2014 Edition syndromic surveillance 
certification criterion would be ineligible for gap certification to 
the 2015 Edition syndromic surveillance certification criterion because 
of the proposed changes to the 2015 Edition syndromic surveillance 
certification criterion. However, if EHR technology is certified after 
the effective date of a final rule for this 2015 Edition proposed rule, 
the EHR technology could be certified to the proposed revised 2014 
Edition syndromic surveillance certification criterion. This would then 
make the EHR technology eligible for gap certification to the 2015 
Edition syndromic surveillance certification criterion because the 
proposed 2015 Edition syndromic surveillance certification criterion 
would be ``unchanged'' when compared to the proposed revised 2014 
Edition syndromic surveillance certification criterion.
 Transmission of Reportable Laboratory Tests and Values/Results
MU Objective
    Capability to submit electronic reportable laboratory results to 
public health agencies, except where prohibited, and in accordance with 
applicable law and practice
2015 Edition EHR Certification Criterion
    Sec.  170.315(f)(4) (Inpatient setting only--Transmission of 
reportable laboratory tests and values/results)
Gap Certification Status
    Ineligible

    We propose to adopt a 2015 Edition certification criterion that 
revises the 2014 Edition version. We also propose to make a technical 
amendment to the regulation text for the 2014 Edition criterion in 
order to have it continue to point to the appropriate standard and 
implementation specifications (HL7 2.5.1 and HL7 Version 2.5.1: 
Implementation Guide: Electronic Laboratory Reporting to Public Health, 
Release 1 with Errata and Clarifications and ELR 2.5.1 Clarification 
Document for EHR Technology Certification) after we restructure the 
regulatory text hierarchy at Sec.  170.205(g) to our accommodate our 
2015 Edition proposal.
    Since the publication of the 2014 Edition Final Rule, CDC has 
issued an updated implementation guide (HL7 Version 2.5.1 
Implementation Guide: Electronic Laboratory Reporting to Public Health, 
DSTU, Release 2 (US Realm), 2013) that address technical corrections 
and clarifications for interoperability with laboratory orders and 
other laboratory domain implementation guides. Specifically, Release 2: 
\94\
---------------------------------------------------------------------------

    \94\ This IG will be available for review during the public 
comment period at http://www.cdc.gov/EHRmeaningfuluse/guides.html.
---------------------------------------------------------------------------

     Corrects errata;
     Applies conformance statements and condition predicates 
from the Clarifications and ELR 2.5.1 Clarification Document for EHR 
Technology Certification;
     Provides technical corrections;
     Provides additional guidance and clarifications;
     Aligns with the current S&I Framework v2 messaging guide 
in the laboratory space (Release 1 was aligned with the LRI predecessor 
issued by Healthcare Information Technology Standards Panel).
    We believe these improvements are important to the IG and will 
continue to support interoperability. Given the improvements included 
in the updated IG, we propose to adopt it at Sec.  170.205(g)(2) and 
include it in the 2015 Edition ``transmission of reportable laboratory 
tests and values/results'' certification criterion at Sec.  
170.315(f)(4). As noted above, to properly codify this proposal in 
regulation, we would have to modify the regulatory text hierarchy in 
Sec.  170.205(g) to designate the standard and implementation 
specifications referenced by the 2014 Edition ``transmission of 
reportable laboratory tests and values/results'' certification 
criterion at Sec.  170.205(g)(1) instead of its current designation at 
Sec.  170.205(g).
 Cancer Case Information
MU Objective
    Capability to identify and report cancer cases to a State cancer 
registry, except where prohibited, and in accordance with applicable 
law and practice
2015 Edition EHR Certification Criteria
    Sec.  170.315(f)(5) (Ambulatory setting only--cancer case 
information)
Gap Certification Status
    Eligible

    We propose to adopt a 2015 Edition EHR certification criterion for 
cancer case information that is the same as the 2014 Edition version. 
However, given our proposal to discontinue the Complete EHR concept and 
associated regulatory definition (discussed later in this preamble), we 
also propose to remove the ``optional'' designation from this 
certification criterion as part of the 2015 Edition since such 
designation would no longer be necessary.
 Transmission to Cancer Registries
MU Objective
    Capability to identify and report cancer cases to a State cancer 
registry, except where prohibited, and in accordance with applicable 
law and practice
2015 Edition EHR Certification Criteria
    Sec.  170.315(f)(6) (Ambulatory setting only--transmission to 
cancer registries)
Gap Certification Status
    Ineligible

    We propose to adopt a 2015 Edition certification criterion for 
transmission to cancer registries that revises the 2014 Edition 
version. Given our proposal to discontinue the Complete EHR concept and 
associated regulatory definition (discussed later in this preamble), we 
also propose to remove the ``optional'' designation from this 
certification criterion as part of the 2015 Edition since such 
designation would no longer be necessary.
    We propose to make a technical amendment to the regulation text for 
the

[[Page 10911]]

2014 Edition certification criterion so that it continues to point to 
the appropriate standard \95\ in the regulatory text hierarchy at Sec.  
170.205(i), while accommodating our 2015 Edition proposal. 
Specifically, we propose to modify the 2014 Edition certification 
criterion to reference Sec.  170.205(i)(1) to establish the regulatory 
text hierarchy necessary to accommodate the standard and IG referenced 
by the proposed 2015 Edition certification criterion.
---------------------------------------------------------------------------

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

    The 2014 Edition criterion for transmission to cancer registries at 
Sec.  170.314(f)(6) references the following IG for cancer reporting: 
Implementation Guide for Ambulatory Healthcare Provider Reporting to 
Central Cancer Registries, HL7 Clinical Document Architecture (CDA), 
Release 1.0. Since the publication of the 2014 Edition Final Rule, CDC 
has updated the IG (Implementation Guide for Ambulatory Healthcare 
Provider Reporting to Central Cancer Registries, HL7 Clinical Document 
Architecture (CDA), Release 1.1, March 2014) to address technical 
corrections and clarifications for interoperability with EHRs and 
cancer registries. Specifically, this updated version of the IG: \96\
---------------------------------------------------------------------------

    \96\ This IG will be available for review during the public 
comment period at http://www.cdc.gov/EHRmeaningfuluse/guides.html.
---------------------------------------------------------------------------

     Provides clarification about conformance statements taking 
precedence over table constraints;
     Adds new vocabulary link (ICD 10 CM reportability list);
     Fixes some within-document references;
     Fixes some LOINC Codes;
     Fixes some Code System and Value Set Object Identifiers 
(OIDs);
     Fixes some conformance verbs;
     Modifies some conformance statements and sample XML for 
clarifications in Medications Entry;
     Fixes some attributes in Payer Section;
     Fixes some Xpaths and element names in constraints table;
     Adds and fixes some codes in Appendix A Code System Table;
     Fixes some conformance verbs and data element names in 
Appendix B ``Ambulatory Healthcare Provider Cancer Event Report--Data 
Elements'';
     Fixes value in value set; and
     Adds data elements for transmission of Grade and 
pathological TNM Stage.
    These improvements are important to the IG and will continue to 
support interoperability. Given the improvements that will be included 
in the updated IG, we propose to adopt it (Implementation Guide for 
Ambulatory Healthcare Provider Reporting to Central Cancer Registries, 
HL7 Clinical Document Architecture (CDA), Release 1.1) at Sec.  
170.205(i)(2) for the 2015 Edition certification criterion for 
transmission to cancer registries at Sec.  170.315(f)(6).
 Automated Numerator Recording
MU Objective
    N/A
2015 Edition EHR Certification Criterion
    Sec.  170.315(g)(1) (Automated numerator recording)
Gap Certification Status
    Eligibility is Fact-Specific

    We propose to adopt a 2015 Edition certification criterion that is 
the same as the 2014 Edition version.
 Automated Measure Calculation
MU Objective
    N/A
2015 Edition EHR Certification Criterion
    Sec.  170.315(g)(2) (Automated measure calculation)
Gap Certification Status
    Eligibility is Fact-Specific

    We propose to adopt a 2015 Edition ``automated measure 
calculation'' certification criterion that is the same as the 2014 
Edition certification criterion. We propose to apply the guidance 
provided for the 2014 Edition ``automated measure calculation'' 
certification criterion in the 2014 Edition Final Rule in that EHR 
technology must be able to support all CMS-acceptable approaches for 
measuring a numerator and denominator in order for to meet the proposed 
2015 Edition ``automated measure calculation'' certification 
criterion.\97\ We also propose that the interpretation of the 2014 
Edition ``automated measure calculation'' certification criterion in 
FAQ 32 \98\ would apply to the proposed 2015 Edition ``automated 
measure calculation'' certification criterion.
---------------------------------------------------------------------------

    \97\ 77 FR 54244-54245.
    \98\ http://www.healthit.gov/policy-researchers-implementers/32-question-11-12-032.
---------------------------------------------------------------------------

 Safety-Enhanced Design; and Quality Management System
MU Objective
    N/A
2015 Edition EHR Certification Criteria
    Sec.  170.315(g)(3) (Safety-Enhanced Design)
    Sec.  170.315(g)(4) (Quality Management System)
Gap Certification Status
    Eligibility is Fact-Specific--Safety-Enhanced Design
    Eligible--Quality Management System
    We propose to adopt 2015 Edition EHR certification criteria that 
are the same as the 2014 Edition versions, but solicit public comment 
regarding whether we should modify these criteria in light of feedback 
that we received during the HITPC ``Implementation and Usability'' 
hearing on July 23, 2013.\99\ Specifically, we request comment 
regarding:
---------------------------------------------------------------------------

    \99\ http://www.healthit.gov/archive?dir=FACA%20Hearings/2013-07-23%20Standards%3A%20Implementation%2C%20Meaningful%20Use%2C%20and%20Certification%20%26%20Adoption%20WGs%2C%20%20Implementation%20%26%20Usability%20Hearing.
---------------------------------------------------------------------------

     Whether the scope of ``Safety-Enhanced Design'' should be 
expanded to include additional certification criteria;
     Whether formative usability tests should be explicitly 
required, or used as substitutes for summative testing;
     Whether there are explicit usability tests that should be 
required in addition to summative testing; and
     Whether there should be a minimum number of test subjects 
explicitly required for usability testing.
    We note that we have updated the cross referencing in the 2015 
Edition version of the ``safety-enhanced design'' certification 
criterion to track the updated certification criteria paragraph 
numbering.
 Non-Percentage-Based Measures Report
MU Objective
    N/A
2015 Edition EHR Certification Criterion
    Sec.  170.315(g)(5) (Non-percentage-based measures report)
Gap Certification Status
    Ineligible

    We propose to adopt a new certification criterion in the 2015 
Edition entitled ``non-percentage-based measures report.'' 
Specifically, we propose to adopt a new 2015 Edition EHR certification 
criterion at Sec.  170.315(g)(5) that would apply to EHR technology 
presented for certification that includes certain ``non-percentage-
based capabilities'' (i.e., capabilities that support MU objectives for 
which the corresponding MU measure is not percentage-based). In the 
2014 Edition NPRM (77 FR 13842), we proposed a certification criterion 
entitled ``non-percentage-based measure use report.'' This 
certification criterion was meant to complement the other certification

[[Page 10912]]

criteria we proposed to support the calculation of percentage-based MU 
measures. In the 2014 Edition Final Rule (77 FR 54186), we acknowledged 
commenters' concerns regarding the complexities raised by our proposed 
``non-percentage-based measure use report'' certification criterion and 
that additional specificity would be needed to make the certification 
criterion more effective. Although we declined to adopt the proposed 
certification criterion in the final rule, we affirmed our belief in 
its spirit and direction--that EPs, EHs, and CAHs would benefit from 
EHR technology that could electronically report non-percentage-based MU 
objectives and measures.
    In November 2012, the HITPC issued a Request for Comment (RFC) 
regarding potential meaningful use Stage 3 recommendations.\100\ The 
RFC specifically solicited feedback on ways in which EHR technology 
could help providers document the use of EHR technology capabilities 
associated with MU measures that are not percentage-based. The comments 
submitted in response to the RFC as well as the 2014 Edition NPRM 
echoed the need for EHR technology to be able to assist providers 
document their use of EHR technology to achieve non-percentage-based 
objectives and measures. The comments also confirmed and have sharpened 
our understanding of the complexities associated with this type of 
certification criterion. Further, we considered these comments in light 
of the recommendation from the HHS OIG that, ``where possible,'' ONC 
require that certified EHR technology be capable of producing reports 
for all MU measures, including non-percentage-based measures.\101\ OIG 
explained that such reports could help EPs, EHs, and CAHs prove 
compliance in the event of an audit and simplify CMS' oversight of the 
EHR Incentive Programs by allowing CMS to conclusively verify that an 
EP, EH, or CAH had relevant EHR technology capabilities in use during 
their reporting period. OIG also acknowledged that producing reports 
may not be possible for some measures.
---------------------------------------------------------------------------

    \100\ The Request for Comments is available at http://www.healthit.gov/sites/default/files/hitpc_stage3_rfc_final.pdf.
    \101\ OEI-05-11-00250 (Nov. 2012), available at https://oig.hhs.gov/oei/reports/oei-05-11-00250.pdf.
---------------------------------------------------------------------------

    The new criterion we propose to adopt is more specific than the one 
we proposed in the 2014 Edition NPRM and also clarifies key aspects of 
the 2014 Edition proposal that caused confusion. Specifically, this 
proposed criterion recognizes that certain aspects of ``use'' 
associated with non-percentage-based measures will occur in different 
ways based on the particular EHR technology capability involved. In 
that regard, the proposed criterion provides EHR technology developers 
with substantial flexibility to create innovative approaches to 
document evidence of use and because non-percentage-based MU measures 
vary, we do not presume that there is one particular way to meet this 
certification criterion.
    The proposed certification criterion would require that an EHR 
technology presented for certification be capable of electronically 
generating a report that shows a user had used (or interacted with) the 
EHR technology capability associated with a non-percentage-based MU 
measure during an EHR reporting period. This means that, at a minimum, 
the EHR technology would need to be capable of determining an EHR 
reporting period (date range) and be able to record some evidence of 
use (e.g., transaction, user action, intervention/reminder) during the 
reporting period. We request public comment on whether we should make 
the regulatory text for this certification criterion more specific or 
if we should maintain the word ``evidence'' and use the final rule's 
preamble to provide more examples of what evidence would be acceptable 
(if we determine to adopt this criterion). If we were to make the 
regulatory text more specific, we propose these two options, but also 
solicit comment on other potential language that would make satisfying 
this criterion clearer.
     Option 1: Require the EHR technology to record evidence of 
use each time a particular capability was used during the reporting 
period.
     Option 2: Require the EHR technology to record evidence of 
use at the beginning, during, and end of the reporting period.
    In some cases we understand that it will not be possible for EHR 
technology to record whether a non-percentage-based capability was used 
``to demonstrate MU'' because this determination depends on the context 
in which the use of the capability occurred or on other subjective 
factors that cannot be determined through EHR technology use. To 
address this point, the proposed criterion focuses on the ability of 
EHR technology to record pertinent information about the use of non-
percentage-based capabilities (e.g., transaction, user action, 
intervention/reminder) that would be helpful to ascertain whether the 
corresponding MU measure was met during a reporting period. Moreover, 
as indicated in Table 2 and explained below, the proposed criterion 
would apply to only those non-percentage-based measures for which this 
pertinent information would be available to the EHR technology based on 
the nature of the capabilities and the ways in which a user could be 
expected to interact with them. To note, the use of the term 
``unchanged'' in the ``MU Stage 2'' column of the table denotes that 
the objective and/or measure has not changed from MU Stage 1.

  Table 2--2015 Edition Certification Criteria That Support One or More
                      Non-Percentage-Based Measures
------------------------------------------------------------------------
                   Certification
   Applicable        criterion         MU Stage 1*        MU Stage 2*
------------------------------------------------------------------------
Y..............  Sec.               Objective. Drug-   Objective.
                  170.315(a)(4),     drug, drug-        Clinical
                  Drug-drug, drug-   allergy            decision
                  allergy            interaction        support.
                  interaction        checks.           Measure. Enable
                  checks.           Measure. Enable     and implement
                                     the                drug-drug and
                                     functionality      drug-allergy
                                     for the entire     interaction
                                     EHR reporting      checks and
                                     period.            implement five
                                                        CDS
                                                        interventions
                                                        for at least
                                                        four CQMs for
                                                        the entire
                                                        reporting
                                                        period.
Y..............  Sec.               Objective.
                  170.315(a)(10),    Clinical
                  Clinical           decision support.
                  decision support. Measure.
                                     Implement one
                                     clinical
                                     decision support
                                     rule.
Y..............  Sec.               Objective.         Objective.
                  170.315(a)(16),    Patient lists.     Unchanged.
                  Patient list      Measure Generate   Measure.
                  creation.          at least 1         Unchanged.
                                     report listing
                                     patients with a
                                     specific
                                     condition.

[[Page 10913]]

 
Y..............  Sec.               Objective.         Objective.
                  170.315(f)(2),     Transmission to    Unchanged.
                  Transmission to    immunization      Measure.
                  immunization       registries.        Successful
                  registries.       Measure. Perform    ongoing
                                     a test and         submission from
                                     follow-up          CEHRT for entire
                                     submission if      reporting
                                     the test was       period.
                                     successful.
Y..............  Sec.               Objective.         Objective.
                  170.315(f)(3),     Transmission to    Unchanged.
                  Transmission to    public health     Measure.
                  public health      agencies           Successful
                  agencies           (syndromic         ongoing
                  (surveillance).    surveillance       submission for
                                     data).             entire reporting
                                    Measure. Perform    period.
                                     a test and
                                     follow-up
                                     submission if
                                     the test was
                                     successful.
Y..............  Sec.               Objective.         Objective.
                  170.315(f)(4),     Transmission to    Unchanged.
                  Transmission of    public health     Measure.
                  reportable         agencies           Successful
                  laboratory tests   (reportable lab    ongoing
                  and values/        data).             submission for
                  results.          Measure. Perform    entire reporting
                                     a test and         period.
                                     follow-up
                                     submission if
                                     the test was
                                     successful.
                 Sec.               N/A..............  Objective.
                  170.315(f)(6),                        Capability to
                  Transmission to                       identify and
                  cancer                                report cancer
                  registries.                           cases to a State
                                                        cancer registry.
                                                       Measure.
                                                        Successful
                                                        ongoing
                                                        submission for
                                                        entire reporting
                                                        period.
N..............  Sec.               Objective.         Objective.
                  170.315(b)(1),     Transitions of     Transitions of
                  Transitions of     care.              care.
                  care.             Measure. Provides  Measures. (1)
                                     a summary of       Provide a
                                     care record for    summary of care
                                     more than 50% of   record for more
                                     transitions of     than 50% of
                                     care and           transitions of
                                     referrals.         care and
                                                        referrals. (2)
                                                        Provide a
                                                        summary of
                                                       care record
                                                        electronically
                                                        for more than
                                                        10% of
                                                        transitions of
                                                        care and
                                                        referrals.
                                                        (3)(A) Conducts
                                                        one or more
                                                        successful
                                                        electronic
                                                        exchanges of a
                                                        summary of care
                                                        record with a
                                                        recipient using
                                                        technology to
                                                        receive the
                                                        summary of care
                                                        record that was
                                                        designed by a
                                                        different EHR
                                                        developer than
                                                        the sender's; or
                                                       (B) Conducts one
                                                        or more
                                                        successful tests
                                                        with the CMS
                                                        designated test
                                                        EHR during the
                                                        EHR reporting
                                                        period.
N..............  Sec.               Objective.         Objective.
                  170.315(a)(12),    Implement drug-    Generate and
                  Drug-formulary     formulary checks.  transmit
                  checks.           Measure. Enable     permissible
                                     functionality      prescriptions
                                     and have access    electronically
                                     to one internal    (eRx).
                                     or external       Measure. More
                                     formulary for      than 50% of
                                     entire reporting   prescriptions
                                     period.            (EP) or more
                                                        than 10% of
                                                        hospital
                                                        discharge
                                                        medication
                                                        orders for
                                                        permissible
                                                        prescriptions
                                                        (EH/CAH) are
                                                        queried for a
                                                        drug-formulary
                                                        and transmitted
                                                        electronically
                                                        using CEHRT.
N..............  Sec.               Objective.
                  170.315(d)(1)-(9   Protect
                  ), Privacy and     electronic
                  Security.          health
                                     information
                                     through
                                     implementation
                                     of appropriate
                                     technical
                                     capabilities.
                                    Measure. Conduct   Objective.
                                     or review a        Unchanged.
                                     security risk     Measure.
                                     analysis in        Unchanged.
                                     accordance with
                                     the requirements
                                     under 45 CFR
                                     164.308(a)(1)
                                     and implement
                                     security updates
                                     as necessary and
                                     correct
                                     identified
                                     security
                                     deficiencies as
                                     part of the
                                     EP's, EH's, or
                                     CAH's risk
                                     management
                                     process
------------------------------------------------------------------------
* The requirements for each meaningful use objective and measure are set
  forth in 42 CFR Sec.   495.6. For convenience, we have summarized and/
  or condensed the descriptions for each objective and measure listed in
  the table above.

    We propose not to include within the scope of this certification 
criterion the EHR technology capability specified in Sec.  
170.315(a)(12), which supports the MU Stage 1 objective ``Implement 
drug-formulary checks'' and the associated non-percentage-based 
measure. This objective was merged with the new MU Stage 2 objectives 
``Generate and transmit permissible prescriptions electronically 
(eRx)'' for EPs and ``Generate and transmit permissible discharge 
prescriptions electronically (eRx)'' for EHs and CAHs, each of which is 
associated with a new percentage-based measure. As a result, EHR 
technology certified to Sec.  170.315(a)(12) must also be certified to 
the ``automated numerator recording'' or ``automated measure 
recording'' certification criterion and will provide adequate evidence 
of use with respect to MU Stage 1 measure related to drug-formulary 
checks.
    We also propose to treat the proposed ToC capability specified at 
Sec.  170.315(b)(1) as inapplicable for purposes of this proposed 
certification criterion. The corresponding MU Stage 1 measure for this 
capability is percentage-based. The corresponding MU Stage 2 objective 
has three measures, two of which are percentage-based. The third 
measure is non-percentage-based, but involves one or more discrete 
transactions in which the EHR user will either receive some form of 
confirmation (from the CMS-designated test EHR) or the transaction is 
documented by the EP, EH, or CAH.
    Finally, as we previously stated in the 2014 Edition Final Rule, 
the privacy and

[[Page 10914]]

security certification criteria proposed for adoption in Sec.  
170.315(d), which are associated with the MU objective (and measure) 
entitled ``protect electronic health information created or maintained 
by the Certified EHR Technology through the implementation of 
appropriate technical capabilities,'' would not be included within the 
scope of this certification criterion because we do not believe that 
EHR technology would be able to capture that a security risk analysis 
was performed by an EP, EH, or CAH except through a manual entry by the 
EP, EH, or CAH affirming the completion of the risk analysis.
    Consistent with the way in which we have previously implemented 
certification policy that more generally applies to EHR technology, an 
ONC-ACB would also need to have new certification responsibilities if 
we were to adopt this proposed criterion in a final rule. As a result, 
we are also proposing to revise 45 CFR 170.550. This revision would 
ensure that EHR Modules presented for certification to certification 
criteria that support MU objectives with a non-percentage-based measure 
are certified to this certification criterion proposed at Sec.  
170.315(g)(5).
 Transmission Certification Criteria
    As discussed in the proposed 2015 Edition ToC certification 
criterion earlier in this preamble, we have determined that it would 
best support industry interoperability approaches and provider choices 
for electronic exchange services if we permitted ``data content'' 
capabilities to be tested and certified separately from ``data 
transmission'' capabilities. As a result, we propose below three 2015 
Edition transmission certification criteria that reflect the decoupling 
of content and transport from both the ToC certification criterion and 
VDT certification criterion. These three proposed criteria mirror the 
transmission standards listed in the 2014 Edition ToC certification 
criterion with the first at 170.315(h)(1) mirroring the same 
transmission standard list in the 2014 Edition VDT certification 
criterion. We have not proposed to require the ability to receive 
Consolidated CDAs transmitted in accordance with the IG for Direct Edge 
Protocols in these certification criteria because we believe it to be 
unnecessary to require as a condition of certification. We assume that: 
1) it will be in the best/market interests of any EHR technology 
developer who gets a product separately certified to any of these 
certification criteria to ensure that the product is able to receive 
data from EHR technology certified to electronically transmit in 
accordance with the IG for Direct Edge Protocols (otherwise its 
product's viability and competitiveness on the market would be 
limited); and 2) it would be redundant in cases where a single EHR 
technology is certified to, for example, both the proposed 2015 Edition 
ToC certification criterion at Sec.  170.315(b)(1) and the Transmit--
Applicability Statement for Secure Health Transport at Sec.  
170.315(h)(1). However, we solicit comment on whether there are other 
factors we have not considered in coming to these conclusions.
 Transmit--Applicability Statement for Secure Health Transport
MU Objective
    N/A
2015 Edition EHR Certification Criterion
    Sec.  170.315(h)(1) (Transmit--Applicability Statement for Secure 
Health Transport)
Gap Certification Status
    Ineligible

    We propose to adopt a new 2015 Edition certification criterion for 
electronic transmission at 45 CFR 170.315(h)(1) that would enable EHR 
technology to be tested and certified solely to perform transmissions 
in accordance with the Applicability Statement for Secure Health 
Transport (the primary Direct Project specification) adopted at Sec.  
170.202(a). We expect that this capability would be tested similarly to 
how it is today except that only this capability would be tested.
 Transmit--Applicability Statement for Secure Health Transport 
and XDR/XDM for Direct Messaging
MU Objective
    N/A
2015 Edition EHR Certification Criterion
    Sec.  170.315(h)(2) (Transmit--Applicability Statement for Secure 
Health Transport and XDR/XDM for Direct Messaging)
Gap Certification Status
    Ineligible

    We propose to adopt a new 2015 Edition certification criterion for 
electronic transmission at 45 CFR 170.315(h)(2) that would enable EHR 
technology to be tested and certified solely to perform transmissions 
in accordance with the Applicability Statement for Secure Health 
Transport (the primary Direct Project specification) adopted at Sec.  
170.202(a) and its companion specification XDR and XDM for Direct 
Messaging Specification adopted at Sec.  170.202(b). We expect that 
this capability would be tested similarly to how it is today except 
that only this capability would be tested.
 Transmit--SOAP Transport and Security Specification and XDR/
XDM for Direct Messaging
MU Objective
    N/A
2015 Edition EHR Certification Criterion
    Sec.  170.315(h)(3) (Transmit--SOAP Transport and Security 
Specification and XDR/XDM for Direct Messaging)
Gap Certification Status
    Ineligible

    We propose to adopt a new 2015 Edition certification criterion for 
electronic transmission at 45 CFR 170.315(h)(3) that would enable EHR 
technology to be tested and certified solely to perform transmissions 
in accordance with the Transport and Security Specification (also 
referred to as the SOAP-Based Secure Transport RTM adopted at Sec.  
170.202(c) and its companion specification XDR and XDM for Direct 
Messaging Specification adopted at Sec.  170.202(b). We expect that 
this capability would be tested similarly to how it is today except 
that only this capability would be tested.
 Transmit--Applicability Statement for Secure Health Transport 
and Delivery Notification in Direct
MU Objective
    N/A
2015 Edition EHR Certification Criterion
    Sec.  170.315(h)(4) (Transmit--Applicability Statement for Secure 
Health Transport and Delivery Notification in Direct)
Gap Certification Status
    Ineligible

    We propose to adopt a new 2015 Edition certification criterion for 
electronic transmission at 45 CFR 170.315(h)(4) that would enable EHR 
technology to be tested and certified solely to perform transmissions 
in accordance with the Applicability Statement for Secure Health 
Transport (the primary Direct Project specification) adopted at Sec.  
170.202(a) and its companion specification Implementation Guide for 
Delivery Notification in Direct, Version 1.0, June 29, 2012 (Delivery 
Notification IG).\102\ The primary Direct Project specification 
requires that Security/Trust Agents (STAs) must issue a Message 
Disposition Notification (MDN, RFC3798) with a disposition of processed 
upon successful receipt, decryption, and trust validation of a Direct 
message. By sending this MDN, the receiving STA is taking

[[Page 10915]]

custodianship of the message and is indicating that it will deliver the 
message to its destination. While the primary Direct Project 
specification indicates that additional MDNs may be sent to indicate 
further processing progress of the message, they are not required. The 
primary Direct Project specification, however, does not provide 
guidance in regards to the actions that should be taken by the sending 
STA in the event an MDN processed message is not received or if the 
receiving STA cannot deliver the message to its destination after 
sending the initial MDN processed message. Due to the lack of 
specifications and guidance in the primary Direct Project specification 
regarding deviations from normal message flow, STAs implementing only 
requirements denoted as ``must'' in Section 3 of the primary Direct 
Project specification may not be able to provide a high level of 
assurance that a message has arrived at its destination. The Delivery 
Notification IG provides implementation guidance enabling STAs to 
provide a high level of assurance that a message has arrived at its 
destination and outlines the various exception flows that result in 
compromised message delivery and the mitigation actions that should be 
taken by STAs to provide success and failure notifications to the 
sending system.
---------------------------------------------------------------------------

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

    From a CLIA regulations perspective, the Delivery Notification IG 
can provide the necessary level of assurance that sent laboratory 
results are received by a provider. Additionally, we note that the 
Delivery Notification IG could be generally useful for any transmission 
that requires a high level of assurance.
    Finally, given that testing and certification to this certification 
criterion would assess conformance to specific, distinct capabilities, 
we propose that certification to Sec.  170.315(h)(4) would not satisfy 
Sec.  170.315(h)(1) or (h)(2), which would need to be separately 
demonstrated to pass testing and certification.

B. 2014 Edition to 2015 Edition Equivalency Table

    The following table identifies the proposed 2015 Edition EHR 
certification criteria that are equivalent to the 2014 Edition 
certification criteria for the purposes of meeting the CEHRT 
definition.

                                Table 3--2015 Edition to 2014 Edition Equivalency
----------------------------------------------------------------------------------------------------------------
                      2015 Edition                                             2014 Edition
----------------------------------------------------------------------------------------------------------------
                                   Title of regulation                                     Title of regulation
      Regulation section                paragraph               Regulation section              paragraph
----------------------------------------------------------------------------------------------------------------
Sec.   170.315(a)(4)..........  Drug-drug, drug-allergy   Sec.   170.314(a)(2).........  Drug-drug, drug-allergy
                                 interaction checks.                                      interaction checks.
Sec.   170.315(a)(5)..........  Demographics............  Sec.   170.314(a)(3).........  Demographics.
Sec.   170.315(a)(6)..........  Vital signs, BMI, &       Sec.   170.314(a)(4).........  Vital signs, BMI, &
                                 growth charts.                                           growth charts.
Sec.   170.315(a)(7)..........  Problem list............  Sec.   170.314(a)(5).........  Problem list.
Sec.   170.315(a)(8)..........  Medication list.........  Sec.   170.314(a)(6).........  Medication list.
Sec.   170.315(a)(9)..........  Medication allergy list.  Sec.   170.314(a)(7).........  Medication allergy
                                                                                          list.
Sec.   170.315(a)(10).........  Clinical decision         Sec.   170.314(a)(8).........  Clinical decision
                                 support.                                                 support.
Sec.   170.315(a)(11).........  Electronic notes........  Sec.   170.314(a)(9).........  Electronic notes.
Sec.   170.315(a)(12).........  Drug-formulary checks...  Sec.   170.314(a)(10)........  Drug-formulary checks.
Sec.   170.315(a)(13).........  Smoking status..........  Sec.   170.314(a)(11)........  Smoking status.
Sec.   170.315(a)(14).........  Image results...........  Sec.   170.314(a)(12)........  Image results.
Sec.   170.315(a)(15).........  Family health history...  Sec.   170.314(a)(13)........  Family health history.
Sec.   170.315(a)(16).........  Patient list creation...  Sec.   170.314(a)(14)........  Patient list creation.
Sec.   170.315(a)(17).........  Patient-specific          Sec.   170.314(a)(15)........  Patient-specific
                                 education resources.                                     education resources.
Sec.   170.315(a)(18).........  Electronic medication     Sec.   170.314(a)(16)........  Electronic medication
                                 administration record.                                   administration record.
Sec.   170.315(a)(19).........  Advance directives......  Sec.   170.314(a)(17)........  Advance directives.
Sec.   170.315(b)(2)..........  Clinical information      Sec.   170.314(b)(4).........  Clinical information
                                 reconciliation and                                       reconciliation.
                                 incorporation.
Sec.   170.315(b)(3)..........  Electronic prescribing..  Sec.   170.314(b)(3).........  Electronic prescribing.
Sec.   170.315(b)(4)..........  Incorporate lab tests &   Sec.   170.314(b)(5).........  Incorporate lab tests &
                                 values/results.                                          values/results.
Sec.   170.315(b)(5)..........  Transmission of           Sec.   170.314(b)(6).........  Transmission of
                                 electronic lab tests &                                   electronic lab tests &
                                 values/results to                                        values/results to
                                 ambulatory providers.                                    ambulatory providers.
Sec.   170.315(b)(6)..........  Data portability........  Sec.   170.314(b)(7).........  Data portability.
Sec.   170.315(c)(1)-(3)......  Clinical quality          Sec.   170.314(c)(1)-(3).....  Clinical quality
                                 measures.                                                measures.
Sec.   170.315(d)(1)..........  Authentication, access    Sec.   170.314(d)(1).........  Authentication, access
                                 control, &                                               control, &
                                 authorization.                                           authorization.
Sec.   170.315(d)(2)..........  Auditable events and      Sec.   170.314(d)(2).........  Auditable events and
                                 tamper resistance.                                       tamper resistance.
Sec.   170.315(d)(3)..........  Audit report(s).........  Sec.   170.314(d)(3).........  Audit report(s).
Sec.   170.315(d)(4)..........  Amendments..............  Sec.   170.314(d)(4).........  Amendments.
Sec.   170.315(d)(5)..........  Automatic log-off.......  Sec.   170.314(d)(5).........  Automatic log-off.
Sec.   170.315(d)(6)..........  Emergency access........  Sec.   170.314(d)(6).........  Emergency access.
Sec.   170.315(d)(7)..........  End-user device           Sec.   170.314(d)(7).........  End-user device
                                 encryption.                                              encryption.
Sec.   170.315(d)(8)..........  Integrity...............  Sec.   170.314(d)(8).........  Integrity.
Sec.   170.315(d)(9)..........  Accounting of             Sec.   170.314(d)(9).........  Accounting of
                                 disclosures.                                             disclosures.
Sec.   170.315(e)(1)..........  View, download, &         Sec.   170.314(e)(1).........  View, download, &
                                 transmit to 3rd party.                                   transmit to 3rd party.
Sec.   170.315(e)(2)..........  Clinical summary........  Sec.   170.314(e)(2).........  Clinical summary.
Sec.   170.315(e)(3)..........  Secure messaging........  Sec.   170.314(e)(3).........  Secure messaging.
Sec.   170.315(f)(1) & (f)(2).  Immunization information/ Sec.   170.314(f)(1) & (f)(2)  Immunization
                                 Transmission to                                          information/
                                 immunization registries.                                 Transmission to
                                                                                          immunization
                                                                                          registries.
Sec.   170.315(f)(3)..........  Transmission to public    Sec.   170.314(f)(3).........  Transmission to public
                                 health agencies--                                        health agencies--
                                 syndromic surveillance.                                  syndromic
                                                                                          surveillance.
Sec.   170.315(f)(4)..........  Transmission of           Sec.   170.314(f)(4).........  Transmission of
                                 reportable lab tests &                                   reportable lab tests &
                                 values/results.                                          values/results.
Sec.   170.315(f)(5)..........  Cancer case information.  Sec.   170.314(f)(5).........  Cancer case
                                                                                          information.
Sec.   170.315(f)(6)..........  Transmission to cancer    Sec.   170.314(f)(6).........  Transmission to cancer
                                 registries.                                              registries.
Sec.   170.315(g)(1)..........  Automated numerator       Sec.   170.314(g)(1).........  Automated numerator
                                 recording.                                               recording.

[[Page 10916]]

 
Sec.   170.315(g)(2)..........  Automated measure         Sec.   170.314(g)(2).........  Automated measure
                                 calculation.                                             calculation.
Sec.   170.315(g)(3)..........  Safety-enhanced design..  Sec.   170.314(g)(3).........  Safety-enhanced design.
Sec.   170.315(g)(4)..........  Quality management        Sec.   170.314(g)(4).........  Quality management
                                 system.                                                  system.
----------------------------------------------------------------------------------------------------------------

C. Gap Certification Eligibility Table for 2015 Edition EHR 
Certification Criteria

    We define ``gap certification'' at 45 CFR 170.502 as ``the 
certification of a previously certified Complete EHR or EHR Module(s) 
to: (1) [a]ll applicable new and/or revised certification criteria 
adopted by the Secretary at subpart C of [part 170] based on the test 
results of a NVLAP-accredited testing laboratory; and (2) [a]ll other 
applicable certification criteria adopted by the Secretary at subpart C 
of [part 170] based on the test results used to previously certify the 
Complete EHR or EHR Module(s)'' (for further explanation, see 76 FR 
1307-1308). Our gap certification policy focuses on the differences 
between certification criteria that are adopted through rulemaking at 
different points in time. This allows EHR technology to be certified to 
only the differences between certification criteria editions rather 
than requiring EHR technology to be fully retested and recertified to 
certification criteria that remain unchanged from one edition to the 
next and for which previously acquired test results are sufficient. 
Under our gap certification policy, ``unchanged'' criteria (see 77 FR 
54248 for further explanation) are eligible for gap certification, and 
each ONC-ACB has discretion over whether it will provide the option of 
gap certification.
    For the purposes of gap certification, Table 4 below provides a 
crosswalk of ``unchanged'' 2015 Edition EHR certification criteria to 
the corresponding 2014 Edition certification criteria. We note that 
with respect to the 2015 Edition certification criteria proposed for 
adoption at Sec.  170.315(g)(1) through (g)(3) that gap certification 
eligibility for these criteria is fact-specific and will depend on any 
modifications made to the specific certification criteria to which 
these ``paragraph (g)'' certification criteria apply.

               Table 4--Gap Certification Eligibility for 2015 Edition EHR Certification Criteria
----------------------------------------------------------------------------------------------------------------
                      2015 Edition                                             2014 Edition
----------------------------------------------------------------------------------------------------------------
                                   Title of regulation                                     Title of regulation
      Regulation section                paragraph               Regulation section              paragraph
----------------------------------------------------------------------------------------------------------------
Sec.   170.315(a)(1)..........  Computerized physician    Sec.   170.314(a)(1).........  Computerized Provider
                                 order entry--                                            Order Entry.
                                 medications.
Sec.   170.315(a)(3)..........  Computerized physician
                                 order entry--radiology/
                                 imaging..
Sec.   170.315(a)(4)..........  Drug-drug, drug-allergy   Sec.   170.314(a)(2).........  Drug-drug, drug-allergy
                                 interaction checks..                                     interaction checks.
Sec.   170.315(a)(6)..........  Vital signs, BMI, &       Sec.   170.314(a)(4).........  Vital signs, BMI, &
                                 growth charts.                                           growth charts.
Sec.   170.315(a)(7)..........  Problem list............  Sec.   170.314(a)(5).........  Problem list.
Sec.   170.315(a)(8)..........  Medication list.........  Sec.   170.314(a)(6).........  Medication list.
Sec.   170.315(a)(9)..........  Medication allergy list.  Sec.   170.314(a)(7).........  Medication allergy
                                                                                          list.
Sec.   170.315(a)(12).........  Drug-formulary checks...  Sec.   170.314(a)(10)........  Drug-formulary checks.
Sec.   170.315(a)(13).........  Smoking status..........  Sec.   170.314(a)(11)........  Smoking status.
Sec.   170.315(a)(14).........  Image results...........  Sec.   170.314(a)(12)........  Image results.
Sec.   170.315(a)(16).........  Patient list creation...  Sec.   170.314(a)(14)........  Patient list creation.
Sec.   170.315(a)(18).........  Electronic medication     Sec.   170.314(a)(16)........  Electronic medication
                                 administration record.                                   administration record.
Sec.   170.315(a)(19).........  Advance directives......  Sec.   170.314(a)(17)........  Advance directives.
Sec.   170.315(b)(3)..........  Electronic prescribing..  Sec.   170.314(b)(3).........  Electronic prescribing.
Sec.   170.315(c)(1)-(3)......  Clinical quality          Sec.   170.314(c)(1)-(3).....  Clinical quality
                                 measures.                                                measures.
Sec.   170.315(d)(1)..........  Authentication, access    Sec.   170.314(d)(1).........  Authentication, access
                                 control, &                                               control, &
                                 authorization.                                           authorization.
Sec.   170.315(d)(3)..........  Audit report(s).........  Sec.   170.314(d)(3).........  Audit report(s).
Sec.   170.315(d)(4)..........  Amendments..............  Sec.   170.314(d)(4).........  Amendments.
Sec.   170.315(d)(5)..........  Automatic log-off.......  Sec.   170.314(d)(5).........  Automatic log-off.
Sec.   170.315(d)(6)..........  Emergency access........  Sec.   170.314(d)(6).........  Emergency access.
Sec.   170.315(d)(7)..........  End-user device           Sec.   170.314(d)(7).........  End-user device
                                 encryption.                                              encryption.
Sec.   170.315(d)(8)..........  Integrity...............  Sec.   170.314(d)(8).........  Integrity.
Sec.   170.315(d)(9)..........  Accounting of             Sec.   170.314(d)(9).........  Accounting of
                                 disclosures.                                             disclosures.
Sec.   170.315(e)(3)..........  Secure messaging........  Sec.   170.314(e)(3).........  Secure messaging.
Sec.   170.315(f)(1)..........  Immunization information  Sec.   170.314(f)(1).........  Immunization
                                                                                          information.
Sec.   170.315(f)(3)#.........  Transmission to public    Sec.   170.314(f)(3)#........  Transmission to public
                                 health agencies--                                        health agencies--
                                 syndromic surveillance.                                  syndromic surveillance
Sec.   170.315(f)(5)..........  Cancer case information.  Sec.   170.314(f)(5).........  Cancer case
                                                                                          information.
Sec.   170.315(g)(4)..........  Quality management        Sec.   170.314(g)(4).........  Quality management
                                 system.                                                  system.
----------------------------------------------------------------------------------------------------------------
# If certified to the revised 2014 Edition version of this criterion after the effective date of the 2015
  Edition Final Rule. For further information on this distinction, please see the gap certification discussion
  under the ``Transmission to Public Health Agencies--Syndromic Surveillance'' in section III.A of this
  preamble.


[[Page 10917]]

D. HIT Definitions

1. CEHRT and Base EHR Definitions
    We propose revisions to the CEHRT and Base EHR definitions at Sec.  
170.102 for the purpose of including the proposed 2015 Edition EHR 
certification criteria in those definitions.
    We propose to revise the CEHRT definition for FY/CY 2014 and 
subsequent years to include reference to the 2015 Edition EHR 
certification criteria. Under our proposal, EPs, EHs, and CAHs would 
have the flexibility to use EHR technology that has been certified to 
either the 2014 Edition or the 2015 Edition, or a combination of both 
editions, to meet the CEHRT definition for FY/CY 2014 and subsequent 
years. We believe this proposal would enhance the already flexible 
CEHRT definition available to EPs, EHs, and CAHs by enabling them to 
use EHR technology certified to the 2015 Edition to meet the CEHRT 
definition and would permit an incremental transition from the adoption 
and implementation of EHR technology certified from one edition of EHR 
certification criteria to another.
    We propose to include in the Base EHR definition the 2015 Edition 
EHR certification criteria that correspond to the 2014 Edition EHR 
certification criteria already specified in the Base EHR definition 
(i.e., CPOE, demographics, problem list, medication list, medication 
allergy list, CDS, CQMs, transitions of care, data portability, and 
privacy and security). Our proposed changes to the Base EHR definition 
would permit EPs, EHs, and CAHs to meet the Base EHR definition with 
EHR technology certified to either the 2014 Edition or the 2015 
Edition, or a combination of both. With the 2014 Edition, EHR 
technology developers have the ability to market their EHR technology 
as meeting the Base EHR definition when appropriate. We would continue 
this policy upon the adoption of the 2015 Edition EHR certification 
criteria.
2. Complete EHR
    We propose to discontinue use of the Complete EHR definition as a 
regulatory concept beginning with the 2015 Edition EHR certification 
criteria. Currently, there are definitions for ``Complete EHR, 2011 
Edition'' and ``Complete EHR, 2014 Edition'' under Sec.  170.102. 
However, under our proposal, we would not add a new definition for 
``Complete EHR, 2015 Edition.'' As a result, ONC-ACBs would not be able 
to issue Complete EHR certifications to EHR technology certified to the 
2015 Edition EHR certification criteria. Despite adopting a revised, 
more flexible, CEHRT definition in the 2014 Edition Final Rule that 
permits EPs, EHs, and CAHs to use (if available) EHR Modules certified 
to the minimum number of certification criteria necessary to support 
their achievement of the specific MU Stage they needed to meet, we 
maintained the Complete EHR concept and Complete EHR certification to 
the 2014 Edition. We assumed some EPs, EHs, and CAHs might prefer the 
relative simplicity a Complete EHR certification offered from a 
regulatory compliance perspective compared to the flexibility and 
responsibility offered by an EHR Module(s) approach to the new CEHRT 
definition. While we thought the continued availability of Complete EHR 
certifications would be helpful for some EPs, EHs, and CAHs, we did not 
believe that for the 2014 Edition the use of Complete EHRs would be the 
primary way the CEHRT definition would be met because the revised, more 
flexible, CEHRT definition adopted in the 2014 Edition Final Rule 
permitted EPs, EHs and CAHs to have less than a certified Complete EHR 
to meet the CEHRT definition. We believe this proposed rule serves as 
an ideal time to propose discontinuing the Complete EHR concept 
beginning with the 2015 Edition and before we propose the 2017 Edition.
    The following explains our rationale for discontinuing the Complete 
EHR concept beginning with the 2015 Edition:
    (1) The Complete EHR definition initially was intended to support 
the original CEHRT definition established in the 2011 Edition Final 
Rule under Sec.  170.102. As a general summary, the original CEHRT 
definition required an EP, EH, and CAH to have EHR technology that met 
ALL of the certification criteria adopted for an applicable setting 
(ambulatory or inpatient). The ``Complete EHR'' term and definition was 
meant to convey that all applicable certification criteria had been met 
and the statutory requirements of the Qualified EHR definition had been 
fulfilled. As noted above, the current CEHRT definition and Complete 
EHR definition no longer share the same symmetry. In fact, the 2014 
Edition Complete EHR definition now exceeds the CEHRT definition's 
requirements as to the number of certification criteria to which an EHR 
technology would need to be certified to meet the CEHRT definition.
    (2) Since publication of the 2014 Edition Final Rule, we have 
received stakeholder feedback through email questions and during 
educational presentations and other outreach that demonstrates 
confusion about the interplay between the CEHRT definition, the Base 
EHR definition (adopted as part of the 2014 Edition Final Rule), and 
the Complete EHR definition. Stakeholders have correctly concluded that 
a certified 2014 Edition Complete EHR could be used to meet the CEHRT 
definition, but some believe incorrectly that their only regulatory 
option to meet the CEHRT definition is to adopt a certified Complete 
EHR. Even though, under the CEHRT definition for FY/CY 2014 and 
subsequent years in Sec.  170.102, they only need EHR technology (EHR 
Modules) certified to the 2014 Edition EHR certification criteria that 
meets the Base EHR definition (a finite set of capabilities) and 
includes all other capabilities that are necessary to meet the 
objectives and measures and successfully report CQMs for the MU Stage 
they are attempting to achieve.
    (3) A Complete EHR is not necessarily ``complete'' or sufficient 
when it comes to an EP's, EH's, or CAH's attempt to achieve MU. For 
example, based on the ``Complete EHR, 2014 Edition'' definition, it may 
not be certified to particular CQMs on which an EP intends to report 
and it may not have been certified to capabilities included in optional 
certification criteria that an EP needs for MU, such as the 2014 
Edition cancer reporting certification criteria (Sec.  170.314(f)(5) 
and (6)). Thus, if we were to continue this policy approach, we believe 
this discrepancy would only grow and cause greater confusion over time.
    (4) Stakeholder feedback to us since the 2014 Edition Final Rule 
(via conference and webinar question and answer sessions, public 
meetings, emails) and the data currently available on the CHPL 
indicates that some EHR technology developers have continued to seek 
only a 2014 Edition Complete EHR certification and, thus, only plan to 
offer a certified Complete EHR as a solution to customers. While we 
recognize EHR technology developers may choose to pursue various 
approaches for designing and marketing their products, we are in a 
position to modify our policy so that it does not encourage EHR 
technology developers to offer only a single certified solution. In 
general, we believe the decision to seek certification only for a 
Complete EHR serves to defeat the flexibility provided by the ``new'' 
CEHRT definition. Consequently, by discontinuing the availability of 
the Complete EHR certification, the EHR technology market could be 
driven by EHR technology developers competing based more on the 
capabilities included

[[Page 10918]]

in their EHR technology than on the type of certification issued 
(Complete EHR or EHR Module).
    (5) The discrepancy between what any single EP, EH, or CAH needs to 
achieve MU and the Complete EHR definition will likely only grow more 
disparate when we adopt certification criteria in a 2017 Edition 
rulemaking to support MU Stage 3. At that time, there may be EPs, EHs, 
and CAHs attempting to achieve each of the three stages of MU, but a 
Complete EHR in line with the current definition would likely include 
capabilities that support core and menu objectives and measures for all 
MU stages.
    (6) Discontinuing the use of the Complete EHR concept would be 
consistent with the instruction of Executive Order (EO) 13563 to 
identify and consider approaches that make the agency's regulatory 
program more effective or less burdensome in achieving the regulatory 
objectives. To illustrate, we would not need to designate EHR 
certification criteria as mandatory or optional in our regulation text 
as these categories were specifically developed to accommodate the 
Complete EHR definition (i.e., cases where EHR technology would 
otherwise have to be certified to a criterion solely because it is 
required in order to satisfy the Complete EHR certification).
    We welcome comments on our proposal to discontinue use of the 
Complete EHR concept beginning with the 2015 Edition. We emphasize that 
this proposal would have no impact on current 2014 Edition Complete EHR 
certifications or in using a 2014 Edition Complete EHR to meet the 
current CEHRT definition. Further, this proposal would not require EHR 
Module certification to only a specific set of certification criteria 
nor would it change what an EHR developer could present for EHR Module 
certification (e.g., EHR technology developed to meet all the 
certification criteria adopted for the ambulatory or inpatient setting 
could be presented for certification as an EHR Module). As an 
alternative to the proposal, if we were to keep the Complete EHR 
concept and definition for the 2015 Edition, we propose and seek 
comment on the following two approaches:
     Continue the same policy of adopting an edition-specific 
Complete EHR (e.g., 2015 Edition Complete EHR). In addition to the 
significant drawbacks discussed above that come with keeping the 
Complete EHR definition, this approach would also be inefficient 
because it would continue the need for regular regulatory changes, 
including adopting new edition-specific Complete EHR definitions and 
making changes to the Base EHR definition to accommodate various 
editions of Complete EHRs.
     Define a Complete EHR as ``EHR technology that has been 
developed to meet, at a minimum, all mandatory certification criteria 
of an edition of EHR certification criteria adopted by the Secretary 
for either an ambulatory setting or inpatient setting and meets the 
Base EHR definition.'' ONC-ACBs would be responsible for issuing 
Complete EHR certifications that specify the edition the Complete EHR 
was certified to. For example, EHR technology certified as a Complete 
EHR to the 2015 Edition would then be issued a certification that 
specifies that it is a 2015 Edition Complete EHR. This would also be 
evident through listing on the CHPL. This approach remains consistent 
with the policies we set forth in the 2014 Edition Final Rule that 
specify that a certification cannot be issued for a Complete EHR based 
on a combination of editions of EHR certification criteria and that 
certification must specify what edition an EHR technology is compliant 
with.
3. Common MU Data Set
    We propose to change to the ``Common MU Data Set'' definition in 
Sec.  170.102 to accommodate our proposed change to the preferred 
language standard as discussed earlier in this preamble under the 2015 
Edition ``demographics'' certification criterion (Sec.  170.315(a)(5)). 
This proposal would not change the preferred language standard 
identified in the ``Common MU Data Set'' definition for certification 
to the 2014 Edition EHR certification criteria (i.e., ISO 639-2 
constrained by ISO 639-1). Our proposed change to the ``Common MU Data 
Set'' definition will only affect certification to the 2015 Edition EHR 
certification criteria that reference the ``Common MU Data Set.'' 
Stated another way, for certification to these certification criteria 
under the 2015 Edition, EHR technology would need to meet the preferred 
language standard we eventually adopt in a subsequent final rule.
4. Cross Referenced FDA Definitions
    As discussed in our proposal for the 2015 Edition ``implantable 
device list'' certification criterion, we propose to adopt in Sec.  
170.102 new definitions for ``Implantable Device,'' ``Unique Device 
Identifier,'' ``Device Identifier,'' and ``Production Identifier.'' We 
propose to adopt the same definitions already provided to these phrases 
at 21 CFR 801.3. Again, we believe adopting these definitions in our 
rule will prevent any interpretation ambiguity and ensure that each 
phrase's specific meaning reflects the same meaning given to them in 
the Unique Device Identification System Final Rule at in 21 CFR 801.3. 
Capitalization was purposefully applied to each word in these defined 
phrases in order to signal to readers that they have specific meanings.

IV. Provisions of the Proposed Rule Affecting the ONC HIT Certification 
Program

A. Applicability

    We propose to revise the ``applicability'' section (Sec.  170.501) 
for the ONC HIT Certification Program to clearly indicate that 
references to the term Complete EHR and Complete EHR certification do 
not apply to certification in accordance with the 2015 Edition EHR 
certification criteria and any subsequent edition of certification 
criteria adopted by the Secretary under subpart C. This proposal is 
consistent with our proposal to discontinue the use of the term 
``Complete EHR'' and Complete EHR certification beginning with the 2015 
Edition EHR certification criteria as discussed under the section 
entitled ``Complete EHR'' of this preamble.

B. Non-MU EHR Technology Certification

    Certification to the 2014 Edition and proposed 2015 Edition 
``automated numerator recording'' certification criteria (Sec. Sec.  
170.314(g)(1) and 170.315(g)(1)) and the ``automated measure 
calculation'' certification criteria (Sec. Sec.  170.314(g)(2) and 
170.315(g)(2)) are important to ensure that EPs, EHs, and CAHs have 
efficient and accurate means for recording, calculating and reporting 
data for MU attestation. Therefore, we have taken steps to ensure EHR 
technology has these necessary capabilities by including certification 
requirements in Sec.  170.550(f)(1) for EHR Modules that are certified 
to the 2014 Edition and proposing similar requirements in Sec.  
170.550(g) for EHR Modules that would be certified to the 2015 Edition, 
including requirements for certification to proposed Sec.  
170.315(g)(5) (``non-percentage-based measure report''). While these 
regulatory requirements are intended to provide assurance that EHR 
Modules can support EPs', EHs', and CAHs' MU attestation needs, they 
preclude the efficient certification of EHR technology designed for 
purposes other than achieving MU.
    For example, EHR technology is often designed for other types of 
health care settings where individual or

[[Page 10919]]

institutional health care providers are not typically eligible to 
qualify for MU incentive payments under Medicare or Medicaid, such as 
behavioral health or long-term post-acute care settings. EHR technology 
is also designed, for example, primarily to support HIE and without 
regard for whether the health care provider using the technology seeks 
to achieve MU. In these examples, a developer could choose to present 
the EHR technology for certification as an EHR Module under the ONC HIT 
Certification Program for various reasons, such as if certification 
were to be required by another HHS program, or simply for the 
assurances that certification provides. However, if those EHR 
technologies were to be certified as 2014 Edition EHR Modules under the 
ONC HIT Certification Program in accordance with the existing 
regulations, they would be subject to the requirements of Sec.  
170.550(f)(1). In other words, EHR technology developers would be 
required to design their EHR technology to include specific 
capabilities related to MU measure recording, calculation, and 
reporting, even though the EHR technology would not be intended for MU.
    We want to avoid such situations and instead make our regulatory 
structure more flexible and extensible such that it can more easily 
accommodate health IT certification for other purposes beyond MU. 
Additionally, we seek to ensure that under the ONC HIT Certification 
Program there is a clear distinction between EHR technology certified 
to support MU attestation requirements and EHR technology that is not. 
This distinction is important so that purchasers can more easily 
compare and select EHR technology that meets their needs. We propose to 
address these issues, starting with EHR technology that is certified to 
the 2015 Edition, by:
     Establishing an ``MU EHR Module'' definition and a ``non-
MU EHR Module'' definition under the main ``EHR Module'' definition at 
Sec.  170.102. An ``MU EHR Module'' would be defined as any service, 
component, or combination thereof that is designed for purposes of the 
EHR Incentive Programs and can meet the requirements of at least one 
certification criterion adopted by the Secretary. A ``non-MU EHR 
Module'' would be defined as any service, component, or combination 
thereof that is designed for any purpose other than the EHR Incentive 
Programs and can meet the requirements of at least one certification 
criterion adopted by the Secretary.
     Revising Sec.  170.550 to require the certification of 
only MU EHR Modules, as applicable, to the proposed 2015 Edition 
``automated numerator recording'' certification criterion (Sec.  
170.315(g)(1)), the ``automated measure calculation'' certification 
criterion (Sec.  170.315(g)(2)), and the ``non-percentage-based measure 
use report'' certification criterion (Sec.  170.315(g)(5)). This 
proposal would ensure that EHR technology designed for MU purposes and 
certified to certification criteria that include capabilities that 
support percentage-based and/or non-percentage-based MU measures are 
capable of electronically performing the associated recording and 
calculation of measure activities for MU purposes.
     Requiring both MU EHR Modules and Non-MU EHR Modules to be 
certified, as applicable, to Sec.  170.315(g)(3) (Safety-enhanced 
design) and/or (g)(4) (Quality system management). These proposed 
requirements can be found in Sec.  170.550(g)(2) and (3), respectively, 
and maintain the policy approach established with certification to the 
2014 Edition (see Sec.  170.550(f)(2) and (3)) that ensures all EHR 
Modules are certified to these specific safety and quality 
certification criteria, as appropriate.
     Revising Sec.  170.523(k)(1)(iii) to make clear that 
beginning with certifications issued to the 2015 Edition, the 
requirement in that section would only apply to MU EHR Modules. For EHR 
technology certified to the 2014 Edition, Sec.  170.523(k)(1)(iii) 
continues to apply to Complete EHRs and all EHR Modules. We further 
note that we are not proposing to revise Sec.  170.523(k)(1)(i) to 
require a EHR Module developer to state whether its 2015 Edition EHR 
Module is ``MU'' or ``non-MU'' on its Web site nor in any marketing 
materials, communications statements, and other assertions related to 
the EHR Module's certification. An EHR Module developer must still list 
the certification criteria that the EHR Module was certified to per 
Sec.  170.523(k)(1)(ii). We also anticipate some form of distinct 
listing of MU and non-MU EHR Modules on the CHPL, as we expect ONC-ACBs 
will report whether the EHR Modules they certify to the 2015 Edition 
are MU EHR Modules or Non-MU EHR Modules. This is due to the fact that 
ONC-ACBs would have different certification responsibilities for MU EHR 
Modules and non-MU EHR Modules per proposed Sec.  170.550(g). We 
believe these steps will be sufficient in providing market clarity.
    We are not proposing to apply the certification concept of MU EHR 
Module and non-MU EHR Module to the 2014 Edition because of the 
inconsistency and potential confusion it would create regarding EHR 
Modules that have already been certified and, more importantly, because 
it would be infeasible to implement for the purposes of establishing a 
distinction on the CHPL in a timely manner to avoid such potential 
confusion. This decision is also in keeping with how we have handled 
prior changes to the certification of EHR technology. With the new 
requirements that we adopted for reporting test results hyperlinks and 
requiring price transparency related to MU, we only applied those 
requirements to EHR technology certified to the 2014 Edition and not 
the 2011 Edition.\103\
---------------------------------------------------------------------------

    \103\ http://www.healthit.gov/policy-researchers-implementers/26-question-10-12-026.
---------------------------------------------------------------------------

    We wish to make clear that our proposed approach continues to leave 
EHR Module developers with discretion on how to develop and present 
their EHR technology for certification. We expect that an EHR Module 
developer would determine whether they want their EHR Module certified 
as a MU or non-MU EHR Module and then seek the appropriate testing and 
certification of their EHR Module from an accredited testing laboratory 
and an ONC-ACB, respectively. Our proposed approach would also not 
prevent MU EHR Modules from being sold or used for non-MU proposes 
since in theory a MU EHR Module could be used for non-MU purposes, 
although it would have certain MU-related capabilities (for example, 
automated numerator recording and automated measure calculation) that 
may be extraneous for some types of users or settings.
    This proposal is based on our belief that EHR technology developers 
who design EHR technology for non-MU purposes and settings (e.g., broad 
electronic health information exchange or behavioral health settings 
staffed mainly by MU ineligibles) find the automated numerator and 
automated measure calculation certification criteria requirements as 
unnecessary burdens and resource investments (i.e., to have to program 
MU-specific rules into their software just to get certified). 
Similarly, we believe that because of the specific ways in which MU 
measures are structured non-MU health care providers would find little 
benefit in getting EHR utilization reports showing MU performance. 
Accordingly, we request public comment, particularly from EHR 
technology developers that design technology for non-MU purposes and 
settings and providers who use EHR technology for non-MU purposes or in 
non-MU settings, on whether:

[[Page 10920]]

     Our regulatory burden assumption is correct related to EHR 
technology developers having to meet the automated numerator and 
automated measure calculation certification criteria to obtain 
certification;
     The automated numerator and automated measure calculation 
certification criteria requirements pose more of burden for small EHR 
technology developers that design EHR technology for non-MU purposes 
and settings (e.g., inhibit their ability to compete with large EHR 
technology developers that have more resources to develop and get 
certified to the automated numerator and automated measure calculation 
certification criteria even if their customers will not use the 
capabilities); and
     Health care providers using EHR technology for non-MU 
purposes and settings would benefit from or be hindered by paying for 
and/or using EHR technology certified to the automated numerator and 
automated measure calculation certification criteria.
    We also request comment on how best to implement our proposed 
approach if we were to adopt it in a subsequent final rule. In this 
regard, we request feedback on the following questions:
     Would the process for testing and certification be clear 
under our approach as described? Should EHR technology developers 
simply inform ONC-ACBs as to the type of EHR Module certification they 
seek (i.e., MU or non-MU)?
     How should we distinguish non-MU EHR Modules on the CHPL? 
Should we have separate listings of MU and non-MU EHR Modules? Are 
there other options?
     How should we indicate and list the availability of MU EHR 
Modules for use beyond MU purposes?

C. ONC Regulations FAQ 28

    In ONC regulations FAQ 28,\104\ we provide guidance on the 
application of Sec.  170.314(g)(1) and (g)(2) to the certification of 
Complete EHRs and EHR Modules.
---------------------------------------------------------------------------

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

1. MU EHR Modules
    We propose to apply the guidance expressed in FAQ 28 to the 
certification of MU EHR Modules to the 2015 Edition ``automated 
numerator recording'' certification criterion (Sec.  170.315(g)(1)) and 
the ``automated measure calculation'' certification criterion (Sec.  
170.315(g)(2)). As we state in FAQ 28 and in the 2014 Edition Final 
Rule (77 FR 54186), ONC-ACBs can certify an EHR Module to either the 
2014 Edition ``automated numerator recording'' certification criterion 
or the 2014 Edition ``automated measure calculation'' certification 
criterion. To provide regulatory clarity, we propose to revise Sec.  
170.550(f)(1) to specify this flexibility for the certification of EHR 
Modules to the 2014 Edition and propose the same flexibility in Sec.  
170.550(g)(1) for MU EHR Modules certified to the 2015 Edition.
    Last, we also clarify that an EHR Module (or MU EHR Module, with 
regard to the 2015 Edition) could be certified to only the ``automated 
measure calculation'' certification criterion (Sec. Sec.  170.314(g)(2) 
or proposed 170.315(g)(2)) in situations where the EHR Module does not 
include a capability that supports a percentage-based MU objective and 
measure, but can meet the requirements of the ``automated measure 
calculation'' certification criterion (Sec. Sec.  170.314(g)(2) or 
proposed 170.315(g)(2)). An example of this would be an ``analytics'' 
EHR Module where data is fed from other EHR technology and the EHR 
Module can record the requisite numerators, denominators and create the 
necessary percentage report as specified in the ``automated measure 
calculation'' certification criterion. In these situations, Sec.  
170.550(f)(1) or (g)(1) would not be implicated or need to be applied.
2. Complete EHRs
    We propose to revise Sec.  170.314(g)(1) to be an optional 
certification criterion as a means of providing regulatory clarity for 
the certification of Complete EHRs to the 2014 Edition. This proposed 
revision implements our guidance provided in FAQ 28. In FAQ 28 we 
stated that EHR technology issued a 2014 Edition Complete EHR 
certification must be certified to Sec.  170.314(g)(2) because it is a 
mandatory certification criterion consistent with the 2014 Edition 
Complete EHR definition requiring certification to all mandatory 
certification criteria for a particular setting (ambulatory or 
inpatient), but not Sec.  170.314(g)(1) (even though it is currently 
designated as a mandatory certification criterion) because a 2014 
Edition Complete EHR would have demonstrated capabilities beyond those 
included in Sec.  170.314(g)(1) by being certified to (g)(2). 
Effectuating this proposal (to make Sec.  170.314(g)(1) optional) would 
provide greater regulatory clarity for ONC-ACBs as they determine 
whether EHR technology meets the 2014 Edition Complete EHR definition.
    As noted previously in this preamble, we propose to discontinue the 
use of the Complete EHR concept beginning with the 2015 Edition. If we 
were to retain the Complete EHR concept for the 2015 Edition, we 
propose to take the same approach for Complete EHRs as specified in FAQ 
28 and in our proposed regulatory changes to Sec.  170.314(g)(1). That 
is, Complete EHRs would need to be certified to the mandatory 
``automated measure calculation'' certification criterion, but not the 
2015 Edition ``automated numerator recording'' certification criterion 
as that would become an optional certification criterion.

D. Patient List Creation Certification Criteria

    The 2014 Edition and proposed 2015 Edition ``patient list 
creation'' certification criteria (Sec.  170.314(a)(14) and Sec.  
170.315(a)(16), respectively) include capabilities that support two MU 
objectives, one with a percentage-based measure and one without (i.e., 
``use clinically relevant information to identify patients who should 
receive reminders for preventive/follow-up care and send these patients 
the reminders, per patient preference'' (``patient reminders'') and 
``generate lists of patients by specific conditions to use for quality 
improvement, reduction of disparities, research, or outreach,'' 
respectively). In situations where EHR technology is presented for 
certification to a ``patient list creation'' certification criterion 
(2014 or 2015 Edition) and does not include a capability to support 
``patient reminders,'' we clarify it would not need to be certified to 
the ``automated numerator recording'' certification criterion 
(Sec. Sec.  170.314(g)(1) for the 2014 Edition and 170.315(g)(1) for 
the 2015 Edition) nor the ``automated measure calculation'' 
certification criterion (Sec. Sec.  170.314(g)(2) for the 2014 Edition 
and 170.315(g)(2) for the 2015 Edition) for ``patient reminders'' 
percentage-based measure capabilities.

E. ISO/IEC 17065

    Section 170.503(b)(1) requires applicants for ONC-Approved 
Accreditor (ONC-AA) status to provide a detailed description of their 
experience evaluating the conformance of certification bodies to ISO/
IEC Guide 65:1996 (Guide 65). Section 170.503(e)(2) requires the ONC-AA 
to verify that the certification bodies it accredits and ONC-ACBs 
conform to, at a minimum, ISO/IEC Guide 65:1996. The International 
Organization for Standardization (ISO) has recently

[[Page 10921]]

issued ISO/IEC 17065: 2012 \105\ (ISO 17065), which cancels and 
replaces Guide 65. The major changes that have been made as compared 
with Guide 65 are as follows:
---------------------------------------------------------------------------

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

     Restructuring this International Standard based on the 
common structure adopted by ISO/CASCO;
     Modifications based on ISO/PAS 17001, ISO/PAS 17002, ISO/
PAS 17003, ISO/PAS 17004 and ISO/PAS 17005;
     Introduction of the ISO/IEC 17000 functional approach in 
the process requirements of Clause 7;
     Information on the application of this International 
Standard for processes and services in Annex B;
     Revision of the terms and definitions in Clause 3;
     Improvement of the impartiality requirements (mechanism);
     Consolidation of the management system requirements in 
Clause 8;
     Inclusion of principles for product certification bodies 
and their activities in Annex A;
     Improvement by taking into account IAF GD 5; and
     Inclusion of a reference to certification schemes, for 
which further information is provided in ISO/IEC 17067.
    The current ONC-AA, American National Standards Institute (ANSI) 
has already notified the certification bodies it accredits that it will 
transition accreditation only to ISO 17065 and that all certification 
bodies it accredits should be accredited to ISO 17065 no later than 
September 15, 2015. Accordingly, because ISO has replaced Guide 65 with 
ISO/IEC 17065, we propose to revise Sec.  170.503(b)(1) and (e)(2) to 
replace the references to Guide 65 with ISO 17065. For Sec.  
170.503(b)(1), the change would be effective as of the effective date 
of the 2015 Edition final rule that would follow this proposed rule. We 
anticipate that date would occur after we select an accreditation body 
as the ONC-AA for the next three-year term as ANSI's current term will 
expire in June 2014. As such, when we next need to assess applicants 
for ONC-AA status in early 2017, we would expect that any applicant 
will by then have experience evaluating the conformance of 
certification bodies to ISO 17065. For Sec.  170.503(e)(2), we propose 
to require compliance with ISO 17065 beginning in FY 2016 (in other 
words, as of October 1, 2015). This compliance date should provide 
sufficient time for certification bodies that are interested in serving 
as ONC-ACBs, as well as existing ONC-ACBs, to be accredited to ISO 
17065 by the ONC-AA. We welcome comments on these proposals.
    We also propose to revise our references to ISO/IEC standards 
17011, 17065 and Guide 65 in Sec.  170.503 by removing or not including 
the date reference for each standard. The published date information 
for each standard will continue to be listed in Sec.  170.599. This 
approach aligns with guidance from the Office of the Federal Register.

F. ONC Certification Mark

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

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

    We propose to require ONC-ACBs to use the Mark in connection with 
HIT they certify under the ONC HIT Certification Program. The required 
use of a singular identifying mark would provide consistency in the 
recognition of HIT certified under the ONC HIT Certification Program 
and mitigate any potential market confusion for purchasers of HIT 
products certified under the ONC HIT Certification Program. The 
required use of the Mark by all ONC-ACBs for products they certify 
under the ONC HIT Certification Program would offer more clarity and 
assurance to purchasers as compared to the use of separate and distinct 
marks by each ONC-ACB to indicate a product has been certified under 
the ONC HIT Certification Program. The required use of the Mark would 
also make clear that an HIT product was certified under the ONC HIT 
Certification Program versus another certification program for HIT 
(e.g., in cases where a certification body is both an ONC-ACB and 
administers other certification programs outside of the ONC HIT 
Certification Program).
    We propose to revise Sec.  170.523 (``Principles of Proper 
Conduct'') to require ONC-ACBs to display the Mark on all 
certifications issued under the ONC HIT Certification Program in a 
manner that complies with the Criteria and Terms of Use for the ONC 
Certified HIT Certification and Design Mark (``Terms of Use'').\107\ In 
addition, we propose to revise Sec.  170.523 to require ONC-ACBs to 
ensure that use of the Mark by HIT developers whose products are 
certified under the ONC HIT Certification Program is compliant with the 
Terms of Use. In the event that the Terms of Use are revised or 
updated, compliance with the most recent version would be required.
---------------------------------------------------------------------------

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

G. ``Certification Packages'' for EHR Modules

    As we look toward the potential expansion of our certification 
program to support the various types of health care providers who are 
not eligible for EHR incentive payments under Medicare or Medicaid, we 
recognize that we can continue to improve the ease with which our 
regulatory concepts (for both MU and non-MU purposes) can be 
communicated to the general public and to EHR Module purchasers. In 
that regard, we believe it would be helpful to establish the concept of 
predefined ``certification packages'' that would reflect groupings of 
certification criteria. We intend for this concept to make it easier 
for stakeholders to communicate and understand the functionality an EHR 
Module includes and the certification criteria to which it is 
certified.
    As explained below, we propose to:
    (1) Identify subsets of certification criteria as ``certification 
packages,'' beginning with the 2015 Edition; and
    (2) Require ONC-ACBs to ensure that EHR Module developers make 
accurate representations concerning certification packages on their Web 
sites and in marketing materials, communications statements, or other 
assertions related to an EHR Module's certification.
    We propose and seek public comment on the following two 
certification packages: ``care coordination'' and ``patient 
engagement.'' We also seek comment on the specific certification 
criteria we have proposed to assign to those packages. As noted above, 
we propose that package designations would only be applicable to 
certifications issued to EHR Modules (MU and non-MU) certified to the 
2015 Edition EHR certification criteria.
    We propose to define ``certification package'' in Sec.  170.502 as 
an identified set of certification criteria adopted by the Secretary in 
subpart C of part 170

[[Page 10922]]

that represent a specific grouping of capabilities. We also propose 
definitions in Sec.  170.502 for ``2015 Edition Care Coordination 
Package'' and ``2015 Edition Patient Engagement Package'' that each 
identify the set of specific certification criteria to which an EHR 
Module needs to be certified, at a minimum, in order for its EHR Module 
developer to represent that the EHR Module meets the requirements of a 
particular package.
     Care Coordination Package: This package would require an 
EHR Module to be certified to, at a minimum, the proposed 2015 Edition 
EHR certification criteria at Sec.  170.315(b)(1) (Transitions of 
care); and Sec.  170.315(b)(2) (Clinical information reconciliation and 
incorporation).
    With respect to this package, we solicit comment on: (1) Whether we 
should also include Sec.  170.315(h)(1) (Transmit--Applicability 
Statement for Secure Health Transport) in order to require that an EHR 
Module labeled with this package is also certified to the transmission 
certification criterion focused on the primary Direct Project 
specification; (2) whether it should be a more general requirement to 
be certified to any one of the Sec.  170.315(h) transmission 
certification criteria (which could risk some organizations adopting an 
EHR Module labeled with ``care coordination package'' being unable to 
exchange with each other because their separate EHR Modules came with 
different transmission capabilities); (3) whether we should require 
that the EHR Module be certified to both Sec.  170.315(h)(1) and Sec.  
170.315(h)(3) (i.e., ``Direct'' and SOAP); and (4) whether including 
any of the transmission criteria in Sec.  170.315(h) as part of the 
package would recreate the same ``binding'' effect that we proposed to 
decouple earlier in this preamble (see the discussion of the 
``Transitions of Care'' certification criterion in section III.A).
     Patient Engagement Package: This package would require an 
EHR Module to be certified to, at a minimum, the proposed 2015 Edition 
EHR certification criteria at Sec.  170.315(e)(1) (View, download and 
transmit to a 3rd party); and Sec.  170.315(e)(3) (Secure messaging).
    With respect to this package, we solicit comment on whether we 
should include Sec.  170.315(a)(16) (Patient list creation), Sec.  
170.315(a)(17) (Patient-specific education resources), or both. While 
these capabilities are more functional than exchange-oriented, they 
could complement and enhance the two certification criteria we have 
proposed to be part of the Patient Engagement Package.
    We clarify that if an EHR Module were certified to the 
certification criteria included in a certification package definition, 
then the EHR Module developer would be able to indicate this fact 
without the need for any additional determination to be made by the 
ONC-ACB. In other words, ONC-ACBs would not have to perform any 
additional analysis or make any additional determination before an EHR 
Module developer could indicate that its certified EHR Module meets a 
certification package definition. However, to ensure that certification 
packages are represented accurately to potential purchasers and users 
of EHR Modules, we propose to modify Sec.  170.523(k)(1) to require 
ONC-ACBs to ensure that an EHR Module developer accurately represents 
the certification packages its EHR Module meets if and when the EHR 
Module developer uses the certification package designation(s) on its 
Web site and in marketing materials, communications statements, or 
other assertions related to the EHR Module's certification. Although 
ONC-ACBs are already required to ensure that the certifications issued 
to EHR Modules (which would indicate the criteria to which the EHR 
Module is certified) are accurately represented by EHR Module 
developers, this proposed provision would expressly impose the 
requirement with regard to certification packages.
    We also clarify that the certification criteria included in a 
certification package would be a minimum threshold, meaning that an EHR 
Module could be certified to other certification criteria adopted by 
the Secretary in subpart C of part 170 in addition to the certification 
criteria included in the certification package at issue. Thus, in the 
event that an EHR Module presented for certification satisfies the 
certification criteria included in each of the proposed certification 
packages and is also certified to other certification criteria, it 
could be so indicated by the EHR Module developer to its customers. For 
example, it could be certified as a non-MU EHR Module with care 
coordination and patient engagement packages.
    Again, we believe this certification package approach could 
simplify communication between EHR Module developers and purchasers as 
well as make EHR Modules that meet a certification package definition 
easier to identify on the CHPL. We intend to indicate on the CHPL the 
certification packages an EHR Module satisfies based on whether the 
certification criteria to which the EHR Module is certified satisfy one 
or more certification package definitions. We believe this 
simplification may be especially valuable to health care providers that 
are ineligible to receive incentive payments under the EHR Incentive 
Programs because the EHR Module developers that serve them may only 
seek EHR Module certification to certification criteria included in a 
package.

V. Other Topics for Consideration for the 2017 Edition Certification 
Criteria Rulemaking

    In this section, we specifically request comment on issues we are 
considering addressing in the rulemaking in which we would propose to 
adopt the 2017 Edition certification criteria.

A. Additional Patient Data Collection

    We are considering whether we should require the collection and use 
of certain patient generated data in the 2017 Edition. We believe there 
are valid reasons and evidence, as discussed below, for certification 
to ensure that EHR technology is capable of recording data beyond those 
currently required for MU. However, we believe it best to present these 
data and rationale for public consideration and comment before 
including them in any proposed 2017 Edition certification criteria. For 
the data discussed below, we anticipate that they would be proposed in 
a 2017 Edition rulemaking as part of a new or existing certification 
criterion that would require EHR technology to:
     Enable a user to electronically record, change, and access 
the [data]; and
     Record a patient's response as ``declined to provide.''
    The functionality under consideration to record the data discussed 
below has no bearing on whether a patient chooses to provide this 
information or whether a health care provider chooses to record the 
information or would be required to do so through the EHR Incentive 
Programs or other programs. Further, while the certification criterion 
or criteria that we are considering for these data would not require to 
EHR technology to have the capability to electronically transmit the 
information, we welcome comments on whether we should also consider 
that capability as well.
    In considering the appropriateness of the data elements and 
standards below, please comment on whether these data elements should 
be include in:
     A 2017 Edition ``demographics'' certification criterion 
(i.e., in a criterion with the functionality to enable a user to 
electronically record, change, and access patient data on preferred

[[Page 10923]]

language, sex, race, ethnicity, and date of birth);
     New standalone certification criteria for each data 
element; and/or
     New certification criteria together (e.g., disability, 
sexual orientation and gender identity in one certification criterion 
with veterans status and occupation status in a separate certification 
criterion).
Disability Information and Accommodation Requests
    In discussions with the HHS Office for Civil Rights and HHS 
Administration for Community Living/Center for Disability and Aging 
Policy, we have considered the potential benefits to patients and 
health care providers alike if EHR technology could enable a user to 
electronically record, change, and access information about a patient's 
disability status and any accommodate requests. For example, a patient 
may have limited sight or mobility and may need patient aids to 
interact with the provider or with the provider's EHR technology (e.g., 
a patient portal or secure messaging). We believe that health care 
providers could be better prepared to engage and treat patients with 
disabilities when they seek care if they were aware of the patient's 
disability status and any accommodate requests. Accordingly, we seek 
comment on whether certification should require that EHR technology be 
capable of enabling a user to electronically record, change, and access 
disability information and/or accommodation requests.
    The following are a potential list of questions that could be asked 
related to disability information and accommodation requests. The 
questions (except for the Limited English Proficiency one) were adapted 
from questions that were approved by the Data Council and promulgated 
by the HHS Secretary under Section 4302 of the Affordable Care 
Act.\108\ The questions align with the Census Bureau's American 
Community Survey \109\ and are designed to characterize functional 
disability. The questions reflect how disability is conceptualized 
consistent with the International Classification of Functioning, 
Disability, and Health and serve as the minimum standard for collecting 
population survey data on disability status. As we mentioned in the 
2014 Edition Final Rule, unlike clinical cognitive or functional status 
assessments, this information can be used by health care providers to 
better accommodate and respond to individual patient needs.\110\
---------------------------------------------------------------------------

    \108\ http://minorityhealth.hhs.gov/templates/content.aspx?ID=9232#1.
    \109\ http://www.census.gov/people/disability/methodology/acs.html.
    \110\ 77 FR 54256.
---------------------------------------------------------------------------

    1. Are you deaf or do you have difficulty hearing? If so, what 
special assistance may you need?
    2. Are you blind or do you have difficulty seeing, even when 
wearing glasses? If so, what assistance may you need?
    3. Because of a physical, mental, or emotional condition, do you 
have serious difficulty concentrating, remembering, or making 
decisions? (patients 5 years old or older).\111\ If so, what assistance 
may you need?
---------------------------------------------------------------------------

    \111\ The specified age designations mean that the questions 
that include these designations only apply to patients older that 
the specified age. The underlying assumption is that patients 
younger than the specified age would inherently have the 
difficulties inquired about. This is consistent with the American 
Community Survey methodology.
---------------------------------------------------------------------------

    4. Do you have difficulty walking or climbing stairs? (patients 5 
years old or older) If so, what assistance may you need?
    5. Do you have difficulty dressing or bathing? (patients 5 years 
old or older). If so, what assistance may you need? \112\
---------------------------------------------------------------------------

    \112\ For the purposes of this question, dressing and bathing 
are considered functionally similar (strength, range of motion, 
transferring and supporting abilities) as the question seeks to 
generally determine the patient's functional ability and not 
attribute a ``yes'' to either ability or to be used for research 
purposes. This question will allow individuals recovering from long 
illnesses, paralysis, or post-surgery limitations to choose ``yes,'' 
and then identify issues they may need assistance with.
---------------------------------------------------------------------------

    6. Because of a physical, mental, or emotional condition, do you 
have difficulty doing errands alone such as visiting a doctor's office 
or shopping? (patients 15 years old or older). If so, what assistance 
may you need?
    7. Do you have difficulty communicating, reading, or do you have 
limited proficiency in English? If so, what assistance may you need?
    We request comment on whether:
     These questions are the right questions to ask (with yes/
no responses and a field for additional explanation);
     These questions and answers can be accurately and 
efficiently recorded in an EHR;
     There are alternative questions that could be asked 
related to disability status and additional assistance requests;
     There are other ways for capturing patients' needs in EHR 
technology and patients' needs related to interacting with EHR 
technology; and
     There are any available standards that could be used to 
capture in an EHR the listed questions (and answers) or any disability 
information and accommodation requests in a structured way. For 
example, would the following standards be appropriate for the 
associated information or suffice to code the listed questions and 
answers:
    [cir] ICF (International Classification of Functioning, Disability 
and Health) for categories of function;
    [cir] LOINC[supreg] for assessment instruments; and
    [cir] SNOMED CT[supreg] for appropriate responses.
    As we noted in the introduction to this section, while the 
certification criterion that we are considering for capturing 
disability status and accommodation requests would not require EHR 
technology to have the capability to electronically exchange the 
information, we welcome comments on the appropriateness of such 
functionality and whether the seven specified questions above or other 
recorded disability status and accommodation request information could 
be efficiently exchanged in structured data, if appropriate. We note 
that the 2014 Edition ``transition of care'' certification criteria and 
the proposed 2015 Edition ``transition of care'' certification 
criterion already include requirements for EHR technology to be capable 
of using the Consolidated CDA for exchanging patient data on cognitive 
and functional status.
Sexual Orientation and Gender Identity
    In response to the 2014 Edition NPRM, we received comments 
requesting the inclusion of sexual orientation and gender identity as 
data EHR technology should be able to record as part of the 
``demographics'' certification criterion. For the 2014 Edition EHR 
certification criterion, we declined to include these data elements as 
the data elements included in the certification criterion were limited 
to only those necessary to support the associated MU objective and 
measure. Since the 2014 Edition Final Rule was published, the IOM 
issued ``Collecting Sexual Orientation and Gender Identity Data in 
Electronic Health Records: Workshop Summary.'' \113\ This summary 
illustrates the clinical relevance for collecting information on both 
sexual orientation and gender identity. Specifically, the collection of 
this information can help to address health disparities for Lesbian, 
Gay, Bisexual and Transgender (LGBT) patients, including access to care 
and the quality

[[Page 10924]]

of care. Conversely, concerns have been raised about the need to 
balance privacy and security with data flow needs. For example, there 
are some additional protections required for data collected in 
federally funded substance abuse treatment programs regarding who has 
access to such data, but there are not similar additional protections 
for sexual orientation and gender identity data. Therefore, we seek 
comment on whether certification should require that EHR technology be 
capable of enabling a user to electronically record, change, and access 
data on a patient's sexual orientation and gender identity. To 
facilitate the standard capturing of this data, we request comment on 
whether the following code sets could be used to capture this 
information in a structured format:
---------------------------------------------------------------------------

    \113\ http://www.iom.edu/Reports/2012/Collecting-Sexual-Orientation-and-Gender-Identity-Data-in-Electronic-Health-Records.aspx.
---------------------------------------------------------------------------

     SNOMED CT[supreg] for sexual orientation.\114\
---------------------------------------------------------------------------

    \114\ Codes of: Asexual; bisexual; gay; heterosexual; lesbian; 
questioning (a person who is questioning his or her sexual 
orientation); decline to answer; and not applicable (ages 0-17).
---------------------------------------------------------------------------

     SNOMED CT[supreg] for gender identity.\115\
---------------------------------------------------------------------------

    \115\ Codes of: Gender variant; man; intersex; questioning (a 
person who is questioning his or her sexual orientation); 
transgender; woman; decline to answer; and not applicable (ages 0-
17). These codes were recommended for creation by HL7, but not have 
yet been updated within SNOMED CT[supreg].
---------------------------------------------------------------------------

U.S. Military Service
    In recent years, U.S. Military service members have been returning 
from service in Iraq and Afghanistan and other various combat duty 
stations. A portion of these service members are returning with 
traumatic brain injuries, major limb injuries, and diagnoses of post-
traumatic stress disorder as reported by the Department of Defense and 
Department of Veterans Affairs. Overall, the Veterans Health 
Administration (Department of Veterans Affairs) provides medical care 
to over 8.76 million veterans each year.\116\ Because the Department of 
Veterans Affairs has eligibility requirements to be considered eligible 
for veterans' benefits and that process takes into consideration a 
variety of factors, we do not seek comment on EHR technology's ability 
to record ``veteran status.'' However, we do seek comment on whether 
EHR technology should be capable of recording whether a patient has 
served in the U.S. Military. We believe recording U.S. Military service 
information can have many benefits. It can help in identifying 
epidemiological risks for patients such as those noted above. It can 
assist in ensuring that a patient receives all the health care benefits 
he or she is entitled to by alerting medical professionals to the 
patient's U.S. Military service history, which can facilitate the 
coordination of benefits. This information can also increase the 
ability to assemble a longitudinal record of care for a U.S. service 
member, such as by requesting or merging of a patient's electronic 
health record stored by the Department of Defense, Veteran's Health 
Administration, and/or another health care provider. Accordingly, we 
seek comment on whether certification should require that EHR 
technology be capable of enabling a user to electronically record, 
change, and access U.S. Military service information. We also seek 
comment on whether the ``U.S. Military service'' data element should be 
expanded to encompass all uniformed service members, including 
commissioned officers of the U.S. Public Health Service and the 
National Oceanographic and Atmospheric Administration as they too are 
eligible for veterans benefits and related services.
---------------------------------------------------------------------------

    \116\ http://www.va.gov/health/.
---------------------------------------------------------------------------

    In terms of electronically capturing U.S. Military service, we 
request comment on the following:
     Use of the following concepts for coding U.S. Military 
service in EHR technology: History of Employment in U.S. Military; No 
History of Employment in U.S. Military; and Currently Employed by U.S. 
Military.
     Whether it would be appropriate to capture the actual 
start date and date of separation from service.
     Whether EHR technology should be able to record the 
foreign locales in which the service member had recently served.
     Whether there are better concepts/values that could 
capture information related to U.S. Military status or uniformed 
service status, including through capturing occupational status and use 
of occupational code sets.
    As we noted in the introduction to this section, while the 
certification criterion that we are considering for capturing U.S. 
Military service would not require EHR technology to have the 
capability to electronically exchange the information, we welcome 
comments on the appropriateness of such functionality. We understand 
that the Consolidated CDA Social History Observation section could 
accommodate military or uniformed service status pending the assignment 
of specific codes (e.g., SNOMED CT), which would enable it to be 
exchanged as part of a summary care record. Therefore, we seek comment 
on the feasibility of capturing military or uniformed service status in 
the Consolidated CDA and whether the 2017 Edition should require EHR 
technology to be capable of exchanging this data (e.g., in the 2017 
Edition ``transition of care'' certification criterion).
Work Information--Industry/Occupation
    The Institute of Medicine has identified patients' work information 
as valuable data that could be recorded by EHR technology and used by 
both health care providers and public health agencies.\117\ Similarly, 
the 2012 HHS Environmental Justice Strategy and Implementation Plan 
echoed the potential benefits of having work information in EHR 
technology.\118\ The combination of current industry and occupation (I/
O) information provides opportunities for health care providers to 
improve patient health outcomes--both for health issues wholly or 
partially caused by work and for health conditions whose management is 
affected by work. For example, ``Usual'' (longest-held) I/O information 
can be key for health care improvement and population-based health 
investigations, and is already a required data element for cancer 
reporting.\119\ Health care providers can use also I/O information to 
assess symptoms in the context of work activities and environments, 
inform patients of risks, obtain information to assist in return-to-
work determinations, and evaluate the health and informational needs of 
groups of patients.
---------------------------------------------------------------------------

    \117\ IOM (Institute of Medicine). 2011. ``Incorporating 
Occupational Information in Electronic Health Records: A Letter 
Report''. Available at: http://www.nap.edu/catalog.php?record_id=13207.
    \118\ U.S. Department of Health and Human Services. February, 
2012. 2012 HHS Environmental Justice Strategy and Implementation 
Plan. Available at: http://www.hhs.gov/environmentaljustice/strategy.html.
    \119\ CDC (2) (Centers for Disease Control and Prevention). 
2012. Implementation Guide for Ambulatory Healthcare Provider 
Reporting to Central Cancer Registries, HL7 Clinical Document 
Architecture (CDA) Release 1.0, August 2012. Available at: http://www.cdc.gov/phin/library/guides/Implementation_Guide_for_Ambulatory_Healthcare_Provider_Reporting_to_Central_Cancer_Registries_August_2012.pdf.
---------------------------------------------------------------------------

    The National Institute for Occupational Safety and Health (NIOSH) 
and other stakeholders are working to develop and support standards and 
tools for the collection, storage, and exchange of I/O information. It 
has developed a relational information model of work information 
(including I/O) for EHR technology and is in the process of translating 
it into the HL7 reference information model format. NIOSH is also 
working with HL7 to reflect functionality for work information in

[[Page 10925]]

EHR technology and is collaborating with other stakeholders to ensure 
that I/O information is incorporated into interoperability standards, 
such as standards to support case reporting to public health. A 
reusable CDA template of Occupational Data for Health (ODH) is part of 
the social history section within the published Healthy Weight (HW) 
trial implementation profile,\120\ which has been tested at the 2014 
Integrating the Healthcare Enterprise Connectathon.\121\ In addition, 
prototype occupation-related CDS knowledge bases for primary care 
providers are in development.
---------------------------------------------------------------------------

    \120\ http://www.ihe.net/uploadedFiles/Documents/QRPH/IHE_QRPH_Suppl_HW.pdf.
    \121\ http://www.ihe.net/Connectathon/.
---------------------------------------------------------------------------

    Widely used code sets are available for converting narrative I/O 
text into structured data. The combination of Bureau of Census (BOC) I/
O codes \122\ and NIOSH-added codes (e.g., for unpaid workers)--
identified as the CDC--Census system in the Public Health Information 
Network Vocabulary Assignment and Distribution System (PHIN VADS) 
\123\--can be used to code patient I/O in EHR technology. The CDC--
Census code sets are already used to classify the I/O information 
provided by respondents in most major U.S. health surveys. Given all of 
the effort by NIOSH and other stakeholders to advance this important 
work, we request comments on whether we should propose as part of the 
2017 Edition that EHR technology be capable of enabling a user to 
electronically record, change, and access the following data elements 
for certification:
---------------------------------------------------------------------------

    \122\ Census (1) (United States Census Bureau). 2012. Industry 
and Occupation. Available at: http://www.census.gov/people/io/methodology/indexes.html.
    \123\ PHIN Vocabulary Access and Distribution System. 2012. 
Available at: http://www.cdc.gov/phin/tools/PHINvads/.
---------------------------------------------------------------------------

     Narrative text for both current and usual industry and 
occupation (I/O), with industry and occupation for each position linked 
and retained in perpetuity and time stamped.
     CDC--Census codes for both current and usual I/O, with 
industry and occupation for each position linked and retained in 
perpetuity and time stamped.
    We solicit public comment on the experience EHR technology 
developers, EPs, EHs, and CAHs have had in capturing, coding, and using 
I/O data. Further, as cited under the U.S. Military service discussion 
above, I/O codes may be appropriate for coding U.S. Military service or 
uniformed service, as both data elements capture information on 
positions held/work performed and exposures. The Department of Veterans 
Affairs and HHS are currently assessing how best to appropriately and 
efficiently capture I/O information and military service information 
about patients in EHR technology. We welcome comments and suggestions 
on any potential options we should consider for our assessment.

B. Medication Allergy Coding

    General allergy types can be coded using the RxNorm vocabulary that 
we have adopted in our rules. However, for coding medication allergies, 
RxNorm is not specific enough to distinguish allergies to particular 
ingredients in drugs nor is it specific enough for coding food-drug 
allergies. Allergic reaction symptoms and DDI reactions can be coded 
using the SNOMED CT vocabulary also adopted in our rules, but there is 
no specific reaction value set and using general problem value sets do 
not allow for identification of the allergy's cause. No formal reaction 
list has been defined in the C-CDA or through the work done by the 
Health Information Technology Standards Panel.\124\ In the HITPC's 
meaningful use Stage 3 Request for Comment, stakeholders commented that 
other vocabulary and value sets could be leveraged to address these 
gaps. These include:
---------------------------------------------------------------------------

    \124\ http://www.hitsp.org/.
---------------------------------------------------------------------------

     The FDA Unique Ingredient Identifier (UNII) system which 
can be used to identify unique ingredients in drugs, biologics, food, 
and devices;
     The VA National Drug File--Reference Terminology (NDF-RT) 
vocabulary which has been mapped to RxNorm and may be a good standard 
for describing allergies to classes of drugs such as penicillin.
    Additionally, CDC has developed a value set for Vaccine Reaction 
and Adverse Events \125\ that is available but not currently assigned 
to drug and general allergic reactions.
---------------------------------------------------------------------------

    \125\ http://phinvads.cdc.gov/vads/ViewValueSet.action?id=635A4FEA-8232-E211-8ECF-001A4BE7FA90.
---------------------------------------------------------------------------

    The HITPC has indicated \126\ that EHR systems should provide 
functionality to code medication allergies, including the related drug 
family for reactions. Currently, we require that CEHRT base CDS 
interventions on certain data (including medication allergies) but this 
list does not specifically include DDI reactions. Given these issues, 
we solicit comment on:
---------------------------------------------------------------------------

    \126\ http://www.healthit.gov/sites/default/files/hitpc_stage3_rfc_final.pdf.
---------------------------------------------------------------------------

    (1) The adoption of additional vocabularies to code medication 
allergies to drug ingredients, allergic reaction symptoms, and DDI 
reactions (e.g., UNII, NDF-RT);
    (2) Whether we should adopt the CDC Vaccine Reaction and Adverse 
Event value set;
    (3) The value of using specific reaction value sets versus general 
problem value sets;
    (4) Whether CDS interventions should be based on DDI reactions.

C. Certification Policy for EHR Modules and Privacy and Security 
Certification Criteria

    In our past rulemakings we have discussed and instituted two 
different policy approaches for ensuring that EHR Modules meet privacy 
and security (P&S) certification criteria while minimizing the level of 
regulatory burden imposed on EHR technology developers. In the 2011 
Edition, we required that EHR Modules must meet all P&S certification 
criteria unless the presenter could demonstrate that certain P&S 
capabilities were either technically infeasible or inapplicable. In the 
2014 Edition, we eliminated the requirement for each EHR Module to be 
certified against the P&S criteria. Rather, the P&S criteria were made 
part of the ``Base EHR definition'' that all EPs, EHs, and CAHs must 
have EHR technology certified to meet, in order to ultimately have EHR 
technology that satisfied the CEHRT definition. While some commenters 
expressed concern with our 2014 Edition proposal to remove the P&S 
certification requirement for EHR Modules, we finalized the policy in 
favor of the outcome-oriented requirement we believed the Base EHR 
definition promoted, and in an effort to enable EHR technology 
developers to better choose which P&S criteria were most applicable to 
their products. As of December 31, 2013, approximately 70% of 2014 
Edition EHR Modules have been certified to at least one P&S criterion 
(out of nine available P&S criteria) and about 51% have been certified 
to four or more. Despite prior stakeholder concerns, this data suggests 
that our 2014 Edition Final Rule policy has not resulted in a 
significant reduction in the number of EHR Modules certified to P&S 
criteria and that a majority of EHR technology developers appear to be 
pursuing certification to these criteria regardless of our more 
flexible, less burdensome policy for 2014 Edition certification.
    On March 23, 2013, the HITSC recommended that we should change our 
EHR Module certification policy for P&S. They recommended that each EHR 
Module presented for certification should be certified through one or 
more of the following three paths:

[[Page 10926]]

     Demonstrate, through system documentation and 
certification testing, that the EHR Module includes functionality that 
meets at least the ``minimal set'' \127\ of privacy and security 
certification criterion.
---------------------------------------------------------------------------

    \127\ The minimal set includes Authentication, access control, 
and authorization, Auditable events and tamper resistance, Audit 
report(s), Amendments, Automatic log-off, Emergency access, End-user 
device encryption, and Integrity. The full recommendation can be 
found at: http://www.healthit.gov/sites/default/files/pswgtransmittalmemo_032613.pdf.
---------------------------------------------------------------------------

     Demonstrate, through system documentation sufficiently 
detailed to enable integration, that the EHR Module has implemented 
service interfaces that enable it to access external services necessary 
to conform to the ``minimal set'' of privacy and security certification 
criterion.
     Demonstrate through documentation that the privacy and 
security certification criterion (and the minimal set that the HITSC 
defined) is inapplicable or would be technically infeasible for the EHR 
Module to meet. In support of this path, the HITSC recommended that ONC 
develop guidance on the documentation required to justify 
inapplicability or infeasibility.
    As a result of the HITSC recommendations and stakeholder feedback, 
we seek comment on the following four options we believe could be 
applied to EHR Module certification for privacy and security:
     Option 1: Re-Adopt the 2011 Edition approach.
     Option 2: Maintain the 2014 Edition approach.
     Option 3: Adopt the HITSC recommendation. This approach 
reintroduces some of the challenges we sought to avoid with our current 
policy and introduces potentially new administrative burdens for EHR 
technology developers.
     Option 4: Adopt a limited applicability approach--under 
this approach, ONC would establish a limited set of P&S functionality 
that every EHR Module would be required to address in order to be 
certified. For example, we could require that all EHR Modules need to 
address the authentication, access control, and authorization 
certification criterion. This approach has the same downsides as 
options 1 and 3 but to a lesser extent given that its broad 
applicability could still result in EPs, EHs, and CAHs adopting EHR 
Modules that had been certified with duplicative capabilities.
    We seek feedback on all of these policy options. Further we 
especially solicit feedback: (1) from EHR technology developers and 
ONC-ACBs regarding the efficiency of the current certification policy; 
(2) from stakeholders that prefer ``option 3'' (the HITSC's 
recommendation) and why; and (3) from stakeholders that prefer ``option 
4'' what the minimum P&S criteria could be.

D. Provider Directories

    We have received feedback from many different stakeholder groups 
that a single standard for ``provider directories'' is needed. The 
impetus for this feedback appears to be MU Stage 2's added exchange 
requirements and a general industry need to find providers electronic 
service information. In June 2011, The HITPC recommended \128\ that we 
consider the adoption of provider directory capabilities in our 
certification program as well as work to address many of the issues 
they raised. To address the HITPC's recommendations, ONC launched a 
number of initiatives to define a single provider directory standard 
and to pilot its use. In August 2013, the HITPC recommended including a 
provider directory standard in MU Stage 3.\129\
---------------------------------------------------------------------------

    \128\ http://www.healthit.gov/sites/default/files/pdf/HITPC_transmit_InfoExchWG_May2011-finalsigned.pdf.
    \129\ http://www.healthit.gov/FACAS/sites/faca/files/IE%20WG_Recommendation%20Transmittal_MU3v2.docx.
---------------------------------------------------------------------------

    After multiple discussions and guidance with subject matter experts 
in the field, we found that the main gap that stakeholders would like 
ONC to address through EHR certification is the ability to be able to 
query individual directory sources and directory sources federated by 
third parties such as HIOs, RHIOs, HISPs etc. This is also known as 
``federated querying.'' However, we also discovered that there were 
only a few implementations of federated querying across the country and 
many were unique due to the lack of a single standard. Given this 
challenge, and its potential to inhibit exchange, ONC launched an open 
source project called ``Modular Specification Provider Directories 
(MSPD).'' \130\
---------------------------------------------------------------------------

    \130\ http://modularspecs.siframework.org/Provider+Directories+Homepage.
---------------------------------------------------------------------------

    During this project stakeholders collaborated to identify 
requirements for the next version of ``Healthcare Provider Directory 
(HPD)'' in order to provide a unified vendor-neutral platform for 
implementation of provider directories that supports both federated and 
non-federated architectures. The project resulted in implementable, 
testable specifications, and high quality test cases that verify 
conformance to the ``test implementation'' which is created based on 
the MSPD IG. In addition, ONC awarded a grant to the EHR [bond] HIE 
Interoperability Workgroup \131\ to pilot provider directory standards 
with multiple states.
---------------------------------------------------------------------------

    \131\ http://www.interopwg.org/
---------------------------------------------------------------------------

    It is our understanding that the current HPD standard created by 
Integrating the Healthcare Enterprise (IHE) \132\ only addresses 
transactions between the client and a single provider directory with a 
single data source. While the standard can be used for federation, it 
does not address the complexities introduced by federation; provide a 
well-defined and straightforward approach to error handling, support 
targeted queries to federated data sources, or define mechanisms by 
which to distinguish the source of results in a given response. ONC is 
currently working with IHE and other stakeholders to solve these issues 
with an updated HPD standard.
---------------------------------------------------------------------------

    \132\ http://wiki.ihe.net/index.php?title=Healthcare_Provider_Directory.
---------------------------------------------------------------------------

    In collaboration with IHE we believe that a new HPD standard will 
be ready in early 2014 that will support federated querying of provider 
directories. As a result, we believe that the updated HPD standard will 
be ready to propose for adoption as part of the 2017 Edition rulemaking 
and included in a certification criterion focused on capabilities to 
query provider directories. Accordingly, we seek public comment on the 
following potential capabilities we are considering for such a 
certification criterion:
    At a minimum, EHR technology would need to be able to query 
provider directories for the following information and electronically 
process the response returned in accordance with the MSPD IG 
requirements (which are expected to be adopted by IHE USA as an IHE USA 
profile):
     Query for an individual provider;
     Query for an organizational provider;
     Query for relationships between individual providers and 
organizational providers.

E. Oral Liquid Medication Dosing

    Our strategic goal is to provide more granular descriptions of 
prescriptions to allow for CDS, identify patient safety issues (such as 
excessive acetaminophen in combination medications), and reduce dosing 
confusion. For example, the U.S. currently uses the English measurement 
system standard (e.g., teaspoons) rather than the metric standard 
(e.g., milliliters (mL)) for prescribing liquid oral medications. The 
medication dose is

[[Page 10927]]

determined in part by the patient's weight. The metric standard (mL) 
offers more precision in medication dose, which can decrease 
preventable adverse drug events. Dosing errors are the most common 
medication error in pediatrics.\133\ The American Academy of Pediatrics 
(AAP) supports the use of the metric standard (mL) for e-
prescribing.\134\ AAP supports modification of both dosing guidelines 
and dose-screening parameters to support dosing for every indication 
that warrants modified dosing regimens.\135\ The Food and Drug 
Administration has provided a draft guidance that supports metric units 
for labeling prescription medications.\136\ And, the National Council 
for Prescription Drug Programs supports mL dosing in retail 
dispensing.\137\
---------------------------------------------------------------------------

    \133\ Wong IC, Ghaleb MA, Franklin BD, Barber N. Incidence and 
nature of dosing errors in pediatric medications: A systematic 
review. Drug Saf. 2004;27(9):661-670.
    \134\ AAP Council on Clinical Information Technology Executive 
Committee, 2011-2012. Policy Statement--Electronic Prescribing in 
Pediatrics: Toward Safer and More Effective Medication Management. 
Pediatrics 2013; 131;824.
    \135\ Johnson KB, Lehmann CU, and the AAP Council on Clinical 
Information Technology. Technical Report--Electronic Prescribing in 
Pediatrics: Toward Safer and More Effective Medication Management. 
Pediatrics 2013;131;e1350.
    \136\ FDA Draft Guidance for Industry on Safety Considerations 
for Container Labels and Carton Labeling Design To Minimize 
Medication Errors. April 24, 2013. https://www.federalregister.gov/articles/2013/04/24/2013-09640/draft-guidance-for-industry-on-safety-considerations-for-container-labels-and-carton-labeling-design.
    \137\ https://www.ncpdp.org/Educational-Summit-Session.aspx?ID=6.
---------------------------------------------------------------------------

    We understand that e-prescribing functionality can present standard 
dosing formula to use the patient's weight to: Calculate a dose; 
convert the dose to a volume for liquids; and present the dose in a 
format that is least likely to be confusing to a prescriber, 
pharmacist, nurse, or patient. Sophisticated e-prescribing 
functionality has been said to use individual dose limits, compared to 
weight- or body surface area-based normal values.
    Given the clinical need and stakeholder support for reducing 
preventable adverse events resulting from dosing errors in e-
prescribing, we solicit comment on whether we should adopt a 
certification criterion (or establish a requirement within a 
certification criterion) for EHR technology to use the metric standard 
for prescribing oral liquid medications or to solve the problem more 
generally using a structured Sig \138\ standard. Potential (non-
mutually exclusive) options for certification include, but are not 
limited to:
---------------------------------------------------------------------------

    \138\ A prescription contains a number of different elements. In 
addition to the patient and prescriber information, it must state 
the name, dosage form and strength of the medication; the dose; the 
amount to be dispensed; the number of refills; and the directions 
for use, or Sig. ``Sig'' is an abbreviation for ``signatura,'' Latin 
for ``Mark thou''. The Sig contains the instructions explaining how 
the patient is to take the medication. http://www.ncpdp.org/pdf/Sig_standard_imp_guide_2006-06.pdf.
---------------------------------------------------------------------------

     Require EHR technology to use a structure Sig with 
explicit dosing units, frequency, and number of units;
     Require EHR technology to provide the metric standard as 
one option to record liquid medication doses;
     Require EHR technology to record liquid medication doses 
in the metric standard only; and
     Require EHR technology to be able to accurately convert a 
liquid dose to the metric standard. For this last option, we are also 
soliciting comment on minimum/maximum dosing checks for dose 
conversion.
    We also solicit comment on EHR readiness to implement the metric 
standard for prescribing oral liquid medications, the effect on 
existing vocabulary standards for units of measurement (e.g., UCUM), 
and implications on the structured Sig format for e-prescribing.

F. Medication History

    Knowing a patient's medication history can assist providers in 
making decisions about a patient's health, reduce the amount of time 
spent on administrative tasks around medication prescribing and 
reconciliation, improve patient safety, and quality of care in all 
health care settings. We are aware of current technology that provides 
medication history information through e-prescribing and EHR systems 
from community pharmacies and patient medication claims history. 
Current medication history services provide information such as patient 
compliance with prescribed medications, therapeutic interventions, 
drug-drug and drug-allergy interactions, adverse drug reactions, 
duplicative therapy, the numbers of pharmacies and physicians, and 
frequency of prescription refills. In a few cases, medication history 
services are provided through state and regional health information 
exchanges.
    In the 2014 Edition, we adopted the NCPDP SCRIPT 10.6 standard for 
e-prescribing (170.314(b)(3)). SCRIPT 10.6 supports a medication 
history source feature that provides where the history was obtained and 
the identity of the source, as well as consolidates histories from 
different sources.
    We solicit comments on whether we should propose a 2017 Edition 
certification criterion focused on medication history capabilities. We 
encourage commenters to address the specific information/specific 
capabilities that should be provided, standards recommended to support 
this capability, and which existing certification criterion/criteria 
could include this capability (e.g., medication reconciliation, 
medication list, e-prescribing) if it were not a stand-alone 
certification criterion.

G. Blue Button +

    We are interested in feedback on the adoption of separate 
certification criteria for Blue Button + (BB+) capabilities as part of 
our 2017 Edition rulemaking. Blue Button+ is the ability to get patient 
records in a human-readable and machine-readable format, and allows the 
patient send them where they choose. This enables a consumer to do 
everything from printing a physical copy to sharing it with a third 
party application. Since the publication of the 2014 Edition Final Rule 
both members of the public and the HITSC have expressed interest in 
promoting Blue Button +. Specifically, stakeholders have indicated an 
interest in using the BB+ Direct Specifications, currently in pilot 
phase of the S&I Framework's BB+ Representational State Transfer (REST) 
workgroup,\139\ and the BB+ RESTful API. The BB+ Direct Specifications 
add two functions beyond the MU Stage 2 requirements: the ability to 
use triggers to automate a ``Direct message'' to the patient after each 
encounter or when new clinical information is added to the record; and 
the ability to load certificate bundles, including the Blue Button 
certificate bundle. The BB+ REST specifications do not change content 
specifications, but include substantial changes to authentication and 
authorization using OAuth and OpenID, and Transport using FHIR instead 
of the Direct Protocol. Given stakeholder interest in the BB+ 
initiative's work and the significant benefits it could have for 
patients, we solicit comments on the following:
---------------------------------------------------------------------------

    \139\ More information on the S&I Framework's BB+ REST workgroup 
can be found at http://wiki.siframework.org/BlueButton+Plus+Pilots.
---------------------------------------------------------------------------

    (1) Is there a market need for BB+ certification? In other words, 
would health IT developers find value in a BB+ certification that would 
enable them to say they are ``BB+ compliant'' or ``BB+ ready'';
    (2) Which elements of BB+ Direct Specifications would be most 
important

[[Page 10928]]

to reference in a certification criterion and how would they be tested; 
and
    (3) What elements of BB+ REST Specifications would be most 
important to reference in a certification criterion and how would they 
be tested? Additionally, what use cases would be uniquely supported by 
BB + REST Specifications?

H. 2D Barcoding

    Using barcode symbols on items with specific details, including 
specifications of the dispensed unit, has the potential to reduce 
medication and transcription errors.\140\ In 2004, the FDA issued the 
``Bar Code Label Requirements for Human Drug Products and Biological 
Products Final Rule'' \141\ for the barcoding of pharmaceutical and 
biological products. The regulation required the National Drug Code 
(NDC) to be barcoded on certain pharmaceutical and biological items 
used in health care facilities using a linear barcode.
---------------------------------------------------------------------------

    \140\ http://www2.aap.org/immunization/pediatricians/pdf/barcoding_guidance_manufacturers_022212.pdf.
    \141\ http://www.fda.gov/ohrms/dockets/98fr/04-4249.htm.
---------------------------------------------------------------------------

    Implementation of two-dimensional (2D) barcodes on drug products 
and biologics such as vaccines can allow for rapid, accurate, and 
automatic capture of data by a handheld imaging device or scanner to 
populate fields in an EHR or specialty registry. 2D barcodes can 
contain more information than linear barcodes in a smaller space.\142\ 
We are aware that 2D barcodes using the GS1 DataMatrix Barcodes 
standard are being introduced for unique device identifiers and 
vaccines.
---------------------------------------------------------------------------

    \142\ http://www.cdc.gov/vaccines/programs/iis/2d-vaccine-barcodes/about.html.
---------------------------------------------------------------------------

    For example, 2D barcode technology has been pilot tested to show 
that barcoding on vaccines can capture vaccine data elements completely 
and accurately.\143\ The National Childhood Vaccine Injury Act \144\ 
(NCVIA) requires documentation of vaccine product identification and 
vaccine lot number. These data are usually handwritten or manually 
typed into an EHR/IIS and can be missing or incorrect. A workgroup from 
the American Academy of Pediatrics (AAP) approached the FDA in 2010 to 
request that the regulation requiring linear barcodes be amended to 
allow for the use of 2D barcodes on vaccines.
---------------------------------------------------------------------------

    \143\ http://www.cdc.gov/vaccines/programs/iis/2d-vaccine-barcodes/about.html.
    \144\ Public Law 99-660.
---------------------------------------------------------------------------

    Since 2011, the CDC has been exploring the potential for 2D 
barcoding to streamline immunization practices. Two vaccine 
manufacturers, ten CDC ``Section 317'' Immunization grantees, and 
approximately 220 immunizers among the ten grantees participated in a 
pilot implementation of 2D barcoded vaccines. Providers administered 
vaccines with 2D barcodes containing product identifier, lot number, 
and expiration date. The providers were given barcode scanners that 
read the 2D barcode and input the data directly into the EHR for each 
patient. The data were then sent to the IIS. Additionally, we are aware 
that a working group led by the AAP has developed a ``Guideline for 
Practitioners'' document to help practices use 2D barcoding with their 
EHR or IIS and guidance for manufacturers on implementing GS1 
DataMatrix Barcodes standard on vaccines.\145\
---------------------------------------------------------------------------

    \145\ AAP materials are available at http://www2.aap.org/immunization/pediatricians/barcoding.html.
---------------------------------------------------------------------------

    Given the progress made to-date demonstrating the feasibility of 
implementing 2D barcode technology in practice, we solicit comment on 
whether we should propose a 2017 Edition certification criterion 
requiring EHR systems to consume 2D barcodes and for what functions 
(e.g., vaccine administration, medication administration). We also 
solicit comment on any other data that EHR technology could be required 
to capture using 2D barcoding information.

I. Duplicate Patient Records

    In September 2013, in response to the 2011 HITPC and HITSC 
recommendations and stakeholder feedback, ONC formally undertook an 
initiative to improve patient matching.\146\ Due to our experience with 
this initiative, we are considering a 2017 Edition certification 
criterion that would require EHR technology to be capable of generating 
and providing to end users reports that detail potential duplicate 
patient records as a potential means to improve patient matching data 
quality. We anticipate that this certification criterion could also 
include functionality for end users to correct duplicate records, which 
typically requires the merging of records and unmerging incorrectly 
merged records.
---------------------------------------------------------------------------

    \146\ http://www.healthit.gov/buzz-blog/health-innovation/onc-launches-patient-matching-initiative/.
---------------------------------------------------------------------------

    We believe a certification criterion including these capabilities, 
in addition to the patient matching capabilities proposed for inclusion 
in the 2015 Edition ``transitions of care'' certification criterion, 
would significantly improve a provider's ability to properly match 
patients to their health information. While many EHR systems today with 
built-in matching functionality and processes offer reports that 
identify potential duplicate records, not all EHR systems offer such a 
capability. Additionally, some EHR systems have the capability, but do 
not make the reports accessible to users. As for merging and unmerging, 
we understand these capabilities vary and are inconsistently applied in 
EHR technology today. While some EHR technology may enable users to 
merge and unmerge back to a specific point in time, others do not 
unmerge and instead delete the entire record and create two new ones.
    We seek comment on provider demand for/interest in these types of 
capabilities in addition to any capabilities that should be included or 
excluded from this potential certification criterion.

J. Disaster Preparedness

    Over the past decade, the U.S. has been challenged by several 
natural and man-made disasters (e.g., terrorist attacks, Hurricanes 
Katrina and Sandy, Joplin tornado) which have placed considerable 
strain on local health care systems and put health system readiness for 
public health emergencies on the national agenda. One of the basic 
tenets of preparedness is, to the greatest extent possible, to 
incorporate into everyday operations those systems, processes, 
equipment, and strategies that might be employed during a 
disaster.\147\ Maintaining health IT infrastructure has tangible day to 
day benefits and during a disaster or other large scale event may 
reduce overall stress on the health care system which helps makes our 
health care systems more resilient. In fact, the National Health 
Security Strategy (NHSS) identifies ``the use of portable, standards-
based, interoperable EHRs'' as an essential element of a ``prepared and 
responsive health system.'' \148\
---------------------------------------------------------------------------

    \147\ Abir M, Mostashari F, Atwal P, et al. Electronic health 
records critical in the aftermath of disasters. Prehosp Disaster 
Med. 2012;6:620-622.
    \148\ U.S. Department of Health and Human Services. National 
health security strategy of the United States of America. 
Washington, DC: U.S. Department of Health and Human Services; 
December 2009: http://www.phe.gov/Preparedness/planning/authority/nhss/strategy/Documents/nhss-final.pdf Accessed August 9, 2013.
---------------------------------------------------------------------------

    For example, EHRs improved health care during a crisis on May 22, 
2011 when a tornado struck Joplin, Missouri. As part of the 
devastation, St. John's Regional Medical Center was heavily damaged and 
had to be evacuated. All paper and film records were destroyed, but 
medical personnel had full access to their patients' electronic 
records. The EHR system significantly aided St.

[[Page 10929]]

John's in tracking patient medical histories and delivering care based 
on the full patient records even from their temporary facility.\149\
---------------------------------------------------------------------------

    \149\ http://www.healthit.gov/buzz-blog/ehr-case-studies/electronic-health-records-prove-invaluable-crisis/.
---------------------------------------------------------------------------

    To more fully consider how EHR technology can be used to enhance 
emergency preparedness and assist in response when emergencies do 
occur, we seek comment (in collaboration with our colleagues in the 
Office of the Assistant Secretary for Preparedness and Response (ASPR)) 
on a number of different concepts that we believe could be expressed as 
certification criteria in the future.
    In November 2012, ONC convened the Southeast Regional HIT-HIE 
Collaboration (SERCH) project on Health Information Exchange in 
Disaster Preparedness and Response.) \150\ The consortium included 
representatives from Alabama, Arkansas, Florida, Georgia, Louisiana, 
and Texas. The consortium's goal was to develop a strategic plan for 
sharing health information data among the Southeast and Gulf states 
during and following a declared natural disaster. The consortium 
members carefully assessed the challenges of accessing medical records 
and coordinating health care information for patient populations 
displaced due to a disaster. The SERCH team recognized the importance 
of using existing EHR and HIE standards and concluded that ``current 
and future work [regarding electronic health information exchange 
during disasters] should leverage the standards being developed'' and 
that ``rather than focus on specifying a minimum data set, allow data 
set sources to contribute as much of the data within the proposed data 
set as they are able.''
---------------------------------------------------------------------------

    \150\ http://www.healthit.gov/sites/default/files/pdf/SERCH-White-Paper.pdf.
---------------------------------------------------------------------------

    One of the key issues encountered during disasters (and day-to-day 
emergency care) is how to bypass the naming of patients who are 
temporarily unidentified. While this is rarely an issue in other care 
settings, disasters and emergencies create situations in which care 
must begin before the identity of the patient can be verified. It is 
our understanding that most EHR technologies used in emergency care 
settings have a name bypass function or facilities have developed 
protocols to be employed in these cases. Unfortunately, stakeholder 
feedback from the field has indicated that there is little consistency 
with respect to the patient naming approach used in EHR technology 
during emergencies/disasters or how rapidly a set of patient records 
can be generated in a mass casualty situation. This makes 
reconciliation across various platforms or throughout the episode of 
care challenging. As a result, information is lost, care is 
disconnected, patient safety is threatened, and tests and procedures 
are often duplicated.
    During facility evacuation it is often necessary to rapidly produce 
hard copies of patient records for groups of patients (for example all 
patients in the ``SICU'' or ``on floor 5 west''). This step is needed 
to ensure the continuity of care for patients en route and at the 
receiving facility, which may not have access to the patient's complete 
electronic record. It is our understanding that many EHR technologies 
today only permit clinical summaries for patients to be printed one at 
a time, which is too time consuming in situations where seconds count.
    The nature of emergency and disaster care is that transitions of 
care and referrals happen at far greater speed and frequency than in 
other primary or ambulatory settings. The unique needs of tracking a 
patient through the episode of care, which may involve numerous, 
unaffiliated care providers (for example, shelters and triage stations, 
emergency medical services, initial emergency department, air medical 
transfer, tertiary center emergency department, specialty care, etc.) 
presents unique challenges. To improve the continuity of care during 
these rapid transitions, stakeholders have suggested that it would be 
helpful if a standardize set of core information can be rapidly 
transferred electronically across different EHR technologies. Numerous 
third-party patient tracking methods and software packages have emerged 
as add-ons to EHR technologies to help, but very few are part of the 
EHR technology and often create parallel tracking systems.
    Disasters present a unique situation in which the demand for health 
resources (personnel, equipment, supplies, space, etc.) may temporarily 
exceed the supply. This situation requires a legal and ethical 
framework to fairly and equitably allocate these scarce resources to 
achieve the greatest possible population based outcomes. The IOM has 
published Crisis Standards of Care: A Systems Framework for 
Catastrophic Disaster Response,\151\ in which the standards of care are 
altered based on the availability of health care resources. As such, it 
seems as if it would be particularly helpful if EHR technology were 
able to denote care provided during contingency and crisis conditions.
---------------------------------------------------------------------------

    \151\ IOM. 2012. Crisis Standards of Care: A Systems Framework 
for Catastrophic Disaster Response. Washington, DC: The National 
Academies Press.
---------------------------------------------------------------------------

    Improved public health surveillance has long been a promise of 
ubiquitous EHR technology. While great strides have been made, little 
attention has been focused on the potential of electronic heath data to 
evaluate resilience, preparedness, strain on the health care system, or 
recovery.
    Given these issues, we solicit comments on:
    (1) Whether there could be a standardized naming convention for EHR 
technology to use for temporarily naming unidentified patients during 
disaster and emergency events?
    (2) Whether we should consider adopting a certification criterion 
that would be available for certification for EHR technology developers 
to show that their EHR technology can batch print face sheets or 
patient snapshots in bulk (by floor or unit, or by facility) to support 
movement/evacuation of large numbers of patients?
    (3) Whether there are particular capabilities or standards we 
should consider as part of EHR certification that would better assist 
providers track and identify patients and victims and share basic 
clinical information quickly across the full continuum of care during 
everyday emergencies, disasters, and public health emergencies?
    (4) Whether EHR technology should be able to denote care provided 
during disasters or public health emergencies and allow for designation 
of care provided under situations which demand contingency or crisis 
standards of care?
    (5) Whether there are any EHR capabilities and certification 
criteria that we should consider for certification that could improve/
expedite how EHR technology is used to report standardized and de-
identified patient data to public health and emergency management 
authorities, in a manner that would allow such authorities the ability 
to measure, track and trend health system resiliency, stress, 
preparedness, and recovery?

K. Certification of Other Types of HIT and for Specific Types of Health 
Care Settings

    Section 3001(c)(5) of the PHSA provides the National Coordinator 
with the authority to establish a voluntary certification program or 
programs for other types of HIT besides Complete EHRs and EHR Modules. 
As we noted in the Permanent Certification Program final rule (76 FR 
1294), the initial focus of the ONC HIT Certification Program

[[Page 10930]]

should be on the certification of Complete EHRs and EHR Modules in 
support of the EHR Incentive Programs. In the 2014 Edition NPRM, we 
sought public comment on whether we should focus any certification 
efforts towards the HIT used by health care providers that are 
ineligible to receive incentive payments under the EHR Incentive 
Programs and received positive feedback that we discussed in the 2014 
Edition Final Rule.\152\ On March 7, 2013, in conjunction with CMS, we 
published the ``Advancing Interoperability and Health Information 
Exchange'' Request for Information (RFI) in the Federal Register, which 
stated that ONC and CMS would continue to collaborate on the EHR 
Incentive Programs and ONC HIT Certification Program to ensure that the 
programs support delivery and payment reform.\153\ The RFI also noted 
that HHS intends to rely on all applicable and appropriate statutory 
authorities, regulations, policies, and programs to accelerate rapid 
adoption of health information exchange across the care continuum in 
support of delivery and payment reform. In response to comments 
received on the RFI, we issued a ``Principles and Strategy for 
Accelerating Health Information Exchange'' paper.\154\ As summarized in 
the paper, commenters made multiple recommendations for the use of 
certification and the expansion of the ONC HIT Certification 
Program.\155\ We stated in the paper: ``A critical part of enabling the 
secure flow of information across the system is advancing the adoption 
of HIT standards through voluntary certification of HIT and HIE 
products and services. CMS will consider various ways in which the 
voluntary certification of HIT and HIE products and services under the 
ONC HIT Certification Program could be aligned with Medicare and 
Medicaid payment policy, to the extent feasible and within the scope of 
applicable law.''
---------------------------------------------------------------------------

    \152\ 77 FR 54275.
    \153\ 78 FR 14793.
    \154\ http://www.healthit.gov/sites/default/files/acceleratinghieprinciples_strategy.pdf.
    \155\ For a summary of these recommendations, see page 5 of the 
``Principles and Strategy for Accelerating Health Information 
Exchange (HIE)'' paper.
---------------------------------------------------------------------------

1. Other Types of HIT
    This proposed rule takes a step towards the expansion of the ONC 
HIT Certification Program to accommodate other types of HIT. By 
proposing changes to the ONC HIT Certification Program to recognize the 
certification of MU and non-MU EHR Modules, EHR technology designed for 
other settings and purposes could be certified under the ONC HIT 
Certification Program to the 2015 Edition without having to meet 
certification criteria designed specifically for MU (see section IV.B 
for further discussion). This step, however, does not address the full 
range of HIT that might be certified to the certification criteria the 
Secretary may adopt in the future because all technologies would still 
be certified as ``EHR Modules'' even with our proposed changes. 
Visibility for stakeholders about the certifications issued and 
attribution for certifications that is more specific and distinct for 
other technologies that would not generally be considered ``EHR'' 
functionality, such as functionality provided by a health information 
exchange, HISP, or laboratory technology, would provide better 
marketing and purchasing clarity. With additional changes to the ONC 
HIT Certification Program, we could provide the proper visibility and 
attribution for these technologies by permitting them to be certified 
as ``HIT Modules.'' ``HIT Modules'' would be distinct from EHR Modules 
in that they would represent technologies that stakeholders recognize 
as distinct from EHR software and services. Certification for ``HIT 
Modules'' could also have long-term practicality as the ONC HIT 
Certification Program evolves. We welcome comments on this potential 
change to the ONC HIT Certification Program as we are considering 
moving in this direction as part of our 2017 Edition rulemaking.
2. Specific Types of Health Care Settings
    To begin the processes noted in the ``Principles and Strategy for 
Accelerating Health Information Exchange (HIE)'' paper, we asked the 
HIT Policy Committee to begin exploring the expansion of certification 
under the ONC HIT Certification Program, particularly focusing on EHR 
certification for the long-term and post-acute care (LTPAC) and 
behavioral health care settings. We expect the Certification/Adoption 
Workgroup of the HIT Policy Committee to present final recommendations 
to the HIT Policy Committee and the HIT Standards Committee in March 
2014. We have also received feedback and suggestions from other 
components of HHS about EHR technology certification for setting-
specific and specialty purposes. EHR technology certification could 
potentially be expanded given stakeholder demand for specific 
certification criteria targeted to support specific purposes. Below are 
some examples on which we seek comment as well as any other suggestion 
the public may have.
 Children's EHR Format
    The Children's EHR Format (``Format'') \156\ was authorized by the 
2009 Children's Health Insurance Program Reauthorization Act (CHIPRA) 
\157\ and developed by the Agency for Healthcare Research and Quality 
(AHRQ) in close collaboration with CMS. The Format was developed to 
bridge the gap between the functionality present in most EHRs currently 
available and the functionality that would more optimally support the 
care of children. Specifically, the Format provides information to EHR 
system developers and others about critical functionality, data 
elements, and other requirements that need to be present in an EHR 
system to address health care needs specific to the care of children, 
especially those enrolled in Medicaid or the Children's Health 
Insurance Program (CHIP). Providers who care for children (e.g., 
pediatricians, family physicians, and specialists) have criticized the 
absence of these ``pediatric'' functions when they are not available in 
EHR technology. The availability of certification of EHR technology to 
the Format (or, more likely, key aspects of the Format) may stimulate 
EHR technology developers to recognize and incorporate pediatric 
functionality into EHR technology as well as further the goals of 
CHIPRA and the agencies responsible for implementing it.
---------------------------------------------------------------------------

    \156\ http://healthit.ahrq.gov/health-it-tools-and-resources/childrens-electronic-health-record-ehr-format.
    \157\ Public Law 111-3, section 401.
---------------------------------------------------------------------------

 Practice Transformation
    To fully support comprehensive primary and specialty care toward 
the aim of better care and better health outcomes at lower cost EHR 
technology may need to include more advanced and specific capabilities 
that are not uniformly or widely available today. For example, the 
ability of EHR technology to enable users to construct a customized 
risk stratification algorithm within EHR technology through selection 
of structured data elements (e.g., diagnosis, labs, medications, 
symptoms, risk factors, frequency of visits, hospitalization or ED 
visit). Alternatively, it could include the ability to modify or adapt 
standardized risk stratification algorithms that identify individual 
patients risk levels and clearly demarcate this risk level within a 
patient's record. Further, it has been suggested that EHR technology

[[Page 10931]]

should enable a user to modify risk stratification algorithms by adding 
more elements or applying a global risk assessment based on clinical 
judgment. In addition to risk stratification, EHR technology may need 
to be able to track patients for care management services based on risk 
status with the ability to create customizable real-time lists of 
patients in different tiers of risk.
    As a second example in this category, we could adopt certification 
criteria for EHR technology that focuses on advanced care coordination 
features to integrate a patient's care plan into visit screens and 
other screens such that the patient view displays an updated and 
modifiable care plan documentation field. Further, a certification 
criterion could focus on ability to enable users to track tests and 
referrals that are in process and automatically trigger a reminder to 
view the results or follow up if results are not entered or received 
into the EHR by an expected date.

VI. Removal of the 2011 Edition EHR Certification Criteria and Related 
Standards, Terms, and Requirements and the Temporary Certification 
Program

A. 2011 Edition EHR Certification Criteria

    We propose modifications to remove the 2011 Edition EHR 
Certification Criteria and related standards, terms, and requirements 
from the Code of Federal Regulations. Specifically, we propose to 
remove 45 CFR Sec. Sec.  170.302, 170.304, and 170.306. We also propose 
to remove the standards and implementation specifications found in 45 
CFR Sec. Sec.  170.205, 170.207, 170.210, and 170.299 that are only 
referenced in the 2011 Edition EHR certification criteria. This means 
that if a standard is also referenced in the 2014 or 2015 Edition, it 
would remain in the regulation text. In regard to terms, we propose to 
retire the definitions found in 45 CFR Sec.  170.102 related to the 
2011 Edition, including ``2011 Edition EHR certification criteria'' and 
``Complete EHR, 2011 Edition.'' In regard to requirements, we propose 
to remove Sec.  170.550(e) and any other requirement in subpart E, 
Sec. Sec.  170.500 through 170.599 that is specific to the 2011 Edition 
and does not have general applicability to other editions of 
certification criteria.
    EHR technology certified to 2011 Edition is outmoded. It no longer 
meets the CEHRT definition and the 2011 Edition no longer represents an 
acceptable level of interoperability. Further, as referenced by the HHS 
Office of Inspector General and CMS in the recent rulemakings completed 
by those agencies around donations of EHR items and services, we expect 
to retire old/no longer applicable certification criteria 
editions.\158\ This approach will streamline our requirements and 
ensure there is no regulatory confusion involving administration of 
ONC's rules and these other agencies' rules. Thus, consistent with EO 
13563 instruction to ``determine whether any [agency] regulations 
should be modified, streamlined, expanded, or repealed so as to make 
the agency's regulatory program more effective or less burdensome in 
achieving the regulatory objectives,'' we are proposing to remove the 
2011 Edition and related standards, terms, and requirements from the 
Code of Federal Regulations.
---------------------------------------------------------------------------

    \158\ CMS final rule ``Medicare Program; Physicians' Referrals 
to Health Care Entities With Which They Have Financial 
Relationships: Exception for Certain Electronic Health Records 
Arrangements'' (78 FR 78751).
---------------------------------------------------------------------------

B. Temporary Certification Program

    The temporary certification program sunset on October 4, 2012, and 
is no longer in existence (77 FR 54268). Accordingly, we propose to 
remove from the Code of Federal Regulations the associated regulations, 
consisting of subpart D (Sec. Sec.  170.400 through 170.499).

VII. Response to Comments

    Because of the large number of public comments normally received in 
response to Federal Register documents, we are not able to acknowledge 
or respond to them individually. We will consider all comments we 
receive by the date and time specified in the DATES section of this 
preamble, and, when we proceed with a subsequent document, we will 
respond to the comments in the preamble of that document. As noted in 
section I.B.2, we do not plan to respond in that subsequent document to 
comments we receive concerning potential proposals for future 
rulemaking and the subject matter discussed in section V. ``Other 
Topics for Consideration for the 2017 Edition Certification Criteria 
Rulemaking.''

VIII. Collection of Information Requirements

    This proposed rule contains no new collections of information under 
the Paperwork Reduction Act nor does it propose to revise current 
collections of information approved by OMB.

IX. Regulatory Impact Statement

A. Statement of Need

    This proposed rule is being published to adopt a voluntary edition 
of certification criteria (2015 Edition). Certification criteria and 
associated standards and implementation specifications will be used to 
test and certify HIT in order to make it possible for EPs, EHs, and 
CAHs to adopt and implement HIT that can be used to meet the CEHRT 
definition. EPs, EHs, and CAHs who seek to qualify for incentive 
payments under the EHR Incentive Programs are required by statute to 
use CEHRT. The 2015 Edition provides an efficient and effective 
response to stakeholder feedback, incorporates ``bug fixes'' for 
errors, omissions and ambiguities found in our 2014 Edition EHR 
certification criteria, which will make our rules clearer and easier to 
implement, and includes newer standards and implementation 
specifications that reflect our commitment to promoting innovation and 
enhancing interoperability.

B. Overall Impact

    We have examined the impact of this proposed rule as required by 
Executive Order 12866 on Regulatory Planning and Review (September 30, 
1993), Executive Order 13563 on Improving Regulation and Regulatory 
Review (February 2, 2011), the Regulatory Flexibility Act (5 U.S.C. 601 
et seq.), section 202 of the Unfunded Mandates Reform Act of 1995 (2 
U.S.C. 1532), and Executive Order 13132 on Federalism (August 4, 1999).
1. Executive Orders 12866 and 13563--Regulatory Planning and Review 
Analysis
    Executive Orders 12866 and 13563 direct agencies to assess all 
costs and benefits of available regulatory alternatives and, if 
regulation is necessary, to select regulatory approaches that maximize 
net benefits (including potential economic, environmental, public 
health and safety effects, distributive impacts, and equity). A 
regulatory impact analysis (RIA) must be prepared for major rules with 
economically significant effects ($100 million or more in any 1 year). 
We have determined that this proposed rule is not an economically 
significant rule. Related costs to prepare EHR technology to be tested 
and certified are estimated to be less than $100 million per year. 
Nevertheless, because of the public interest in this proposed rule, we 
have prepared an RIA that to the best of our ability presents the costs 
and benefits of the proposed rule.
a. Costs
    This rule proposes the adoption of standards, implementation 
specifications, and certification criteria

[[Page 10932]]

that would establish the capabilities that EHR technology would need to 
demonstrate to be certified to the 2015 Edition. Our analysis focuses 
on the direct effects of the provisions of this proposed rule--the 
costs incurred by EHR technology developers to develop and prepare EHR 
technology to be tested and certified in accordance with the 
certification criteria (and the standards and implementation 
specifications they include) adopted by the Secretary. That is, we 
focus on the technological development and preparation costs necessary 
for EHR technology already certified to the 2014 Edition EHR 
certification criteria to upgrade to the proposed 2015 Edition EHR 
certification criteria and for developing a new EHR Module to meet the 
2015 Edition EHR certification criteria. The costs for testing and 
certification of EHR technologies to the 2015 Edition were captured in 
the regulatory impact analysis of the Permanent Certification Program 
final rule as we discuss in more detail below (IX.B.1.a.iii ``Testing 
and Certification Costs for the 2015 Edition''). The costs that EPs, 
EHs, and CAHs will incur in adopting and implementing EHR technology 
certified to the 2015 Edition are not within the scope of this final 
rule.
i. Development and Preparation Costs for the 2015 Edition
    The development costs we estimate are categorized based on the type 
of certification criteria we have identified for the purposes of gap 
certification (i.e., new, revised, and unchanged). For the 2014 Edition 
Final Rule, we used the total number of unique Complete EHRs and EHR 
Modules that had been certified to the 2011 Edition EHR certification 
criteria as identified in the CHPL for our regulatory impact analysis. 
At this point in time, we do not believe the CHPL is fully populated 
with all of the EHR technologies that will be certified to 2014 Edition 
EHR certification criteria. Accordingly, we are using the total number 
of unique \159\ 2011 Edition Complete EHRs and EHR Modules that were 
used for MU Stage 1 attestation as reported at the end of FY 2013.\160\ 
We expect, however, that upon issuance of the 2015 Edition Final Rule 
that the CHPL would provide a more complete picture of the number of 
EHR technologies certified to the 2014 Edition for use in our 
regulatory impact analysis and that we would use those numbers instead 
of the 2011 Edition numbers we include here for our current estimates.
---------------------------------------------------------------------------

    \159\ We attempted to discern how many Complete EHRs and EHR 
Modules were used that would not constitute a newer version of the 
same EHR technology.
    \160\ For 2015 Edition EHR certification criteria that do not 
have equivalent 2011 Edition EHR certification criteria, we used the 
unique number for the equivalent 2014 Edition EHR certification 
criteria as identified and used for the 2014 Edition Final Rule 
regulatory impact analysis.
---------------------------------------------------------------------------

    Using the unique number of 2011 Edition EHR technologies used for 
MU Stage 1 attestation we have established a range of EHR technologies 
that we believe will be developed and prepared to meet each of the 
proposed 2015 Edition EHR certification criteria based on the following 
four considerations:
     Before a subsequent 2015 Edition final rule is issued, 
many, if not most, EPs, EHs, and CAHs will have EHR technology 
certified to the 2014 Edition that can be used to meet the CEHRT 
definition for FY/CY 2014 and FY/CY 2015 because they must use EHR 
technology that has been certified to the 2014 Edition to meet the 
CEHRT definition beginning with FY/CY 2014.
     Unlike the 2014 Edition, the 2015 Edition is a voluntary 
edition of EHR certification criteria to which EPs, EHs, and CAHs are 
not required to possess EHR technology certified in order to meet the 
CEHRT definition on a certain date.
     The CEHRT definition only requires EPs, EHs, and CAHs to 
possess the CEHRT they need to demonstrate MU for the stage they seek 
to accomplish, which could conceivably directly affect the number of 
EHR technologies developed to certain certification criteria that 
support MU menu objectives and measures.
     Some EHR technology will be developed and prepared to meet 
the 2015 Edition that is not intended to be used by providers solely 
for MU purposes.
     Some EHR technology developers may wait to see what the 
2017 Edition includes in a 2017 Edition proposed rule, potentially 
certify EHR technology to the 2015 Edition, and then pursue gap 
certification to the final 2017 Edition.
    Based on these assumptions, we believe that between 20% and 40% of 
unique EHR technologies used for MU Stage 1 will be developed and 
prepared for certification to the 2015 Edition. This range takes into 
account potential new entrants to the market as well as those EHR 
technologies used for MU Stage 1 attestation that may no longer be 
brought forth for certification because of such factors as corporate 
re-organizations (e.g., mergers and acquisitions) as well as the loss 
of market share for some EHR technologies.\161\ This range also takes 
into account any potential non-MU-focused EHR technologies that will be 
developed and prepared to meet the 2015 Edition, but not designed for 
MU purposes. For unchanged certification criteria, we have only 
calculated development and preparation costs for 25-50 new EHR 
technologies. There would not be any costs associated with upgrading 
EHR technologies previously certified to the 2014 Edition and we do not 
expect any more than 25-50 new technologies to be certified to the 
unchanged 2015 Edition EHR certification criteria.
---------------------------------------------------------------------------

    \161\ This may be happening with EHR technologies being 
developed and prepared for certification to the 2014 Edition based 
on the number of certified EHR technologies listed on the CHPL as of 
October 2013.
---------------------------------------------------------------------------

    We are not aware of an available independent study (e.g., a study 
capturing the efforts and costs to develop and prepare Complete EHRs 
and EHR Modules to meet the requirements of the 2014 Edition EHR 
certification criteria) that we could rely upon as a basis for 
estimating the efforts and costs required to develop and prepare EHR 
technology to meet the 2015 Edition EHR certification criteria. 
Therefore, we have relied upon the approach we used for estimating the 
costs associated with developing and preparing EHR technology to meet 
the 2014 Edition EHR certification criteria in the 2014 Edition NPRM 
and 2014 Edition Final Rule (i.e., we have used our own research to 
estimate the effort required to develop and prepare EHR technology to 
meet the requirements of the 2015 Edition.).\162\ We have identified 
three levels of effort that we believe can be associated with the 
development and preparation of EHR technology to meet the requirements 
of the 2015 Edition. These levels of effort are the average range of 
hours we would expect to be necessary to develop EHR technology to meet 
the requirements of the 2015 Edition EHR certification criteria. This 
means that a few EHR technology developers' costs may be less than this 
range and a few may exceed the range. Level 1 is for certification 
criteria that we believe will require the least amount of effort to 
develop and prepare EHR technology for testing and certification to the 
criteria, with a range of 40-100 hours. Level 2 is for certification 
criteria that we believe will require a moderate amount of effort to 
develop and prepare EHR

[[Page 10933]]

technology for testing and certification to the criteria, with a range 
of 100-300 hours. Level 3 is for certification criteria that we believe 
will require the most amount of effort to develop and prepare EHR 
technology for testing and certification to the criteria, with a range 
of 300-400 hours.
---------------------------------------------------------------------------

    \162\ We have also estimated the costs for the proposed 
revisions to the 2014 Edition ``transmission to public health 
agencies--syndromic surveillance'' certification criterion (Sec.  
170.314(f)(3)).
---------------------------------------------------------------------------

    We have based the effort levels on the hours necessary for a 
software developer to develop and prepare the EHR technology for 
testing and certification. The U.S. Department of Labor, Bureau of 
Labor Statistics estimates that the mean hourly wage for a software 
developer is $44.85.\163\ We have also calculated the costs of an 
employee's benefits by assuming that an employer expends thirty-six 
percent (36%) of an employee's hourly wage on benefits for the 
employee. We have concluded that a 36% expenditure on benefits is an 
appropriate estimate because it is the routine percentage used by HHS 
for contract cost estimates. We have rounded up the average software 
developer's wage with benefits to $61 per hour.
---------------------------------------------------------------------------

    \163\ http://www.bls.gov/oes/current/oes151132.htm.
---------------------------------------------------------------------------

    To calculate our low cost estimates for each certification 
criterion in the tables below, we have multiplied the low number of the 
estimated range of EHR technologies expected to be developed and 
prepared by the low number of estimated hours for a software developer 
to develop and prepare the EHR technologies for testing and 
certification. To calculate our high cost estimates for each 
certification criterion in the tables below, we have multiplied the 
high number of the estimated range of EHR technologies expected to be 
developed and prepared to the criterion by the high number of estimated 
hours for a software developer to develop and prepare the EHR 
technologies for testing and certification. For the following tables 
(Tables 5 through Table 11), dollar amounts are expressed in 2014 
dollars.
New Certification Criteria

                      Table 5--2015 Edition New EHR Certification Criteria: Level 1 Effort
----------------------------------------------------------------------------------------------------------------
                                                                     Estimated
                                                                   number of EHR      Average         Average
                                                                   technologies     development     development
         Regulation section              Title of regulation           to be            and             and
                                              paragraph           developed with    preparation     preparation
                                                                       this         costs--low      costs--high
                                                                    capability         ($M)            ($M)
----------------------------------------------------------------------------------------------------------------
170.315(h)(1)......................  Transmit--Applicability             171-342             .42            2.09
                                      Statement for Secure
                                      Health Transport.
170.315(h)(2)......................  Transmit--Applicability             137-274             .33            1.67
                                      Statement for Secure
                                      Health Transport & XDR/XDM
                                      for Direct Messaging.
170.315(h)(3)......................  Transmit--SOAP Transport            137-274             .33            1.67
                                      and Security Specification
                                      & XDR/XDM for Direct
                                      Messaging.
                                    ----------------------------------------------------------------------------
    Total..........................  ...........................  ..............            1.08            5.43
----------------------------------------------------------------------------------------------------------------


                      Table 6--2015 Edition New EHR Certification Criteria: Level 2 Effort
----------------------------------------------------------------------------------------------------------------
                                                                     Estimated
                                                                   number of EHR      Average         Average
                                                                   technologies     development     development
         Regulation section              Title of regulation           to be            and             and
                                              paragraph           developed with    preparation     preparation
                                                                       this         costs--low      costs--high
                                                                    capability         ($M)            ($M)
----------------------------------------------------------------------------------------------------------------
170.315(a)(20).....................  Implantable device list....         151-303             .93            5.54
170.315(h)(4)......................  Transmit--Applicability               32-65             .20            1.19
                                      Statement for Secure
                                      Health Transport &
                                      Delivery Notification in
                                      Direct.
                                    ----------------------------------------------------------------------------
    Total..........................  ...........................  ..............            1.13            6.73
----------------------------------------------------------------------------------------------------------------


                      Table 7--2015 Edition New EHR Certification Criteria: Level 3 Effort
----------------------------------------------------------------------------------------------------------------
                                                                     Estimated
                                                                   number of EHR      Average         Average
                                                                   technologies     development     development
         Regulation section              Title of regulation           to be            and             and
                                              paragraph           developed with    preparation     preparation
                                                                       this         costs--low      costs--high
                                                                    capability         ($M)            ($M)
----------------------------------------------------------------------------------------------------------------
170.315(c)(4)......................  Clinical quality measures--         152-303            2.78            7.39
                                      patient population
                                      filtering.
170.314(g)(5)......................  Non-percentage-based                151-303            2.76            7.39
                                      measures reporting.
                                    ----------------------------------------------------------------------------
    Total..........................  ...........................  ..............            5.54           14.78
----------------------------------------------------------------------------------------------------------------

Revised Certification Criteria

[[Page 10934]]



                    Table 8--2015 Edition Revised EHR Certification Criteria: Level 1 Effort
----------------------------------------------------------------------------------------------------------------
                                                                     Estimated
                                                                   number of EHR      Average         Average
                                                                   technologies     development     development
         Regulation section              Title of regulation           to be            and             and
                                              paragraph           developed with    preparation     preparation
                                                                       this         costs--low      costs--high
                                                                    capability         ($M)            ($M)
----------------------------------------------------------------------------------------------------------------
170.315(a)(5)......................  Demographics...............         202-403             .49            2.46
170.315(a)(11).....................  Electronic notes...........          93-187             .23            1.14
170.315(a)(17).....................  Patient-specific education          153-306             .37            1.87
                                      resources.
170.315(b)(2)......................  Clinical information                158-317             .39            1.93
                                      reconciliation and
                                      incorporation.
170.315(b)(4)......................  Incorporate laboratory              157-314             .38            1.92
                                      tests and values/results.
170.315(b)(5)......................  Transmission of electronic            32-65             .08             .40
                                      laboratory tests and
                                      values/results to
                                      ambulatory providers
                                      (inpatient).
170.315(b)(6)......................  Data portability...........         149-298             .36            1.82
170.315(d)(2)......................  Auditable events and tamper-        196-392             .48            2.39
                                      resistance.
170.315(e)(2)......................  Clinical summary                    132-264             .32            1.61
                                      (ambulatory).
170.315(f)(2)......................  Transmission to                     145-289             .35            1.76
                                      immunization registries.
170.315(f)(4)......................  Transmission of reportable            26-51             .06             .31
                                      laboratory tests and
                                      values/results (inpatient
                                      setting).
170.315(f)(6)......................  Transmission to cancer                26-51             .06             .31
                                      registries.
                                    ----------------------------------------------------------------------------
    Total..........................  ...........................  ..............            3.57           17.92
----------------------------------------------------------------------------------------------------------------


                    Table 9--2014 Edition Revised EHR Certification Criteria: Level 2 Effort
----------------------------------------------------------------------------------------------------------------
                                                                     Estimated
                                                                   number of EHR      Average         Average
                                                                   technologies     development     development
         Regulation section              Title of regulation           to be            and             and
                                              paragraph           developed with    preparation     preparation
                                                                       this         costs--low      costs--high
                                                                    capability         ($M)            ($M)
----------------------------------------------------------------------------------------------------------------
170.314(f)(3)......................  Transmission to public              141-282             .86            5.16
                                      health agencies--syndromic
                                      surveillance.
                                    ----------------------------------------------------------------------------
    Total..........................  ...........................  ..............             .86            5.16
----------------------------------------------------------------------------------------------------------------


                    Table 10--2015 Edition Revised EHR Certification Criteria: Level 2 Effort
----------------------------------------------------------------------------------------------------------------
                                                                     Estimated
                                                                   number of EHR      Average         Average
                                                                   technologies     development     development
         Regulation section              Title of regulation           to be            and             and
                                              paragraph           developed with    preparation     preparation
                                                                       this         costs--low      costs--high
                                                                    capability         ($M)            ($M)
----------------------------------------------------------------------------------------------------------------
170.315(a)(2)......................  CPOE--laboratory...........         189-378            1.15            6.92
170.315(a)(10).....................  Clinical decision support..         190-380            1.16            6.95
170.315(a)(15).....................  Family health history......          93-187             .57            3.42
170.315(b)(1)......................  Transitions of care........         171-342            1.04            6.26
170.315(e)(1)......................  View, download, and                 126-252             .77            4.61
                                      transmit to third party.
170.315(f)(3)......................  Transmission to public              141-282             .86            5.16
                                      health agencies--syndromic
                                      surveillance.
                                    ----------------------------------------------------------------------------
    Total..........................  ...........................  ..............            5.55           33.32
----------------------------------------------------------------------------------------------------------------

Unchanged Certification Criteria

                   Table 11--2015 Edition Unchanged EHR Certification Criteria: Level 2 Effort
----------------------------------------------------------------------------------------------------------------
                                                                     Estimated
                                                                   number of EHR      Average         Average
                                                                   technologies     development     development
         Regulation section              Title of regulation           to be            and             and
                                              paragraph           developed with    preparation     preparation
                                                                       this         costs--low      costs--high
                                                                    capability         ($M)            ($M)
----------------------------------------------------------------------------------------------------------------
170.315(a)(1)......................  CPOE--medications..........           25-50             .06             .31
170.315(a)(3)......................  CPOE--radiology/imaging....           25-50             .06             .31
170.315(a)(4)......................  Drug-drug, drug-allergy               25-50             .06             .31
                                      interaction checks.
170.315(a)(6)......................  Vital signs, body mass                25-50             .06             .31
                                      index, and growth charts.

[[Page 10935]]

 
170.315(a)(7)......................  Problem list...............           25-50             .06             .31
170.315(a)(8)......................  Medication list............           25-50             .06             .31
170.315(a)(9)......................  Medication allergy list....           25-50             .06             .31
170.315(a)(12).....................  Drug formulary check.......           25-50             .06             .31
170.315(a)(13).....................  Smoking status.............           25-50             .06             .31
170.315(a)(14).....................  Image results..............           25-50             .06             .31
170.315(a)(16).....................  Patient list creation......           25-50             .06             .31
170.315(a)(18).....................  Electronic medication                 25-50             .06             .31
                                      administration record.
170.315(a)(19).....................  Advance directives.........           25-50             .06             .31
170.315(b)(3)......................  Electronic prescribing.....           25-50             .06             .31
170.315(c)(1)......................  Clinical quality measures--           25-50             .06             .31
                                      capture and export.
170.315(c)(2)......................  Clinical quality measures--           25-50             .06             .31
                                      import and calculate.
170.315(c)(3)......................  Clinical quality measures--           25-50             .06             .31
                                      electronic submission.
170.314(d)(1)......................  Authentication, access                25-50             .06             .31
                                      control, and authorization.
170.315(d)(3)......................  Audit report...............           25-50             .06             .31
170.315(d)(4)......................  Amendments.................           25-50             .06             .31
170.315(d)(5)......................  Automatic log-off..........           25-50             .06             .31
170.315(d)(6)......................  Emergency access...........           25-50             .06             .31
170.315(d)(7)......................  End-user device encryption.           25-50             .06             .31
170.315(d)(8)......................  Integrity..................           25-50             .06             .31
170.315(d)(9)......................  Accounting of disclosures..           25-50             .06             .31
170.315(e)(3)......................  Secure messaging...........           25-50             .06             .31
170.315(f)(1)......................  Immunization information...           25-50             .06             .31
170.315(f)(5)......................  Cancer case information....           25-50             .06             .31
170.315(g)(1)......................  Automated numerator                   25-50             .06             .31
                                      recording.
170.315(g)(2)......................  Automated measure                     25-50             .06             .31
                                      calculation.
170.315(g)(3)......................  Safety-enhanced design.....           25-50             .06             .31
170.315(g)(4)......................  Quality systems management.           25-50             .06             .31
                                    ----------------------------------------------------------------------------
    Total..........................  ...........................  ..............            1.92            9.92
----------------------------------------------------------------------------------------------------------------

ii. Overall Development and Preparation Costs Over a Two-Year Period
    In total, we estimate the overall costs to develop and prepare EHR 
technology for certification over a two-year period to be $19.65 
million to $93.26 million, with a cost mid-point of approximately 
$56.46 million. Evenly distributed over calendar years 2014 and 2015, 
the cost range would be $9.82 million to $46.63 per year with an annual 
cost mid-point of approximately $28.23. We project these costs to be 
evenly distributed over calendar years 2014 and 2015 for the following 
reasons:
     We expect a subsequent 2015 Edition final rule to be 
published in the summer of 2014.
     We expect a 2017 Edition proposed rule to be published in 
the fall 2014 and a 2017 Edition final rule to be published 
approximately by summer 2015.
     We assume a number of developers will develop and prepare 
EHR technology for testing and certification in the last half of 2014 
so that the EHR technology can be implemented and used to meet the 
current CEHRT definition.
     We expect development and preparation in 2015 to continue 
at a similar pace until a 2017 Edition final rule is published and 
testing and certification to the 2017 Edition certification criteria 
can begin.
     We expect that EHR technology developers will shift 
development and preparation of their EHR technology to meeting the 2017 
Edition because it is expected to become the basis for meeting the 
CEHRT definition in future years.
     While we could foresee EHR technology developers possibly 
shifting to development and preparation of their EHR technology to meet 
the 2017 Edition as soon as the 2017 Edition proposed rule is issued 
(fall 2014), we could also foresee HIT developers continuing 
development and preparation of their HIT to meet the 2015 Edition and 
then pursuing gap certification to the 2017 Edition.
    Table 12 below represents the costs attributable to this proposed 
rule distributed as follows: 50% for 2014 and 50% for 2015. The dollar 
amounts expressed in Table 12 are expressed in 2014 dollars.

                   Table 12--Distributed Total Preparation Costs for EHR Technology Developers
                                       [(Two-year period)--totals rounded]
----------------------------------------------------------------------------------------------------------------
                                                                                    Total high     Total average
                      Year                             Ratio      Total low cost   cost estimate   cost estimate
                                                     (percent)     estimate ($M)       ($M)            ($M)
----------------------------------------------------------------------------------------------------------------
2014............................................              50            9.82           46.63           28.23
2015............................................              50            9.82           46.63           28.23
                                                 ---------------------------------------------------------------

[[Page 10936]]

 
    2-Year Totals...............................  ..............           19.65           93.26           56.46
----------------------------------------------------------------------------------------------------------------

iii. Testing and Certification Costs for the 2015 Edition
    In the regulatory impact analysis of the Permanent Certification 
Program final rule, we estimated the costs for testing and 
certification of EHR technologies that would be used for providers to 
attempt to achieve MU Stages 1-3.\164\ These costs were based on a two-
year rulemaking cycle for the CEHRT definition and each MU Stage. We 
believe the costs we attributed to testing and certification of EHR 
technologies in support of MU Stage 2 in the Permanent Certification 
Program final rule would encompass the actual testing and certification 
of EHR technologies to both the 2014 and 2015 Editions. This assessment 
is based on the number of EHR technologies currently certified to the 
2014 Edition and our projections in this proposed rule for the number 
of EHR technologies that would likely be tested and certified to the 
2015 Edition EHR certification criteria. Further, we note that the 
estimated costs in the Permanent Certification Program final rule 
included costs for surveillance of EHR technologies and also estimated 
the costs for testing and certification above what we understand are 
the cost ranges charged by ONC-ACBs today. We welcome comments on our 
determination and our cost estimates.
---------------------------------------------------------------------------

    \164\ 76 FR 1318.
---------------------------------------------------------------------------

b. Benefits
    We believe that there will be several significant benefits that may 
arise from this proposed rule for patients, health care providers, and 
EHR technology developers. Our proposals incorporate stakeholder 
feedback on particular 2014 Edition issues identified as unnecessarily 
impeding innovation. Our proposed revisions also seek to continue to 
improve EHR technology's interoperability through the adoption of 
updated standards and implementation specifications. Furthermore, our 
proposal to separate ``content'' and ``transport'' capabilities in 2015 
Edition transitions of care certification criterion (compared to how 
the 2014 Edition version is structured) is aimed at significantly 
improving the market availability of electronic health information 
exchange services. And our proposed 2015 Edition ``view, download, 
transmit to 3rd party'' certification criterion includes a greater 
focus on enabling a patient to choose where they want to send their 
health information. We believe these proposed revisions would open new 
market opportunities for EPs, EHs, and CAHs to select best of breed 
products as well as reduce EHR technology developer burdens related to 
certification. Our proposals and requests for comment in this proposed 
rule also signal to the industry the future direction we hope to go 
with our certification criteria and certification program. This 
advanced visibility can better assist EHR technology developers plan 
for the future.
2. Regulatory Flexibility Act (RFA)
    The RFA requires agencies to analyze options for regulatory relief 
of small businesses if a rule has a significant impact on a substantial 
number of small entities.
    The Small Business Administration (SBA) establishes the size of 
small businesses for federal government programs based on average 
annual receipts or the average employment of a firm. While EHR 
technology developers that pursue certification under the ONC HIT 
Certification Program represent a small segment of the overall 
information technology industry, we believe that the entities impacted 
by this proposed rule most likely fall under the North American 
Industry Classification System (NAICS) code 541511 ``Custom Computer 
Programming Services'' specified at 13 CFR 121.201 where the SBA 
publishes ``Small Business Size Standards by NAICS Industry.'' The SBA 
size standard associated with this NAICS code is set at $25 million in 
annual receipts \165\ which ``indicates the maximum allowed for a 
concern and its affiliates to be considered small entities.''
---------------------------------------------------------------------------

    \165\ The SBA references that annual receipts means ``total 
income'' (or in the case of a sole proprietorship, ``gross income'') 
plus ``cost of goods sold'' as these terms are defined and reported 
on Internal Revenue Service tax return forms. 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 
2015 Edition certification criteria under the ONC HIT Certification 
Program. We also note that with the exception of aggregate business 
information available through the U.S. Census Bureau and the SBA 
related to NAICS code 541511, it appears that many EHR technology 
developers that pursue certification under the ONC HIT Certification 
Program are privately held or owned and do not regularly, if at all, 
make their specific annual receipts publicly available. As a result, it 
is difficult to locate empirical data related to many of these EHR 
technology developers to correlate to the SBA size standard. However, 
although not correlated to the size standard for NAICS code 541511, we 
do have information indicating that over 60% of EHR technology 
developers that have had Complete EHRs and/or EHR Modules certified to 
the 2011 Edition EHR certification criteria have less than 51 
employees.\166\
---------------------------------------------------------------------------

    \166\ We hope to update this information in a subsequent final 
rule based on data obtained regarding certification to the 2014 
Edition.
---------------------------------------------------------------------------

    We estimate that this proposed rule would have effects on EHR 
technology developers that are likely to pursue certification under the 
ONC HIT Certification Program, some of which may be small entities. 
However, we believe that we have proposed the minimum amount of 
requirements necessary to accomplish our policy goals, including a 
reduction in regulatory burden and additional flexibility for the 
regulated community, and that no additional appropriate regulatory 
alternatives could be developed to lessen the compliance burden 
associated with this proposed rule. We note that this proposed rule 
does not impose the costs cited in the regulatory impact analysis as 
compliance costs, but rather as

[[Page 10937]]

investments which these EHR technology developers voluntarily take on 
and expect to recover with an appropriate rate of return. Accordingly, 
we do not believe that the proposed rule will create a significant 
impact on a substantial number of small entities, but request comment 
on whether there are small entities that we have not identified that 
may be affected in a significant way by this proposed rule. 
Additionally, the Secretary certifies that this proposed rule will not 
have a significant impact on a substantial number of small entities.
3. Executive Order 13132--Federalism
    Executive Order 13132 establishes certain requirements that an 
agency must meet when it promulgates a proposed rule (and subsequent 
final rule) that imposes substantial direct requirement costs on state 
and local governments, preempts state law, or otherwise has federalism 
implications. Nothing in this proposed rule imposes substantial direct 
compliance costs on state and local governments, preempts state law or 
otherwise has federalism implications. We are not aware of any State 
laws or regulations that are contradicted or impeded by any of the 
standards, implementation specifications, or certification criteria 
that we propose for adoption.
4. Unfunded Mandates Reform Act of 1995
    Section 202 of the Unfunded Mandates Reform Act of 1995 requires 
that agencies assess anticipated costs and benefits before issuing any 
rule whose mandates require spending in any one year of $100 million in 
1995 dollars, updated annually for inflation. The current inflation-
adjusted statutory threshold is approximately $141 million. This 
proposed rule will not impose an unfunded mandate on State, local, and 
tribal governments or on the private sector that will reach the 
threshold level.

C. Request for Comments on 2017 Impact Analysis Methods

    In response to ONC's 2011 Edition and 2014 Edition rulemakings some 
stakeholders have suggested that we underestimate the burden associated 
with developing EHR technology to meet the certification criteria. Yet 
those stakeholders have not provided data or alternative(s) to the 
methods that we have used in our rules to prepare the best estimate we 
can. In our 2014 Edition Final Rule and in this proposed rule, we use a 
three level approach with hour ranges and multiply those ranges by the 
number of EHR technologies we expect to be developed to be tested and 
certified to those criteria. This proposed rule and the 2014 Edition 
Final Rule's impact analysis represented a significant improvement on 
our 2011 Edition's impact analysis due to the fact that we now have 
data on EHR technology certified to the criteria we had adopted.
    That being said, we believe we can do a better job estimating our 
certification criteria impacts so long as commenters, especially EHR 
technology developers, can provide company-specific responses with 
estimates or ranges. To facilitate more streamlined industry feedback, 
and in turn more accurate estimates, we are considering using the 
following template in our 2017 Edition rulemaking that would be part of 
each certification criterion's preamble discussion. We would pre-
populate this template in the 2017 Edition proposed rule with our 
burden/compliance estimates and enable commenters to compare our 
estimates to their own. The proposed estimates would also reflect 
whether the certification criterion's capabilities had previously been 
adopted. We believe that this level of feedback could then be used to 
more accurately reflect our regulation's potential impacts. We propose 
to use a template that splits out specific actions/specific technical 
capabilities as follows. We also expect have a ``level of effort'' 
multiplier/coefficient in the third column to account for instances 
where we would assume that EHR technology developers have already 
invested time and resources toward implementing a regulatory 
requirement. This multiplier would range from zero to one (or 0% to 
100%). For instance, with respect to a certification criterion that 
remains the same between editions, we may put a zero since our rule 
would not require any additional effort from the EHR technology 
developer to meet the criterion. Similarly, for certification criteria 
that only have a specific capability revised (e.g., the proposed 2015 
Edition ``demographics'' certification criterion), we could put zeros 
for most rows and .25 for the proposed updated language standard to 
account for the one change to an otherwise largely unmodified 
certification criterion.

------------------------------------------------------------------------
                                     First-time
                                    development        Multiplier for
    Certification criterion          effort for          subsequent
                                     regulatory     development level of
                                     compliance            effort
------------------------------------------------------------------------
Requirements/Design              X Hours..........  (0 to 1).
 Specification.
Capability 1 Total.............  XX Hours.........  (0 to 1).
Sub-Capability 1-1.............  X Hours..........  (0 to 1).
Sub-Capability 1-2.............  X Hours..........  (0 to 1).
Capability 2 Total.............  XX Hours.........  (0 to 1).
Capability 2-1.................  X Hours..........  (0 to 1).
Capability 2-2.................  X Hours..........  (0 to 1).
------------------------------------------------------------------------

    We also encourage stakeholders to review the HIMSS EHRA's 
development estimate presentation, delivered to the Meaningful Use 
Workgroup of the HITPC on September 24, 2013 and available here: http://www.healthit.gov/facas/calendar/2013/09/24/policy-meaningful-use-wg. 
The EHRA's model can serves as another point of input for commenters to 
consider in suggesting alternative methods for our impact analysis.
    Finally, we seek comment on whether this modified approach would be 
beneficial and which methodology stakeholders believe we should 
consider. We also ask stakeholders to comment on their ability and 
willingness to complete company level estimates in conjunction with the 
general comments in response to the NPRM.
    OMB reviewed this proposed rule.

List of Subjects in 45 CFR Part 170

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

[[Page 10938]]

recordkeeping requirements, Public health, Security.

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

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

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

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

0
2. In Sec.  170.102:
0
a. Remove the ``2011 Edition EHR certification criteria'' and 
``Complete EHR, 2011 Edition'' definitions;
0
b. Add in alphanumeric order the definitions for ``2015 Edition EHR 
certification criteria,'' ``Device Identifier,'' ``Implantable 
Device,'' ``Production Identifier,'' and ``Unique Device Identifier;'' 
and
0
c. Revise the definitions for ``Base EHR,'' paragraph (2) of 
``Certified EHR Technology,'' ``EHR Module'', and paragraph (6) of the 
``Common MU Data Set'' definition to read as follows:


Sec.  170.102  Definitions.

* * * * *
    2015 Edition EHR certification criteria means the certification 
criteria at Sec.  170.315.
    Base EHR means an electronic record of health-related information 
on an individual that:
    (1) Includes patient demographic and clinical health information, 
such as medical history and problem lists;
    (2) Has the capacity:
    (i) To provide clinical decision support;
    (ii) To support physician order entry;
    (iii) To capture and query information relevant to health care 
quality;
    (iv) To exchange electronic health information with, and integrate 
such information from other sources;
    (v) To protect the confidentiality, integrity, and availability of 
health information stored and exchanged; and
    (3) Has been certified to the certification criteria adopted by the 
Secretary at:
    (i) Section 170.314(a)(1); or Sec.  170.315(a)(1), (2), or (3);
    (ii) Section 170.314(a)(3) or Sec.  170.315(a)(5);
    (iii) Section 170.314(a)(5) or Sec.  170.315(a)(7);
    (iv) Section 170.314(a)(6) or Sec.  170.315(a)(8);
    (v) Section 170.314(a)(7) or Sec.  170.315(a)(9);
    (vi) Section 170.314(a)(8) or Sec.  170.315(a)(10);
    (vii) Both Sec.  170.314(b)(1) and (2); or, both Sec.  
170.315(b)(1) and Sec.  170.315(h)(1); or Sec.  170.314(b)(1) and (2) 
combined with either Sec.  170.315(b)(1) or Sec.  170.315(h)(1), or 
both Sec.  170.315(b)(1) and Sec.  170.315(h)(1);
    (viii) Section 170.314(b)(7) or Sec.  170.315(b)(6);
    (ix) Section 170.314(c)(1) or Sec.  170.315(c)(1);
    (x) Section 170.314(c)(2) or Sec.  170.315(c)(2);
    (xi) Section 170.314(c)(3) or Sec.  170.315(c)(3);
    (xii) Section 170.314(d)(1) or Sec.  170.315(d)(1);
    (xiii) Section 170.314(d)(2) or Sec.  170.315(d)(2);
    (xiv) Section 170.314(d)(3) or Sec.  170.315(d)(3);
    (xv) Section 170.314(d)(4) or Sec.  170.315(d)(4);
    (xvi) Section 170.314(d)(5) or Sec.  170.315(d)(5);
    (xvii) Section 170.314(d)(6) or Sec.  170.315(d)(6);
    (xviii) Section 170.314(d)(7) or Sec.  170.315(d)(7); and
    (xix) Section 170.314(d)(8) or Sec.  170.315(d)(8).
    (4) Has been certified to the certification criteria at Sec.  
170.314(c)(1) and (2) or Sec.  170.315(c)(1) and (2):
    (i) For no fewer than 9 clinical quality measures covering at least 
3 domains from the set selected by CMS for eligible professionals, 
including at least 6 clinical quality measures from the recommended 
core set identified by CMS; or
    (ii) For no fewer than 16 clinical quality measures covering at 
least 3 domains from the set selected by CMS for eligible hospitals and 
critical access hospitals.
* * * * *
    Certified EHR Technology means:
* * * * *
    (2) For FY and CY 2014 and subsequent years, the following: EHR 
technology certified under the ONC HIT Certification Program to the 
2014 or 2015 Edition EHR certification criteria that has:
    (i) The capabilities required to meet the Base EHR definition; and
    (ii) All other capabilities that are necessary to meet the 
objectives and associated measures under 42 CFR 495.6 and successfully 
report the clinical quality measures selected by CMS in the form and 
manner specified by CMS (or the States, as applicable) for the stage of 
meaningful use that an eligible professional, eligible hospital, or 
critical access hospital seeks to achieve.
Common MU Data Set
* * * * *
    (6) Preferred language. (i) The standard specified in Sec.  
170.207(g)(1) for certification to the 2014 Edition EHR certification 
criteria.
    (ii) The standard specified in Sec.  170.207(g)(2) for 
certification to the 2015 Edition EHR certification criteria.
* * * * *
    Device Identifier is defined as it is in 21 CFR 801.3.
* * * * *
    EHR Module means any service, component, or combination thereof 
that can meet the requirements of at least one certification criterion 
adopted by the Secretary.
    (1) MU EHR Module means any service, component, or combination 
thereof that is designed for purposes of the EHR Incentive Programs and 
can meet the requirements of at least one certification criterion 
adopted by the Secretary as part of the 2015 Edition EHR certification 
criteria.
    (2) Non-MU EHR Module means any service, component, or combination 
thereof that is designed for any purpose other than the EHR Incentive 
Programs and can meet the requirements of at least one certification 
criterion adopted by the Secretary as part of the 2015 Edition EHR 
certification criteria.
* * * * *
    Implantable Device is defined as it is in 21 CFR 801.3.
* * * * *
    Production Identifier is defined as it is in 21 CFR 801.3.
* * * * *
    Unique Device Identifier is defined as it is in 21 CFR 801.3.
0
3. In Sec.  170.202, republish the introductory text and add paragraphs 
(d) and (e) to read as follows:


Sec.  170.202  Transport standards.

    The Secretary adopts the following transport standards:
* * * * *
    (d) Standard. ONC Implementation Guide for Delivery Notification in 
Direct.
    (e) Standard. ONC Implementation Guide for Direct Edge Protocols.
0
4. Amend Sec.  170.204 by--
0
A. Republishing the introductory text;
0
B. Revising paragraph (a);
0
C. Revising paragraph (b)(2) and adding paragraph (b)(3); and
0
D. Adding paragraphs (d) and (e).
    The revisions and additions read as follows:

[[Page 10939]]

Sec.  170.204  Functional standards.

    The Secretary adopts the following functional standards:
    (a) Accessibility. (1) Standard. Web Content Accessibility 
Guidelines (WCAG) 2.0, Level A Conformance (incorporated by reference 
in Sec.  170.299).
    (2) Standard. Web Content Accessibility Guidelines (WCAG) 2.0, 
Level AA Conformance.
    (b) * * *
    (2) Implementation specifications. HL7 Implementation Guide: 
Service-Oriented Architecture Implementations of the Context-aware 
Knowledge Retrieval (Infobutton) Domain, Draft Standard for Trial Use, 
Release 1.
    (3) Implementation specifications. HL7 Implementation Guide: 
Service-Oriented Architecture Implementations of the Context-aware 
Knowledge Retrieval (Infobutton) Domain, Release 1.
* * * * *
    (d) Decision Support. Standard. HL7 Implementation Guide: Clinical 
Decision Support Knowledge Artifact Implementation Guide.
    (e) Decision Support. Standard. HL7 Decision Support Service 
Implementation Guide.
0
5. Amend Sec.  170.205 by--
0
A. Republishing the introductory text;
0
B. Adding paragraph (a)(4);
0
C. Removing and reserving paragraphs (b)(1), (c), and (d)(1);
0
D. Adding paragraphs (d)(4) and (5);
0
E. Removing and reserving paragraphs (e)(1), and (e)(2);
0
F. Adding paragraph (e)(4);
0
G. Removing and reserving paragraph (f);
0
H. Revising paragraphs (g), (i), and (j); and
0
I. Adding paragraphs (l) and (m).
    The revisions and additions read as follows:


Sec.  170.205  Content exchange standards and implementation 
specifications for exchanging electronic health information.

    The Secretary adopts the following content exchange standards and 
associated implementation specifications:
    (a) * * *
    (4) Standard. HL7 Implementation Guide for CDA[supreg] Release 2: 
Consolidated CDA Templates for Clinical Notes, Draft Standard for Trial 
Use, Release 2.0. The use of the ``unstructured document'' document-
level template is prohibited.
    (b) * * *
    (1) [Reserved]
* * * * *
    (c) [Reserved]
    (d) * * *
    (1) [Reserved]
* * * * *
    (4) Standard. HL7 2.5.1 (incorporated by reference in Sec.  
170.299). Implementation specifications. PHIN Messaging Guide for 
Syndromic Surveillance: Emergency Department, Urgent Care, and 
Inpatient Settings, Release 1.9.
    (5) HL7 Clinical Document Architecture (CDA), Release 2.0, 
Normative Edition (incorporated by reference in Sec.  170.299).
    (e) * * *
    (1) [Reserved]
    (2) [Reserved]
* * * * *
    (4) Standard. HL7 2.5.1 (incorporated by reference in Sec.  
170.299). Implementation specifications. HL7 2.5.1 Implementation Guide 
for Immunization Messaging, Release 1.5.
    (f) [Reserved]
    (g) Electronic transmission of lab results to public health 
agencies. (1) Standard. HL7 2.5.1 (incorporated by reference in Sec.  
170.299). Implementation specifications. HL7 Version 2.5.1 
Implementation Guide: Electronic Laboratory Reporting to Public Health, 
Release 1 (incorporated by reference in Sec.  170.299) with Errata and 
Clarifications, (incorporated by reference in Sec.  170.299) and ELR 
2.5.1 Clarification Document for EHR Technology Certification 
(incorporated by reference in Sec.  170.299).
    (2) Standard. HL7 2.5.1 (incorporated by reference in Sec.  
170.299). Implementation specifications. HL7 Version 2.5.1 
Implementation Guide: Electronic Laboratory Reporting to Public Health, 
Draft Standard for Trial Use, Release 2.
* * * * *
    (i) Cancer information. (1) Standard. HL7 Clinical Document 
Architecture (CDA), Release 2.0, Normative Edition (incorporated by 
reference in Sec.  170.299). Implementation specifications. 
Implementation Guide for Ambulatory Healthcare Provider Reporting to 
Central Cancer Registries, HL7 Clinical Document Architecture (CDA), 
Release 1.0 (incorporated by reference in Sec.  170.299).
    (2) Standard. HL7 Clinical Document Architecture (CDA), Release 
2.0, Normative Edition (incorporated by reference in Sec.  170.299). 
Implementation specifications. Implementation Guide for Ambulatory 
Healthcare Provider Reporting to Central Cancer Registries, HL7 
Clinical Document Architecture (CDA), Release 1.1.
    (j) Electronic incorporation and transmission of lab results. (1) 
Standard. HL7 Version 2.5.1 Implementation Guide: S&I Framework Lab 
Results Interface (incorporated by reference in Sec.  170.299).
    (2) Standard. HL7 Version 2.5.1 Implementation Guide: S&I Framework 
Lab Results Interface, Release 1 (US Realm) (S&I Framework LRI) with 
Errata.
* * * * *
    (l) Laboratory orders. (1) Standard. HL7 Version 2.5.1 
Implementation Guide: S&I Framework Laboratory Orders from EHR.
    (2) [Reserved]
    (m) Family health history. (1) HL7 Version 3 Standard: Clinical 
Genomics; Pedigree (incorporated by reference in Sec.  170.299). 
Implementation specifications. HL7 Version 3 Implementation Guide: 
Family History/Pedigree Interoperability.
    (2) [Reserved]
0
6. Amend Sec.  170.207 by--
0
A. Republishing the introductory text;
0
B. Removing and reserving paragraphs (a)(1), (a)(2), (b)(1), (c)(1), 
(d)(1), and (e)(1); and
0
C. Revising paragraph (g).
    The revisions read as follows:


Sec.  170.207  Vocabulary standards for representing electronic health 
information.

    The Secretary adopts the following code sets, terminology, and 
nomenclature as the vocabulary standards for the purpose of 
representing electronic health information:
    (a) * * *
    (1) [Reserved]
    (2) [Reserved]
* * * * *
    (b) * * *
    (1) [Reserved]
* * * * *
    (c) * * *
    (1) [Reserved]
* * * * *
    (d) * * *
    (1) [Reserved]
* * * * *
    (e) * * *
    (1) [Reserved]
* * * * *
    (g) Preferred language. (1) Standard. As specified by the Library 
of Congress, ISO 639-2 alpha-3 codes limited to those that also have a 
corresponding alpha-2 code in ISO 639-1 (incorporated by reference in 
Sec.  170.299).
    (2) Standard. As specified by the Library of Congress, ISO 639-2.
* * * * *


Sec.  170.210  [Amended]

0
7. In Sec.  170.210, remove and reserve paragraphs (a)(2) and (b).
0
8. Add Sec.  170.212 to read as follows:

[[Page 10940]]

Sec.  170.212  Performance standards for health information technology.

    The Secretary adopts the following performance standards for health 
information technology:
    (a) EHR technology must successfully electronically process 
documents validly formatted in accordance with the standard specified 
in Sec.  170.205(a)(4) no less than 95% of the time.
    (b) [Reserved]
0
9. In Sec.  170.300, revise paragraph (d) to read as follows:


Sec.  170.300  Applicability.

* * * * *
    (d) In Sec. Sec.  170.314 and 170.315, all certification criteria 
and all capabilities specified within a certification criterion have 
general applicability (i.e., apply to both ambulatory and inpatient 
settings) unless designated as ``inpatient setting only'' or 
``ambulatory setting only.''
    (1) Inpatient setting only means that the criterion or capability 
within the criterion is only required for certification of EHR 
technology designed for use in an inpatient setting.
    (2) Ambulatory setting only means that the criterion or capability 
within the criterion is only required for certification of EHR 
technology designed for use in an ambulatory setting.


Sec.  170.302  [Removed and Reserved]

0
10. Remove and reserve Sec.  170.302.


Sec.  170.304  [Removed and Reserved]

0
11. Remove and reserve Sec.  170.304.


Sec.  170.306  [Removed and Reserved]

0
12. Remove and reserve Sec.  170.306.
0
13. In Sec.  170.314:
0
A. In Sec.  170.314(a)(3)(i)(B), remove ``Sec.  170.207(g)'' and add in 
its place ``Sec.  170.207(g)(1)'';
0
B. In Sec.  170.314(b)(5)(i)(A)(1), remove ``Sec.  170.205(j)'' and add 
in its place ``Sec.  170.205(j)(1)'';
0
C. In Sec.  170.314(b)(6), remove ``Sec.  170.205(j)'' and add in its 
place ``Sec.  170.205(j)(1)'';
0
D. In Sec.  170.314(e)(1)(i)(A), remove ``Sec.  170.204(a)'' and add in 
its place ``Sec.  170.204(a)(1)'';
0
E. In Sec.  170.314(f)(4)(i), remove ``Sec.  170.205(g)'' and add in 
its place ``Sec.  170.205(g)(1)'';
0
F. In Sec.  170.314(f)(6), remove ``Sec.  170.205(i)'' and add in its 
place '' Sec.  170.205(i)(1)'';
    and
0
G. Revise Sec.  170.314(f)(3) and (g)(1).
    The revisions read as follows:


Sec.  170.314  2014 Edition electronic health record certification 
criteria.

* * * * *
    (f) * * *
    (3) * * *
    (i) Ambulatory setting only. The standard specified in Sec.  
170.205(d)(2), (d)(5), or (k).
    (B) Optional. The standard (and applicable implementation 
specifications) specified in Sec.  170.205(d)(4).
    (ii) Inpatient setting only. The standard (and implementation 
specifications) specified in Sec.  170.205(d)(4).
* * * * *
    (g) * * *
    (1) Optional--Automated numerator recording. For each meaningful 
use objective with a percentage-based measure, EHR technology must be 
able to create a report or file that enables a user to review the 
patients or actions that would make the patient or action eligible to 
be included in the measure's numerator. The information in the report 
or file created must be of sufficient detail such that it enables a 
user to match those patients or actions to meet the measure's 
denominator limitations when necessary to generate an accurate 
percentage.
* * * * *
0
14. Add Sec.  170.315 as follows:


Sec.  170.315  2015 Edition electronic health record certification 
criteria.

    The Secretary adopts the following certification criteria for EHR 
technology certification. EHR technology must include the capability to 
perform the following functions electronically, unless designated as 
optional, and in accordance with all applicable standards and 
implementation specifications adopted in this part:
    (a) Clinical. (1) Computerized provider order entry--medications. 
Enable a user to electronically record, change, and access medication 
orders.
    (2) Computerized provider order entry--laboratory. (i) Enable a 
user to electronically record, change, and access laboratory orders.
    (ii) Ambulatory setting only. Enable a user to electronically 
create laboratory orders for electronic transmission:
    (A) With all the information for a test requisition as specified at 
42 CFR 493.1241(c)(1) through (c)(8); and
    (B) In accordance with the standard specified at Sec.  
170.205(l)(1) and, at a minimum the version of the standard at Sec.  
170.207(c)(2).
    (3) Computerized provider order entry--radiology/imaging. Enable a 
user to electronically record, change, and access radiology and imaging 
orders.
    (4) Drug-drug, drug-allergy interaction checks. (i) Interventions. 
Before a medication order is completed and acted upon during 
computerized provider order entry (CPOE), interventions must 
automatically and electronically indicate to a user drug-drug and drug-
allergy contraindications based on a patient's medication list and 
medication allergy list.
    (ii) Adjustments. (A) Enable the severity level of interventions 
provided for drug-drug interaction checks to be adjusted.
    (B) Limit the ability to adjust severity levels to an identified 
set of users or available as a system administrative function.
    (5) Demographics. (i) Enable a user to electronically record, 
change, and access patient demographic data including preferred 
language, sex, race, ethnicity, and date of birth.
    (A) Enable race and ethnicity to be recorded in accordance with the 
standard specified in Sec.  170.207(f) and whether a patient declines 
to specify race and/or ethnicity.
    (B) Enable preferred language to be recorded in accordance with the 
standard specified in Sec.  170.207(g)(2) and whether a patient 
declines to specify a preferred language.
    (ii) Inpatient setting only. Enable a user to electronically 
record, change, and access the preliminary cause of death and date of 
death in the event of a mortality.
    (6) Vital signs, body mass index, and growth charts. (i) Vital 
signs. Enable a user to electronically record, change, and access, at a 
minimum, a patient's height/length, weight, and blood pressure. Height/
length, weight, and blood pressure must be recorded in numerical values 
only.
    (ii) Calculate body mass index. Automatically calculate and 
electronically display body mass index based on a patient's height and 
weight.
    (iii) Optional--Plot and display growth charts. Plot and 
electronically display, upon request, growth charts for patients.
    (7) Problem list. Enable a user to electronically record, change, 
and access a patient's active problem list:
    (i) Ambulatory setting. Over multiple encounters in accordance 
with, at a minimum, the version of the standard specified in Sec.  
170.207(a)(3); or
    (ii) Inpatient setting. For the duration of an entire 
hospitalization in accordance with, at a minimum, the version of the 
standard specified in Sec.  170.207(a)(3).
    (8) Medication list. Enable a user to electronically record, 
change, and access a patient's active medication list as well as 
medication history:
    (i) Ambulatory setting. Over multiple encounters; or

[[Page 10941]]

    (ii) Inpatient setting. For the duration of an entire 
hospitalization.
    (9) Medication allergy list. Enable a user to electronically 
record, change, and access a patient's active medication allergy list 
as well as medication allergy history:
    (i) Ambulatory setting. Over multiple encounters; or
    (ii) Inpatient setting. For the duration of an entire 
hospitalization.
    (10) Clinical decision support. (i) Evidence-based decision support 
interventions. Enable a limited set of identified users to select 
(i.e., activate) one or more electronic clinical decision support 
interventions (in addition to drug-drug and drug-allergy 
contraindication checking) based on each one and at least one 
combination of the following data:
    (A) Problem list;
    (B) Medication list;
    (C) Medication allergy list;
    (D) At least one demographic specified in paragraph (a)(5)(i) of 
this section;
    (E) Laboratory tests; and
    (F) Vital signs.
    (ii) Linked referential clinical decision support. (A) EHR 
technology must be able to:
    (1) Electronically identify for a user diagnostic and therapeutic 
reference information; or
    (2) Electronically identify for a user diagnostic and therapeutic 
reference information in accordance with the standard specified at 
Sec.  170.204(b) and the implementation specifications at Sec.  
170.204(b)(1) or (3).
    (B) For paragraph (a)(10)(ii)(A) of this section, EHR technology 
must be able to electronically identify for a user diagnostic or 
therapeutic reference information based on each one and at least one 
combination of the data referenced in paragraphs (a)(10)(i)(A), (B), 
and (D) of this section.
    (iii) Clinical decision support configuration. (A) Enable 
interventions and reference resources specified in paragraphs 
(a)(10)(i) and (ii) of this section to be configured by a limited set 
of identified users (e.g., system administrator) based on a user's 
role.
    (B) EHR technology must enable interventions to be electronically 
triggered:
    (1) Based on the data referenced in paragraphs (a)(10)(i)(A) 
through (F) of this section.
    (2) When a patient's medications, medication allergies, and 
problems are incorporated from a transition of care/referral summary 
received pursuant to paragraph (b)(1)(i)(B) of this section.
    (3) Ambulatory setting only. When a patient's laboratory tests and 
values/results are incorporated pursuant to paragraph (b)(4)(i)(A)(1) 
of this section.
    (iv) Automatically and electronically interact. Interventions 
triggered in accordance with paragraphs (a)(10)(i) through (iii) of 
this section must automatically and electronically occur when a user is 
interacting with EHR technology.
    (v) Source attributes. Enable a user to review the attributes as 
indicated for all clinical decision support resources:
    (A) For evidence-based decision support interventions under 
paragraph (a)(10)(i) of this section:
    (1) Bibliographic citation of the intervention (clinical research/
guideline);
    (2) Developer of the intervention (translation from clinical 
research/guideline);
    (3) Funding source of the intervention development technical 
implementation; and
    (4) Release and, if applicable, revision date(s) of the 
intervention or reference source.
    (B) For linked referential clinical decision support in paragraph 
(a)(10)(ii) of this section and drug-drug, drug-allergy interaction 
checks in paragraph(a)(4) of this section, the developer of the 
intervention, and where clinically indicated, the bibliographic 
citation of the intervention (clinical research/guideline).
    (vi) Decision support--knowledge artifact. Electronically process 
clinical decision support knowledge artifacts in accordance with the 
standard specified at Sec.  170.204(d).
    (vii) Decision support--service. Enable a user to electronically 
make an information request with patient data and receive in return 
electronic clinical guidance in accordance with the standard specified 
at Sec.  170.204(e).
    (11) Electronic notes. Enable a user to electronically:
    (i) Record, change, and access electronic notes; and
    (ii) Search within and across electronic notes stored within EHR 
technology.
    (12) Drug-formulary checks. EHR technology must automatically and 
electronically check whether a drug formulary (or preferred drug list) 
exists for a given patient and medication.
    (13) Smoking status. Enable a user to electronically record, 
change, and access the smoking status of a patient in accordance with 
the standard specified at Sec.  170.207(h).
    (14) Image results. Electronically indicate to a user the 
availability of a patient's images and narrative interpretations 
(relating to the radiographic or other diagnostic test(s)) and enable 
electronic access to such images and narrative interpretations.
    (15) Family health history. Enable a user to electronically record, 
change, and access a patient's family health history according to the 
standard and implementation specification specified at Sec.  
170.205(m)(1).
    (16) Patient list creation. Enable a user to electronically and 
dynamically select, sort, access, and create patient lists by: date and 
time; and based on each one and at least one combination of the 
following data:
    (i) Problems;
    (ii) Medications;
    (iii) Medication allergies;
    (iv) At least one demographic specified in paragraph (a)(5)(i) of 
this section;
    (v) Laboratory tests and values/results; and
    (vi) Ambulatory setting only. Patient communication preferences.
    (17) Patient-specific education resources. EHR technology must be 
able to electronically identify for a user patient-specific education 
resources based on data included in the patient's problem list, 
medication list, and laboratory tests:
    (i) In accordance with the standard specified at Sec.  170.204(b) 
and the implementation specifications at Sec.  170.204(b)(1) or (3); 
and
    (ii) By any means other than using the standard specified in Sec.  
170.204(b).
    (18) Inpatient setting only--electronic medication administration 
record. (i) In combination with an assistive technology that provides 
automated information on the ``rights'' specified in paragraphs 
(a)(18)(i)(A) through (E) of this section, enable a user to 
electronically verify the following before administering medication(s):
    (A) Right patient. The patient to whom the medication is to be 
administered matches the medication to be administered.
    (B) Right medication. The medication to be administered matches the 
medication ordered for the patient.
    (C) Right dose. The dose of the medication to be administered 
matches the dose of the medication ordered for the patient.
    (D) Right route. The route of medication delivery matches the route 
specified in the medication order.
    (E) Right time. The time that the medication was ordered to be 
administered compared to the current time.
    (ii) Right documentation. Electronically record the time and date 
in accordance with the standard specified in Sec.  170.210(g), and user

[[Page 10942]]

identification when a medication is administered.
    (19) Inpatient setting only--advance directives. Enable a user to 
electronically record whether a patient has an advance directive.
    (20) Implantable device list. (i) Enable a user to electronically 
access and view a list of Unique Device Identifiers and other relevant 
information associated with a patient's Implantable Device(s).
    (ii) Enable a user to electronically record in a patient's 
Implantable Device list the following information at the time the 
Implantable Device is implanted or removed:
    (A) The Unique Device Identifier associated with the Implantable 
Device; and
    (B) Other relevant information about the Implantable Device or 
procedure.
    (iii) For each Unique Device Identifier in a patient's Implantable 
Device list, allow a user to separately access and view electronically 
the Device Identifier and Production Identifier portions of the Unique 
Device Identifier.
    (b)Care coordination. (1) Transitions of care. (i) Send and receive 
via edge protocol. EHR technology must be able to electronically:
    (A) Send transitions of care/referral summaries through a method 
that conforms to the standard specified at Sec.  170.202(e) and that 
leads to such summaries being processed by a service that has 
implemented the standard specified in Sec.  170.202(a); and
    (B) Receive transitions of care/referral summaries through a method 
that conforms to the standard specified at Sec.  170.202(e) from a 
service that has implemented the standard specified in Sec.  
170.202(a).
    (ii) Receiving accuracy. EHR technology must meet or exceed the 
standard specified at Sec.  170.212(a)
    (iii) Display.
    (A) EHR technology must be able to electronically display in human 
readable format the data included in transition of care/referral 
summaries received and formatted according to any of the following 
standards (and applicable implementation specifications) specified in: 
Sec.  170.205(a)(1) through (4).
    (B) Section views. Extract and allow for individual display each 
additional section or sections (and the accompanying document header 
information) that were included in a transition of care/referral 
summary received and formatted in accordance with the standard adopted 
at Sec.  170.205(a)(3).
    (iv) Create. (A) Enable a user to electronically create a 
transition of care/referral summary formatted according to the standard 
adopted at Sec.  170.205(a)(4) that includes, at a minimum, the Common 
MU Data Set and the following data expressed, where applicable, 
according to the specified standard(s):
    (1) Encounter diagnoses. The standard specified in Sec.  170.207(i) 
or, at a minimum, the version of the standard specified Sec.  
170.207(a)(3);
    (2) Immunizations. The standard specified in Sec.  170.207(e)(2);
    (3) Cognitive status;
    (4) Functional status;
    (5) Ambulatory setting only. The reason for referral; and referring 
or transitioning provider's name and office contact information;
    (6) Inpatient setting only. Discharge instructions; and
    (7) Unique Device Identifier(s) for a patient's Implantable 
Device(s).
    (B) Patient matching data quality. EHR technology must be capable 
of creating a transition of care/referral summary that includes the 
following data and, where applicable, represent such data according to 
the additional constraints specified below:
    (1) Data. first name, last name, middle name (or middle initial in 
cases where only it exists/is used), suffix, date of birth, place of 
birth, maiden name, current address, historical address, phone number, 
and sex.
    (2) Constraint. Represent last/family name according to the CAQH 
Phase II Core 258: Eligibility and Benefits 270/271 Normalizing Patient 
Last Name Rule version 2.1.0.
    (3) Constraint. Represent suffix according to the CAQH Phase II 
Core 258: Eligibility and Benefits 270/271 Normalizing Patient Last 
Name Rule version 2.1.0 (JR, SR, I, II, III, IV, V, RN, MD, Ph.D., 
ESQ). If no suffix exists, the field should be entered as null.
    (4) Constraint. Represent the year, month and date of birth are 
required fields while hour, minute and second should be optional 
fields. If hour, minute and second are provided then either time zone 
offset should be included unless place of birth (city, region, country) 
is provided; in latter local time is assumed. If date of birth is 
unknown, the field should be marked as null.
    (5) Constraint. Represent current and historical address 
information, including the street address, city, state, zip code, 
according to the United States Postal Service format;
    (6) Constraint. Represent phone number (home, business, cell) in 
the ITU format specified in ITU-T E.123 and ITU-T E.164. If multiple 
phone numbers are present, all should be included.
    (7) Constraint. Represent sex according to the HL7 Version 3 
ValueSet for Administrative Gender.
    (2) Clinical information reconciliation and incorporation. (i) 
Correct patient. Upon receipt of a transition of care/referral summary 
formatted according to the standard adopted at Sec.  170.205(a)(4), EHR 
technology must be able to demonstrate that the transition of care/
referral summary received is or can be properly matched to the correct 
patient.
    (ii) Reconciliation. Enable a user to electronically reconcile the 
data that represent a patient's active medication, problem, and 
medication allergy list as follows. For each list type:
    (A) Electronically and simultaneously display (i.e., in a single 
view) the data from at least two list sources in a manner that allows a 
user to view the data and their attributes, which must include, at a 
minimum, the source and last modification date;
    (B) Enable a user to create a single reconciled list of 
medications, medication allergies, or problems;
    (C) Enable a user to review and validate the accuracy of a final 
set of data; and
    (D) Upon a user's confirmation, automatically update the list, and 
electronically incorporate the following data expressed according to 
the specified standard(s):
    (1) Medications. At a minimum, the version of the standard 
specified in Sec.  170.207(d)(2);
    (2) Problems. At a minimum, the version of the standard specified 
in Sec.  170.207(a)(3);
    (3) Medication allergies. At a minimum, the version of the standard 
specified in Sec.  170.207(d)(2).
    (3) Electronic prescribing. Enable a user to electronically create 
prescriptions and prescription-related information for electronic 
transmission in accordance with:
    (i) The standard specified in Sec.  170.205(b)(2); and
    (ii) At a minimum, the version of the standard specified in Sec.  
170.207(d)(2).
    (4) Incorporate laboratory tests and values/results. (i) Receive 
results. (A) Ambulatory setting only. (1) Electronically receive and 
incorporate clinical laboratory tests and values/results in accordance 
with the standard specified in Sec.  170.205(j)(2) and, at a minimum, 
the version of the standard specified in Sec.  170.207(c)(2).
    (2) Electronically display the tests and values/results received in 
human readable format.
    (B) Inpatient setting only. Electronically receive clinical 
laboratory tests and values/results in a structured format and 
electronically display such

[[Page 10943]]

tests and values/results in human readable format.
    (ii) Electronically display the test report information:
    (A) Specified in 42 CFR 493.1291(a)(1) through (a)(3) and (c)(1) 
through (c)(7);
    (B) Related to reference values as specified in 42 CFR 493.1291(d);
    (C) For alerts and delays as specified in 42 CFR 493.1291(g) and 
(h); and
    (D) For corrected reports as specified in 42 CFR 493.1291(k)(2).
    (iii) Electronically attribute, associate, or link a laboratory 
test and value/result with a laboratory order or patient record.
    (5) Inpatient setting only--transmission of electronic laboratory 
tests and values/results to ambulatory providers. EHR technology must 
be able to electronically create laboratory test reports for electronic 
transmission: (i) That includes the information:
    (A) For a test report as specified in 42 CFR 493.1291(a)(1) through 
(a)(3) and (c)(1) through (c)(7);
    (B) Related to reference values as specified in 42 CFR 493.1291(d);
    (C) For alerts and delays as specified in 42 CFR 493.1291(g) and 
(h); and
    (D) For corrected reports as specified in 42 CFR 493.1291(k)(2); 
and
    (ii) In accordance with the standard specified in Sec.  
170.205(j)(2) and with laboratory tests expressed in accordance with, 
at a minimum, the version of the standard specified in Sec.  
170.207(c)(2).
    (6) Data portability. Enable a user to electronically create a set 
of export summaries for all patients in EHR technology formatted 
according to the standard adopted at Sec.  170.205(a)(4) that 
represents the most current clinical information about each patient and 
includes, at a minimum, the Common MU Data Set and the following data 
expressed, where applicable, according to the specified standard(s):
    (i) Encounter diagnoses. The standard specified in Sec.  170.207(i) 
or, at a minimum, the version of the standard at Sec.  170.207(a)(3);
    (ii) Immunizations. The standard specified in Sec.  170.207(e)(2);
    (iii) Cognitive status;
    (iv) Functional status;
    (v) Ambulatory setting only. The reason for referral; and referring 
or transitioning provider's name and office contact information;
    (vi) Inpatient setting only. Discharge instructions; and
    (vii) Unique Device Identifier(s) for a patient's Implantable 
Device(s).
    (c) Clinical quality measures. (1) Clinical quality measures--
capture and export. (i) Capture. For each and every CQM for which the 
EHR technology is presented for certification, EHR technology must be 
able to electronically record all of the data identified in the 
standard specified at Sec.  170.204(c) that would be necessary to 
calculate each CQM. Data required for CQM exclusions or exceptions must 
be codified entries, which may include specific terms as defined by 
each CQM, or may include codified expressions of ``patient reason,'' 
``system reason,'' or ``medical reason.''
    (ii) Export. EHR technology must be able to electronically export a 
data file formatted in accordance with the standards specified at Sec.  
170.205(h) that includes all of the data captured for each and every 
CQM to which EHR technology was certified under paragraph (c)(1)(i) of 
this section.
    (2) Clinical quality measures--import and calculate. (i) Import. 
EHR technology must be able to electronically import a data file 
formatted in accordance with the standard specified at Sec.  170.205(h) 
and use such data to perform the capability specified in paragraph 
(c)(2)(ii) of this section. EHR technology presented for certification 
to all three of the certification criteria adopted in paragraphs (c)(1) 
through (3) of this section is not required to meet paragraph 
(c)(2)(i).
    (ii) Calculate. EHR technology must be able to electronically 
calculate each and every clinical quality measure for which it is 
presented for certification.
    (3) Clinical quality measures--electronic submission. Enable a user 
to electronically create a data file for transmission of clinical 
quality measurement data:
    (i) In accordance with the standards specified at Sec.  170.205(h) 
and (k); and
    (ii) That can be electronically accepted by CMS.
    (4) Clinical quality measures--patient population filtering. EHR 
technology must be able to record structured data for the purposes of 
being able to filter CQM results to create different patient population 
grouping by one or a combination of the following patient 
characteristics:
    (i) practice site and address;
    (ii) Tax Identification Number (TIN), National Provider Identifier 
(NPI), and TIN/PIN combination;
    (iii) Diagnosis;
    (iv) Primary and secondary health insurance, including 
identification of Medicare and Medicaid dual eligibles; and
    (v) Demographics including age, sex, preferred language, education 
level, and socioeconomic status.
    (d) Privacy and security. (1) Authentication, access control, and 
authorization. (i) Verify against a unique identifier(s) (e.g., 
username or number) that a person seeking access to electronic health 
information is the one claimed; and
    (ii) Establish the type of access to electronic health information 
a user is permitted based on the unique identifier(s) provided in 
paragraph (d)(1)(i) of this section, and the actions the user is 
permitted to perform with the EHR technology.
    (2) Auditable events and tamper-resistance. (i) Record actions. EHR 
technology must be able to:
    (A) Record actions related to electronic health information in 
accordance with the standard specified in Sec.  170.210(e)(1); and
    (B) Record the encryption status (enabled or disabled) of 
electronic health information locally stored on end-user devices by EHR 
technology in accordance with the standard specified in Sec.  
170.210(e)(3) unless the EHR technology prevents electronic health 
information from being locally stored on end-user devices (see 
170.314(d)(7) of this section).
    (ii) Default setting. EHR technology must be set by default to 
perform the capabilities specified in paragraph (d)(2)(i)(A) of this 
section and, where applicable, paragraph (d)(2)(i)(B).
    (iii) Prevent disabling. EHR technology must prevent all users from 
being able to disable the capabilities specified in paragraphs 
(d)(2)(i)(A) and (B) of this section through the EHR technology.
    (iv) Audit log protection. Actions and statuses recorded in 
accordance with paragraph (d)(2)(i) of this section must not be capable 
of being changed, overwritten, or deleted by the EHR technology.
    (v) Detection. EHR technology must be able to detect whether the 
audit log has been altered.
    (3) Audit report(s). Enable a user to create an audit report for a 
specific time period and to sort entries in the audit log according to 
each of the data specified in the standards at Sec.  170.210(e).
    (4) Amendments. Enable a user to electronically select the record 
affected by a patient's request for amendment and perform the 
capabilities specified in paragraphs (d)(4)(i) or (ii) of this section.
    (i) Accepted amendment. For an accepted amendment, append the 
amendment to the affected record or include a link that indicates the 
amendment's location.
    (ii) Denied amendment. For a denied amendment, at a minimum, append 
the request and denial of the request to the

[[Page 10944]]

affected record or include a link that indicates this information's 
location.
    (5) Automatic log-off. Prevent a user from gaining further access 
to an electronic session after a predetermined time of inactivity.
    (6) Emergency access. Permit an identified set of users to access 
electronic health information during an emergency.
    (7) End-user device encryption. Paragraph (d)(7)(i) or (ii) of this 
section must be met to satisfy this certification criterion. (i) EHR 
technology that is designed to locally store electronic health 
information on end-user devices must encrypt the electronic health 
information stored on such devices after use of EHR technology on those 
devices stops.
    (A) Electronic health information that is stored must be encrypted 
in accordance with the standard specified in Sec.  170.210(a)(1).
    (B) Default setting. EHR technology must be set by default to 
perform this capability and, unless this configuration cannot be 
disabled by any user, the ability to change the configuration must be 
restricted to a limited set of identified users.
    (ii) EHR technology is designed to prevent electronic health 
information from being locally stored on end-user devices after use of 
EHR technology on those devices stops.
    (8) Integrity. (i) Create a message digest in accordance with the 
standard specified in Sec.  170.210(c).
    (ii) Verify in accordance with the standard specified in Sec.  
170.210(c) upon receipt of electronically exchanged health information 
that such information has not been altered.
    (9) Accounting of disclosures. Record disclosures made for 
treatment, payment, and health care operations in accordance with the 
standard specified in Sec.  170.210(d).
    (e) Patient engagement. (1) View, download, and transmit to 3rd 
party. (i) Patients (and their authorized representatives) must be able 
to use EHR technology to view, download, and transmit their health 
information to a 3rd party in the manner specified below. Access to 
these capabilities must be online and through a secure channel that 
ensures all content is encrypted and integrity-protected in accordance 
with the standard for encryption and hashing algorithms specified at 
Sec.  170.210(f).
    (A) View. Patients (and their authorized representatives) must be 
able to use EHR technology to electronically view in accordance with 
the standard adopted at Sec.  170.204(a)(2), at a minimum, the 
following data:
    (1) The Common MU Data Set (which should be in their English (i.e., 
non-coded) representation if they associate with a vocabulary/code 
set).
    (2) Ambulatory setting only. Provider's name and office contact 
information.
    (3) Inpatient setting only. Admission and discharge dates and 
locations; discharge instructions; and reason(s) for hospitalization.
    (B) Download.
    (1) Patients (and their authorized representatives) must be able to 
use EHR technology to electronically download an ambulatory summary or 
inpatient summary (as applicable to the EHR technology setting for 
which certification is requested) in only human readable format, in 
only the format specified in accordance to the standard adopted at 
Sec.  170.205(a)(4), or in both formats.
    (2) When downloaded according to the standard adopted at Sec.  
170.205(a)(4), the ambulatory summary or inpatient summary must 
include, at a minimum, the following data (which, for the human 
readable version, should be in their English representation if they 
associate with a vocabulary/code set):
    (i) Ambulatory setting only. All of the data specified in paragraph 
(e)(1)(i)(A)(1) and (2) of this section and Unique Device Identifier(s) 
for a patient's implantable device(s).
    (ii) Inpatient setting only. All of the data specified in 
paragraphs (e)(1)(i)(A)(1) and (3) of this section and Unique Device 
Identifier(s) for a patient's Implantable Device(s).
    (3) Inpatient setting only. Patients (and their authorized 
representatives) must be able to electronically download transition of 
care/referral summaries that were created as a result of a transition 
of care (pursuant to the capability expressed in the certification 
criterion adopted at paragraph (b)(1) of this section).
    (C) Transmit to third party. Patients (and their authorized 
representatives) must be able to:
    (1) Enter a 3rd party destination of their choice to electronically 
transmit:
    (i) The ambulatory summary or inpatient summary (as applicable to 
the EHR technology setting for which certification is requested) 
created in paragraph (e)(1)(i)(B)(1) of this section in accordance with 
the standard specified in Sec.  170.202(a).
    (ii) Inpatient setting only. Electronically transmit transition of 
care/referral summaries (as a result of a transition of care/referral) 
selected by the patient (or their authorized representative) in 
accordance with the standard specified in Sec.  170.202(a).
    (2) Accomplish a transmission of their ambulatory summary or 
inpatient summary through a method that conforms to the standard 
specified at Sec.  170.202(e) and that leads to such summary being 
processed by a service that has implemented the standard specified in 
Sec.  170.202(a).
    (ii) Activity history log. (A) When electronic health information 
is viewed, downloaded, or transmitted to a third-party using the 
capabilities included in paragraphs (e)(1)(i)(A) through (C) of this 
section, the following information must be recorded and made accessible 
to the patient:
    (1) The action(s) (i.e., view, download, transmission) that 
occurred;
    (2) The date and time each action occurred in accordance with the 
standard specified at Sec.  170.210(g);
    (3) The user who took the action; and
    (4) The addressee to whom an ambulatory summary or inpatient 
summary was transmitted and whether that transmission was successful 
(or failed).
    (B) EHR technology presented for certification may demonstrate 
compliance with paragraph (e)(1)(ii)(A) of this section if it is also 
certified to the certification criterion adopted at Sec.  170.315(d)(2) 
and the information required to be recorded in paragraph (e)(1)(ii)(A) 
is accessible by the patient.
    (2) Ambulatory setting only--clinical summary. (i) Create. Enable a 
user to create a clinical summary for a patient in human readable 
format and formatted according to the standards adopted at Sec.  
170.205(a)(4).
    (ii) Customization. Enable a user to customize the data included in 
the clinical summary.
    (iii) Minimum data from which to select. EHR technology must permit 
a user to select, at a minimum, the following data when creating a 
clinical summary:
    (A) Common MU Data Set (which, for the human readable version, 
should be in their English representation if they associate with a 
vocabulary/code set);
    (B) Medications administered during the visit. At a minimum, the 
version of the standard specified in Sec.  170.207(d)(2);
    (C) Immunizations administered during the visit. At a minimum, the 
version of the standard specified in Sec.  170.207(e)(2);
    (D) Diagnostic tests pending and future scheduled tests. At a 
minimum, the version of the standard specified in Sec.  170.207(c)(2);
    (E) The provider's name and office contact information; date and 
location of visit; reason for visit; clinical instructions; future 
appointments;

[[Page 10945]]

referrals to other providers; and recommended patient decision aids; 
and
    (F) Unique Device Identifier(s) for a patient's Implantable 
Device(s).
    (3) Ambulatory setting only--secure messaging. Enable a user to 
electronically send messages to, and receive messages from, a patient 
in a manner that ensures:
    (i) Both the patient (or authorized representative) and EHR 
technology user are authenticated; and
    (ii) The message content is encrypted and integrity-protected in 
accordance with the standard for encryption and hashing algorithms 
specified at Sec.  170.210(f).
    (f) Public health. (1) Immunization information. Enable a user to 
electronically record, change, and access immunization information.
    (2) Transmission to immunization registries. EHR technology must be 
able to electronically create immunization information for electronic 
transmission in accordance with:
    (i) The standard and applicable implementation specifications 
specified in Sec.  170.205(e)(4); and
    (ii) At a minimum, the version of the standard specified in Sec.  
170.207(e)(2).
    (3) Transmission to public health agencies--syndromic surveillance. 
EHR technology must be able to electronically create syndrome-based 
public health surveillance information for electronic transmission in 
accordance with:
    (i) Ambulatory setting only. (A) The standard specified in Sec.  
170.205(d)(2), (d)(5), or (k).
    (B) Optional. The standard (and applicable implementation 
specifications) specified in Sec.  170.205(d)(4).
    (ii) Inpatient setting only. The standard (and applicable 
implementation specifications) specified in Sec.  170.205(d)(4).
    (4) Inpatient setting only--transmission of reportable laboratory 
tests and values/results. EHR technology must be able to electronically 
create reportable laboratory tests and values/results for electronic 
transmission in accordance with:
    (i) The standard (and applicable implementation specifications) 
specified in Sec.  170.205(g)(2); and
    (ii) At a minimum, the versions of the standards specified in Sec.  
170.207(a)(3) and (c)(2).
    (5) Ambulatory setting only--cancer case information. Enable a user 
to electronically record, change, and access cancer case information.
    (6) Ambulatory setting only--transmission to cancer registries. EHR 
technology must be able to electronically create cancer case 
information for electronic transmission in accordance with:
    (i) The standard (and applicable implementation specifications) 
specified in Sec.  170.205(i)(2); and
    (ii) At a minimum, the versions of the standards specified in Sec.  
170.207(a)(3) and (c)(2).
    (g) Utilization. (1) Automated numerator recording. For each 
meaningful use objective with a percentage-based measure, EHR 
technology must be able to create a report or file that enables a user 
to review the patients or actions that would make the patient or action 
eligible to be included in the measure's numerator. The information in 
the report or file created must be of sufficient detail such that it 
enables a user to match those patients or actions to meet the measure's 
denominator limitations when necessary to generate an accurate 
percentage.
    (2) Automated measure calculation. For each meaningful use 
objective with a percentage-based measure that is supported by a 
capability included in an EHR technology, electronically record the 
numerator and denominator and create a report including the numerator, 
denominator, and resulting percentage associated with each applicable 
meaningful use measure.
    (3) Safety-enhanced design. User-centered design processes must be 
applied to each capability an EHR technology includes that is specified 
in the following certification criteria: Sec.  170.315(a)(1) through 
(4), (8) through (10), and (18) and (b)(2) and (3).
    (4) Quality management system. For each capability that an EHR 
technology includes and for which that capability's certification is 
sought, the use of a Quality Management System (QMS) in the 
development, testing, implementation and maintenance of that capability 
must be identified.
    (i) If a single QMS was used for applicable capabilities, it would 
only need to be identified once.
    (ii) If different QMS were applied to specific capabilities, each 
QMS applied would need to be identified. This would include the 
application of a QMS to some capabilities and none to others.
    (iii) If no QMS was applied to all applicable capabilities such a 
response is acceptable to satisfy this certification criterion.
    (5) Non-percentage-based measures use report. (i) For each 
capability included in EHR technology that is also associated with a 
meaningful use objective and measure that is not percentage-based 
(except for the capabilities specified in Sec.  170.315(a)(12), (b)(1), 
and (d)) electronically record evidence that a user used or interacted 
with the capability and the date and time that such use or interaction 
occurred, in accordance with the standard specified at Sec.  
170.210(g).
    (ii) Enable a user to electronically create a report of the 
information recorded as part of paragraph (g)(5)(i) of this section for 
the user's identified Medicare or Medicaid EHR Incentive Program 
reporting period.
    (h) Transmission. (1) Transmit--Applicability Statement for Secure 
Health Transport. Enable health information to be electronically 
transmitted in accordance with the standard specified in Sec.  
170.202(a).
    (2) Transmit--Applicability Statement for Secure Health Transport 
and XDR/XDM for Direct Messaging. Enable health information to be 
electronically transmitted in accordance with the standard specified in 
Sec.  170.202(b).
    (3) Transmit--SOAP Transport and Security Specification and XDR/XDM 
for Direct Messaging. Enable health information to be electronically 
transmitted in accordance with the standard specified in Sec.  
170.202(c).
    (4) Transmit--Applicability Statement for Secure Health Transport 
and Delivery Notification in Direct. Enable health information to be 
electronically transmitted in accordance with the standard specified in 
Sec.  170.202(d).

Subpart D--[Removed and Reserved]

0
15. Remove and reserve subpart D, consisting of Sec. Sec.  170.400 
through 170.499.
0
16. Revise Sec.  170.501 to read as follows:


Sec.  170.501  Applicability.

    (a) This subpart establishes the processes that applicants for ONC-
ACB status must follow to be granted ONC-ACB status by the National 
Coordinator; the processes the National Coordinator will follow when 
assessing applicants and granting ONC-ACB status; the requirements that 
ONC-ACBs must follow to maintain ONC-ACB status; and the requirements 
of ONC-ACBs for certifying Complete EHRs, EHR Module(s), and other 
types of HIT in accordance with the applicable certification criteria 
adopted by the Secretary in subpart C of this part. It also establishes 
the processes accreditation organizations must follow to request 
approval from the National Coordinator and that the National 
Coordinator in turn will follow to approve an accreditation 
organization

[[Page 10946]]

under the ONC HIT Certification Program as well as certain ongoing 
responsibilities for an ONC-AA.
    (b) References to the term Complete EHR and Complete EHR 
certification throughout this subpart do not apply to certification in 
accordance with the 2015 Edition EHR certification criteria and any 
subsequent edition of certification criteria adopted by the Secretary 
under subpart C of this part.
0
17. Amend Sec.  170.502 by adding the definition ``Certification 
Package,'' to read as follows:
* * * * *
    Certification Package means an identified set of certification 
criteria adopted by the Secretary in subpart C of this part that 
represent a specific grouping of capabilities.
    (1) 2015 Edition Care Coordination Package includes, at a minimum, 
Sec.  170.315(b)(1) and (2).
    (2) 2015 Edition Patient Engagement Package includes, at a minimum, 
Sec.  170.315(e)(1) and (3).
* * * * *
0
18. In Sec.  170.503, revise paragraphs (b)(1) and (e)(2) to read as 
follows:


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

* * * * *
    (b) * * *
    (1) A detailed description of the accreditation organization's 
conformance to ISO/IEC17011 (incorporated by reference in Sec.  
170.599) and experience evaluating the conformance of certification 
bodies to ISO/IEC 17065.
* * * * *
    (e) * * *
    (2) Verify that the certification bodies it accredits and ONC-ACBs 
conform to, at a minimum:
    (i) For fiscal years 2014 and 2015, ISO/IEC Guide 65 (incorporated 
by reference in Sec.  170.599); and
    (ii) For fiscal year 2016 and subsequent years, ISO/IEC 17065.
* * * * *
0
19. In Sec.  170.523, republish the introductory text, revise paragraph 
(k)(1)(iii), and add paragraphs (k)(1)(iv) and (l) to read as follows:


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

    An ONC-ACB shall:
* * * * *
    (k) * * *
    (1) * * *
    (iii) Any additional types of costs that an EP, EH, or CAH would 
pay to implement the Complete EHR's or EHR Module's capabilities in 
order to attempt to meet meaningful use objectives and measures. 
Beginning with EHR technology certified to the 2015 Edition EHR 
certification criteria, any additional types of costs that an EP, EH, 
or CAH would pay to implement the MU EHR Module's capabilities in order 
to attempt to meet meaningful use objectives and measures. EHR 
technology self-developers are excluded from the requirements of this 
paragraph.
    (iv) If an EHR Module developer chooses to represent that an EHR 
Module satisfies a certification package(s) as defined in Sec.  170.502 
of this subpart, such representations must be accurate.
* * * * *
    (l) Display the ONC Certified HIT Certification and Design Mark on 
all certifications issued under the ONC HIT Certification Program in a 
manner that complies with the Criteria and Terms of Use for the ONC 
Certified HIT Certification and Design Mark, and ensure that use of the 
mark by HIT developers whose products are certified under the ONC HIT 
Certification Program is compliant with the Criteria and Terms of Use 
for the ONC Certified HIT Certification and Design Mark.
0
20. In Sec.  170.550, remove and reserve paragraph (e), revise 
paragraph (f) introductory text and (f)(1), redesignate paragraph (g) 
as (h), and add a new paragraph (g) to read as follows:


Sec.  170.550  EHR Module certification.

* * * * *
    (e) [Reserved]
    (f) When certifying an EHR Module to the 2014 Edition EHR 
certification criteria, an ONC-ACB must certify the EHR Module in 
accordance with the certification criteria at:
    (1) Section 170.314(g)(1) or (g)(2) if the EHR Module has 
capabilities presented for certification that would support a 
meaningful use objective with a percentage-based measure;
* * * * *
    (g) When certifying an EHR Module to the 2015 Edition EHR 
certification criteria, an ONC-ACB must certify the EHR Module in 
accordance with the certification criteria at:
    (1) Section 170.315(g)(1) or (g)(2) if the MU EHR Module has 
capabilities presented for certification that would support a 
meaningful use objective with a percentage-based measure;
    (2) Section 170.315(g)(3) if the EHR Module is presented for 
certification to one or more listed certification criteria in Sec.  
170.315(g)(3);
    (3) Section 170.315(g)(4); and
    (4) Section 170.315(g)(5) if the MU EHR Module has capabilities 
presented for certification that would support a meaningful use 
objective with a non-percentage-based measure.
* * * * *

    Dated: February 18, 2014.
Kathleen Sebelius,
Secretary.
[FR Doc. 2014-03959 Filed 2-21-14; 4:15 pm]
BILLING CODE 4150-45-P