[Federal Register Volume 77, Number 45 (Wednesday, March 7, 2012)]
[Proposed Rules]
[Pages 13832-13885]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2012-4430]



[[Page 13831]]

Vol. 77

Wednesday,

No. 45

March 7, 2012

Part III





Department of Health and Human Services





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





45 CFR Part 170





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

Federal Register / Vol. 77 , No. 45 / Wednesday, March 7, 2012 / 
Proposed Rules

[[Page 13832]]


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

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Office of the Secretary

45 CFR Part 170

RIN 0991-AB82


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

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

ACTION: Proposed rule.

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

SUMMARY: Under section 3004 of the Public Health Service Act, the 
Secretary of Health and Human Services is proposing to revise the 
initial set of standards, implementation specifications, and 
certification criteria adopted in an interim final rule published on 
January 13, 2010, and a subsequent final rule that was published on 
July 28, 2010, as well as to adopt new standards, implementation 
specifications, and certification criteria. The proposed new and 
revised certification criteria would establish the technical 
capabilities and specify the related standards and implementation 
specifications that Certified Electronic Health Record (EHR) Technology 
would need to include to, at a minimum, support the achievement of 
meaningful use by eligible professionals, eligible hospitals, and 
critical access hospitals under the Medicare and Medicaid EHR Incentive 
Programs beginning with the EHR reporting periods in fiscal year and 
calendar year 2014. This notice of proposed rulemaking also proposes 
revisions to the permanent certification program for health information 
technology, which includes changing the program's name.

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 May 7, 2012.

ADDRESSES: You may submit comments, identified by RIN 0991-AB82, 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.
    <bullet> 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.
    <bullet> Regular, Express, or Overnight Mail: Department of Health 
and Human Services, Office of the National Coordinator for Health 
Information Technology, Attention: 2014 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.
    <bullet> Hand Delivery or Courier: Office of the National 
Coordinator for Health Information Technology, Attention: 2014 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 and 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. 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://healthit.hhs.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).

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
CDS Clinical Decision Support
CEHRT Certified EHR Technology
CHPL Certified HIT Products List
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
HIPAA Health Insurance Portability and Accountability Act of 1996
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
ICD-9-CM International Classification of Diseases, 9th Revision, 
Clinical Modification
ICD-10-CM International Classification of Diseases, 10th Revision, 
Clinical Modification

[[Page 13833]]

ICD-10-PCS International Classification of Diseases, 10th Revision, 
Procedure Coding System
LOINC Logical Observation Identifiers Names and Codes
MU Meaningful Use
ONC Office of the National Coordinator of 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

I. Executive Summary
    A. Purpose of Regulatory Action
    B. Summary of Major Provisions
    1. Overview of the 2014 Edition EHR Certification Criteria
    2. Certified EHR Technology
    3. ONC HIT Certification Program
    C. Costs and Benefits
II. Background
    A. Statutory Basis
    1. Standards, Implementation Specifications, and Certification 
Criteria
    2. HIT Certification Programs
    B. Regulatory History
    1. Initial Set of Standards, Implementation Specifications, and 
Certification Criteria Interim Final and Final Rules
    2. Medicare and Medicaid EHR Incentive Programs Stage 1 Proposed 
and Final Rules
    3. HIT Certification Programs Proposed Rule and the Temporary 
and Permanent Certification Programs Final Rules
III. Provisions of the Proposed Rule affecting Standards, 
Implementation Specifications and Certification Criteria
    A. 2014 Edition EHR Certification Criteria
    1. Applicability
    2. Scope of a Certification Criterion for Certification
    3. Explanation and Revision of Terms Used in Certification 
Criteria
    4. New Certification Criteria
    a. Ambulatory and Inpatient Setting
    b. Ambulatory Setting
    c. Inpatient Setting
    5. Revised Certification Criteria
    a. Ambulatory and Inpatient Setting
    b. Ambulatory Setting
    c. Inpatient Setting
    6. Unchanged Certification Criteria
    a. Refinements to Unchanged Certification Criteria
    b. Unchanged Certification Criteria Without Refinements
    7. Gap Certification
    B. Redefining Certified EHR Technology and Related Terms
    1. Proposed Revisions to the Definition of Certified EHR 
Technology
    2. Base EHR
    3. Complete EHR
    4. Certifications Issued for Complete EHRs and EHR Modules
    5. Adaptations of Certified Complete EHRs or Certified EHR 
Modules
IV. Provisions of the Proposed Rule Affecting the Permanent 
Certification Program for HIT (``ONC HIT Certification Program'')
    A. Program Name Change
    B. ``Minimum Standards'' Code Sets
    C. Revisions to EHR Module Certification Requirements
    1. Privacy and Security Certification
    2. Certification to Certain New Certification Criteria
    D. ONC-ACB Reporting Requirements
    E. Continuation and Representation of Certified Status
    1. 2011 or 2014 Edition EHR Certification Criteria Compliant
    2. Updating a Certification
    3. Base EHR Representation
V. Request for Additional Comments
    A. Certification and Certification Criteria for Other Health 
Care Settings
    B. 2014 Edition EHR Accounting of Disclosures Certification 
Criterion
    C. Disability Status
    D. Data Portability
    E. EHR Technology Price Transparency
VI. Response to Comments
VII. Collection of Information Requirements
VIII. Regulatory Impact Statement
    A. Statement of Need
    B. Overall Impact
    1. Executive Orders 12866 and 13563--Regulatory Planning and 
Review Analysis
    a. Costs
    i. Development and Preparation Costs for 2014 Edition EHR 
Certification Criteria
    ii. Overall Development and Preparation Costs Over a 3-Year 
Period
    iii. Costs for Reporting Test Results Hyperlinks
    b. Benefits
    2. Regulatory Flexibility Act Analysis
    3. Executive Order 13132--Federalism
    4. Unfunded Mandates Reform Act of 1995

Regulation Text

I. Executive Summary

A. Purpose of Regulatory Action

    The HIT Standards Committee (HITSC) issued recommendations for 
standards, implementation specifications, and certification criteria to 
the National Coordinator for Health Information Technology (the 
National Coordinator) on September 28, 2011 and October 21, 2011. In 
fulfilling his duties under sections 3001(c)(1)(A) and (B) of the 
Public Health Service Act (PHSA), the National Coordinator reviewed the 
recommendations made by the HITSC, endorsed certain standards, 
implementation specifications, and certification criteria, and reported 
his determinations to the Secretary for consideration. This proposed 
rule serves as the Secretary's publication of her determinations 
regarding the standards, implementation specifications, and 
certification criteria endorsed by the National Coordinator, as 
required by section 3004(a)(3) of the PHSA.
    The adoption by the Secretary, under sections 3004(a)(3) and 
3004(b)(3) of the PHSA, of the standards, implementation 
specifications, and certification criteria proposed in this rule would 
establish the technical capabilities that electronic health record 
(EHR) technology must include to be certified. EHR technology certified 
to these standards, implementation specifications, and certification 
criteria makes it possible for eligible professionals (EPs), eligible 
hospitals (EHs), and critical access hospitals (CAHs) to adopt 
Certified EHR Technology (CEHRT) and subsequently attempt to 
demonstrate its meaningful use (MU) under the Medicare and Medicaid EHR 
Incentive Programs (the ``EHR Incentive Programs'') beginning with the 
EHR reporting periods in Federal fiscal year (FY) 2014 for EHs and CAHs 
and calendar year (CY) 2014 for EPs (hereafter referred to as ``FY/CY 
2014'').
    Consistent with Executive Order 13563, we have undertaken a 
retrospective review of our regulations. The proposed rule introduces 
multiple means for reducing regulatory burden and increasing regulatory 
flexibility for stakeholders, including proposed changes to current 
regulatory requirements and approaches.

B. Summary of Major Provisions

1. Overview of the 2014 Edition EHR Certification Criteria
    We propose to adopt certification criteria that will support the 
proposed changes to the EHR Incentive Programs, including the new and 
revised objectives and measures for Stages 1 and 2 of MU proposed by 
CMS. The certification criteria we propose for adoption would also 
enhance care coordination, patient engagement, and the security, 
safety, and efficacy of EHR technology. For clarity, we refer to the 
certification criteria proposed for adoption as the 2014 Edition EHR 
certification criteria and the currently adopted certification criteria 
as the 2011 Edition EHR certification criteria. To permit efficient 
certification methods and reduce regulatory burden, we have identified 
those certification criteria that we propose to include in the 2014 
Edition EHR certification criteria that include unchanged capabilities 
that were also included in the 2011 Edition EHR certification criteria. 
For EHR technology previously certified to the 2011 Edition EHR 
certification criteria, this would permit, where applicable, the use of 
prior test results for certification to the 2014 Edition EHR 
certification criteria (see the discussion of ``gap certification'' in 
section III.A.7 of this preamble).
2. Certified EHR Technology
    Since the publication of the Standards and Certification Criteria 
final rule in July 2010, HHS has received significant

[[Page 13834]]

feedback from stakeholders suggesting that we change our CEHRT policy 
(and definition) to one that would provide EPs, EHs, and CAHs the 
flexibility to have only the EHR technology they need to demonstrate 
MU. Consistent with stakeholder feedback and recommendations received 
from the HITSC, this rule proposes to revise the definition of CEHRT. 
Of most significance, beginning with the EHR reporting periods in FY/CY 
2014, we are proposing a revised definition of CEHRT that would provide 
more flexibility for EPs, EHs, and CAHs. In sum, in order to have EHR 
technology that meets the definition of CEHRT for FY and CY 2014 and 
subsequent years, EPs, EHs, and CAHs would be required to have a Base 
EHR (EHR technology that includes fundamental capabilities all 
providers would need to have) as well as the additional EHR technology 
necessary to meet the MU objectives and measures for the stage of MU 
that they seek to meet and to capture, calculate, and report clinical 
quality measures. We further discuss this proposal, including the 
concept of a ``Base EHR'' in section III.C (Redefining Certified EHR 
Technology and Related Terms).
3. ONC HIT Certification Program
    This rule proposes revisions to the permanent certification program 
which aim to increase regulatory clarity and transparency, reduce 
regulatory burden, and add flexibility for the health information 
technology (HIT) community. One of these revisions includes changing 
the permanent certification program title to the ``ONC HIT 
Certification Program,'' which provides clearer attribution to the 
agency responsible for the program and an appropriate description of 
the program's scope, covering both current and potential future 
activities. The rule also proposes to revise the process for permitting 
the use of newer versions of ``minimum standard'' code sets. The 
proposed new approach seeks to reduce regulatory complexity and burden 
by providing the industry with the flexibility to quickly utilize newer 
versions of adopted ``minimum standard'' code sets. The rule proposes 
to modify the certification processes ONC-Authorized Certification 
Bodies (ONC-ACBs) would need to follow for certifying EHR Modules as a 
means of providing clear implementation direction and compliance with 
proposed new certification criteria, and also proposes to reduce 
regulatory burden by eliminating the certification requirement that 
every EHR Module be certified to the ``privacy and security'' 
certification criteria. Instead, the privacy and security capabilities 
are included in the Base EHR that must be a part of every EP's, EH's, 
and CAH's CEHRT. To increase clarity for the HIT market, we propose 
methods for clearly representing certified Complete EHRs and certified 
EHR Modules, including the representation of a ``Base EHR.'' Finally, 
we propose to require that test results used for the certification of 
EHR technology be available to the public in an effort to increase 
transparency around the certification process.

C. Costs and Benefits

    We determined that this proposed rule is not an economically 
significant rule as its overall costs will be less than $100 million 
per 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 (i.e., 
Complete EHRs and EHR Modules) to be tested and certified in accordance 
with the proposed certification criteria are represented in monetary 
terms in Table 1 below. We believe that there will be market pressures 
to have certified Complete EHRs and certified EHR Modules ready and 
available prior to when EPs, EHs, and CAHs must meet the proposed 
revised definition of CEHRT for FY/CY 2014. We assume this factor will 
cause a greater number of developers to prepare EHR technology for 
testing and certification towards the end of 2012 and throughout 2013, 
rather than in 2014. As a result, we believe, as represented in Table 
1, that the costs attributable to this proposed rule will be 
distributed as follows: 40% for 2012, 50% for 2013, and 10% for 2014. 
The dollar amounts expressed in Table 1 are expressed in 2012 dollars.
    There are multiple potential benefits from the adoption of the 
proposed certification criteria in this rule. Foremost, EHR technology 
certified to the proposed certification criteria would be capable of 
supporting EPs, EHs, and CAHs' attempts to demonstrate MU under the EHR 
Incentive Programs. The certification criteria also promote enhanced 
interoperability, functionality, utility, and security of EHR 
technology through the capabilities they include and the standards they 
require EHR technology to meet for certification. Proposals such as the 
revised definition of CEHRT, the availability of gap certification, and 
the proposed revisions to the permanent certification program, will, as 
noted, increase regulatory clarity, improve transparency, and add 
flexibility, while also reducing the regulatory burden on the HIT 
industry. Finally, we believe the proposals in this rule will support 
other initiatives, such as the Partnership for Patients.

   Table 1--Estimated Costs of the Proposed Rule: Distributed Total Preparation Costs for Complete EHR and EHR
                                Module Developers (3-year period)--Totals Rounded
----------------------------------------------------------------------------------------------------------------
                                                                                    Total high     Total average
                      Year                         Ratio percent  Total low cost   cost estimate   cost estimate
                                                                  estimate  ($M)       ($M)            ($M)
----------------------------------------------------------------------------------------------------------------
2012............................................              40           36.80           95.01           65.91
2013............................................              50           46.01          118.76           82.38
2014............................................              10            9.20           23.75           16.48
                                                 ---------------------------------------------------------------
    3-Year Totals...............................  ..............           92.01          237.52          167.53
----------------------------------------------------------------------------------------------------------------

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

[[Page 13835]]

1. Standards, Implementation Specifications, and Certification Criteria
    With the passage of the HITECH Act, two new Federal advisory 
committees were established, 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 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, while the HITSC is 
responsible for 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.''
    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. Initial Set of Standards, Implementation Specifications, and 
Certification Criteria Interim Final and Final 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 MU Stage 1. 
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) (the ``S&CC July 
2010 final rule''). On October 13, 2010, an interim final rule with a 
request for comment was issued to remove certain implementation 
specifications related to public health surveillance that had been 
previously adopted in the S&CC July 2010 final rule (75 FR 62686).
    The standards, implementation specifications, and certification 
criteria adopted by the Secretary in the S&CC July 2010 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).
2. Medicare and Medicaid EHR Incentive Programs Stage 1 Proposed and 
Final Rules
    On January 13, 2010, CMS published the EHR Incentive Programs Stage 
1 proposed rule (75 FR 1844). The rule proposed a definition for Stage 
1 MU of CEHRT 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 S&CC July 2010 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.
3. HIT Certification Programs Proposed Rule and the Temporary and 
Permanent Certification Programs Final 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

[[Page 13836]]

Permanent Certification Program final rule'').

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

    In the S&CC July 2010 final rule, the Secretary adopted 
certification criteria in title 45, part 170, Sec. Sec.  170.302, 
170.304, and 170.306 of the Code of Federal Regulations. To make a 
clear distinction between these previously adopted certification 
criteria and the ones discussed in this proposed rule, we will refer to 
the certification criteria adopted in the S&CC July 2010 final rule and 
included in Sec. Sec.  170.302, 170.304, and 170.306 collectively as 
the ``2011 Edition EHR certification criteria'' and propose to revise 
Sec.  170.102 to add this definition.

A. 2014 Edition EHR Certification Criteria

    This rule proposes new, revised, and unchanged certification 
criteria that would establish the technical capabilities and specify 
the related standards and implementation specifications that CEHRT 
would need to include to, at a minimum, support the achievement of MU 
by EPs, EHs, and CAHs under the EHR Incentive Programs beginning with 
the EHR reporting periods in FY/CY 2014. We refer to these new, 
revised, and unchanged certification criteria as the ``2014 Edition EHR 
certification criteria'' and propose to add this term and its 
definition to Sec.  170.102. Additionally, we propose to codify the 
2014 Edition EHR certification criteria in section 170.314 to set them 
apart and make it easier for stakeholders to quickly determine which 
certification criteria would be required beginning with the EHR 
reporting periods that start in FY/CY 2014. This approach, coupled with 
our reference to the 2011 Edition EHR certification criteria, should 
eliminate any ambiguity and provide a clear distinction between the 
certification criteria that are part of the 2011 Edition EHR 
certification criteria and those we propose to include in the 2014 
Edition EHR certification criteria. Further, we believe the inclusion 
of all 2014 Edition EHR certification criteria in one regulatory 
section will simplify the regulatory framework for stakeholders.
    Many of the certification criteria that we propose in this rule are 
intended to support the MU objectives and measures proposed in the CMS 
Medicare and Medicaid EHR Incentive Programs Stage 2 proposed rule 
(Stage 2 proposed rule) \1\ as well as the reporting of MU objectives 
and measures and clinical quality measures (CQMs) to CMS. To the extent 
CMS may change (e.g., add, revise, or remove) MU objectives, measures, 
or reporting requirements in a final rule, we may also find it 
necessary or appropriate to change proposed supporting certification 
criteria. Commenters recommending changes to the proposed MU objectives 
and measures, CQMs, or reporting requirements should consider whether 
changes to the certification criteria would also be needed and offer 
those suggested changes. Similarly, commenters should consider and 
specify whether any of their suggested revisions to the proposed 
certification criteria would impact the proposals in CMS's Stage 2 
proposed rule.
---------------------------------------------------------------------------

    \1\ When we refer to CMS's Medicare and Medicaid EHR Incentive 
Programs Stage 2 proposed rule, we are referring to the NPRM 
published elsewhere in this issue of the Federal Register.
---------------------------------------------------------------------------

    We discuss the new, revised, and unchanged certification criteria 
that we propose to adopt as the 2014 Edition EHR certification criteria 
in sections A.4 through A.6 below. We specify where the proposed 
certification criteria would be included in Sec.  170.314. We include a 
table at the beginning of the discussion of each certification 
criterion or criteria that specifies the MU objective that the proposed 
2014 Edition EHR certification criterion or criteria and associated 
standards and implementation specifications support. The objective 
cited is either a proposed Stage 1 or Stage 2 objective that would be 
effective for the EHR reporting periods in FY/CY 2014. We provide this 
frame of reference because we propose that beginning in FY/CY 2014 EHR 
technology would need to be certified to the 2014 Edition EHR 
certification criteria to meet the definition of CEHRT and the table 
permits commenters to easily associate the certification criterion with 
the MU objective it supports. We provide the rationale for the proposed 
certification criteria, including citing the recommendations of the 
HITPC and HITSC, where appropriate. Last, in certain instances, we 
specifically request comment on the maturity and industry-acceptance of 
various standards and implementation specifications.
1. Applicability
    Section 170.300 establishes the applicability of subpart C--
Certification Criteria for Health Information Technology. Section 
170.300(a) establishes the applicability of the adopted certification 
criteria to the testing and certification of Complete EHRs and EHR 
Modules. Section 170.300(b) specifies that when a certification 
criterion refers to two or more standards as alternatives, the use of 
at least one of the alternative standards will be considered compliant. 
Section 170.300(c) specifies that Complete EHRs and EHR Modules are not 
required to be compliant with certification criteria that are 
designated as optional. We propose to revise Sec.  170.300 to reflect 
our proposed regulatory structure for the 2014 Edition EHR 
certification criteria. We propose to revise paragraph (c) to add that 
Complete EHRs and EHR Modules are also not required to be certified to 
specific capabilities within a certification criterion that are 
designated as optional. We also propose to add a paragraph (d) that 
would clarify which certification criteria or specific capabilities 
within a certification criterion included in Sec.  170.314 have general 
applicability (i.e., apply to both ambulatory and inpatient settings) 
or apply only to an inpatient setting or an ambulatory setting.
2. Scope of a Certification Criterion for Certification
    In the certification programs final rules (75 FR 36176, 76 FR 1290-
91) and the S&CC July 2010 final rule (75 FR 44622), we clarified that 
a single certification criterion would encompass all of the specific 
capabilities referenced below the first paragraph level. As an example 
in the Permanent Certification Program final rule, we stated that the 
certification criterion at 45 CFR 170.302, paragraph ``(f)'' (the first 
paragraph level) identifies that the certification criterion relates to 
recording and charting vital signs. The certification criterion 
includes three specific capabilities at (f)(1), (2), and (3) (the 
second paragraph level): The ability to record, modify, and retrieve 
patients' vital signs; the ability to calculate body mass index (BMI); 
and the ability to plot and display growth charts. We stated that we 
viewed the entire set of specific capabilities required by paragraph 
``(f)'' (namely, (f)(1), (2), and (3)) as one certification criterion, 
and that the specific capability to calculate BMI would not be 
equivalent to one certification criterion.
    Based on our proposal to codify all the 2014 Edition EHR 
certification criteria in Sec.  170.314, we are clarifying that 
certification to the certification criteria at Sec.  170.314 would 
occur at the second paragraph level of the regulatory section. The 
first paragraph level in Sec.  170.314 would be used to organize the 
certification criteria into categories.

[[Page 13837]]

These categories would be: Clinical (Sec.  170.314(a)); care 
coordination (Sec.  170.314(b)); clinical quality measures (Sec.  
170.314(c)); privacy and security (Sec.  170.314(d)); patient 
engagement (Sec.  170.314(e)); public health (Sec.  170.314(f)); and 
utilization (Sec.  170.314(g)). Thus, for this proposed rule, a 
certification criterion in Sec.  170.314 would be at the second 
paragraph level and would encompass all of the specific capabilities in 
the paragraph levels below with, as noted in our discussion of 
``applicability,'' an indication if the certification criterion or the 
specific capabilities within the criterion only apply to one setting 
(ambulatory or inpatient). For example, we propose to adopt the revised 
certification criterion for demographics at Sec.  170.314(a)(3) (second 
paragraph level). The certification criterion includes two specific 
capabilities at (3)(i) and (ii) (third paragraph level): ``(i)'' enable 
a user to electronically record, change, and access patient demographic 
data including preferred language, gender, race, ethnicity, and date of 
birth (in accordance with the specified standards for race, ethnicity, 
and preferred language (Sec.  170.314(3)(i)(A) and (B)); and, ``(ii)'' 
for the inpatient setting only, enable a user to electronically record, 
change, and access preliminary cause of death in the event of mortality 
in accordance with the standard specified in Sec.  170.207(k). 
Consequently, to meet the proposed certification criterion for 
demographics, for example, EHR technology designed for the inpatient 
setting would need to meet Sec.  170.314(a)(3)(i)(A) and (B) and (ii), 
while EHR technology designed for the ambulatory setting would only 
need to meet (3)(i)(A) and (B) because the capability at (3)(ii) only 
applies to the inpatient setting.
3. Explanation and Revision of Terms Used in Certification Criteria
    Certain terms are repeatedly used in the proposed 2014 Edition EHR 
certification criteria. Based on our experience and stakeholder 
feedback related to how terms in the 2011 Edition EHR certification 
criteria have been interpreted, we have determined that it is necessary 
in certain cases to select different terms. The following is a list of 
terms we repeatedly use in the proposed 2014 Edition EHR certification 
criteria and the intended meaning for each term.
    ``User'' is used to mean a health care professional or his or her 
office staff or a software program or service that would interact 
directly with the CEHRT. This is essentially the same description that 
we gave to ``user'' in the S&CC July 2010 final rule (75 FR 44598). We 
further clarify that, unless expressly stated otherwise, ``user'' does 
not mean a patient.
    ``Record'' is used to mean the ability to capture and store 
information in EHR technology. We consider this meaning complementary 
to and consistent with related terms, namely ``change'' and ``access,'' 
and their associated capabilities.
    ``Change'' is used to mean the ability to alter or edit information 
previously recorded in EHR technology. We are replacing the term 
``modify'' used in the 2011 Edition EHR certification criteria with 
``change.'' Although we interpret both terms to have essentially the 
same meaning, we believe ``change'' connotes a more plain language 
meaning as recommended by plainlanguage.gov.\2\ In certification 
criteria in which this term is used, we do not intend for it to be 
interpreted to mean that information previously recorded would be able 
to be changed without the retention of prior value(s). Rather, a change 
must be retained as an audited event and in a viewable format that 
identifies the changed information in a patient's record (similar to 
how one might see changes represented in a word-processing 
application). How such changes are displayed is a design decision left 
to EHR technology developers.
---------------------------------------------------------------------------

    \2\ http://www.plainlanguage.gov/howto/wordsuggestions/simplewords.cfm#lm.
---------------------------------------------------------------------------

    ``Access'' is used to mean the ability to examine or review 
information in or through EHR technology. We are proposing to replace 
the term ``retrieve'' used in the 2011 Edition EHR certification 
criteria with ``access'' because we believe it is clearer and more 
accurately expresses the capability we intend for EHR technology to 
include. We note that some stakeholders had interpreted ``retrieve'' to 
suggest that the EHR technology also needed to be able to obtain data 
from external sources. Nevertheless, we interpret both ``access'' and 
``retrieve'' to have essentially the same meaning, but note that 
``access'' should not be interpreted to include necessarily the 
capability of obtaining or transferring the data from an external 
source.
    ``Incorporate'' is used to mean to electronically import, 
attribute, associate, or link information in EHR technology. With the 
exception of import, we previously used these terms to describe the 
``incorporate'' capability included in certification criteria as 
illustrated by the capability specified at Sec.  170.302(h)(3). We only 
propose to revise its unique meaning for the 2014 Edition EHR 
certification criteria and the purposes of certification to account for 
the ability to electronically import information.
    ``Create'' is used to mean to electronically produce or generate 
information. We are proposing to replace the term ``generate'' used in 
the 2011 Edition EHR certification criteria with ``create.'' We believe 
``create'' is clearer and is a better word choice than generate from a 
plain language perspective.
    ``Transmit'' is used to mean to send from one point to another.
4. New Certification Criteria
    In the Permanent Certification Program final rule (76 FR 1302), we 
described new certification criteria as those that specify capabilities 
for which the Secretary has not previously adopted certification 
criteria. We further stated that new certification criteria also 
include certification criteria that were previously adopted for 
Complete EHRs or EHR Modules designed for a specific setting and are 
subsequently adopted for Complete EHRs or EHR Modules designed for a 
different setting (for example, if the Secretary previously adopted a 
certification criterion only for Complete EHRs or EHR Modules designed 
for an ambulatory setting and then subsequently adopts that 
certification criterion for Complete EHRs or EHR Modules designed for 
an inpatient setting). Based on our experience trying to appropriately 
categorize the certification criteria we propose to be part of the 2014 
Edition EHR certification criteria, we have determined that our 
description of new certification criteria needs to be clarified. 
Accordingly, we list below the factors that we would consider when 
determining whether a certification criterion is ``new:''
    <bullet> The certification criterion only specifies capabilities 
that have never been included in previously adopted certification 
criteria; or
    <bullet> The certification criterion was previously adopted as 
``mandatory'' for a particular setting and subsequently adopted as 
``mandatory'' or ``optional'' for a different setting.
    We propose to adopt new certification criteria that will support 
new MU objectives and associated measures, the reporting of MU 
measures, and will enable EHR technology to enhance patient engagement. 
Some of the new criteria would apply to both ambulatory and inpatient 
settings, while some certification criteria would only apply to one of 
the settings or would be new for a particular setting.

[[Page 13838]]

a. Ambulatory and Inpatient Setting
    We propose to adopt 8 certification criteria that would be new 
certification criteria for both the ambulatory and inpatient settings.

    <bullet> Electronic notes

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Record electronic notes in patient records.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(a)(9) (Electronic notes)
------------------------------------------------------------------------

    The HITSC recommended a certification criterion similar to the 2014 
Edition EHR certification criterion we propose at Sec.  170.314(a)(9) 
(with specific reference to ``physician, physician assistant, or nurse 
practitioner'' electronic notes) to support the MU objective and 
measure recommended by the HITPC. CMS has not proposed the MU objective 
and measure for Stage 2, but has requested public comment on whether 
the objective and measure should be incorporated into Stage 2.
    Consistent with our discussion in the preamble section titled 
``Explanation and Revision of Terms Used in Certification Criteria,'' 
we have replaced the terms ``modify'' and ``retrieve'' in the 
recommended criterion with ``change'' and ``access,'' respectively. 
Additionally, we are providing the following clarifications for the 
electronic ``search'' capability. ``Search'' means the ability to 
search free text and data fields of electronic notes. It also means the 
ability to search the notes that any licensed health care professional 
has included within the EHR technology, including the ability to search 
for information across separate notes rather than just within notes. We 
believe that this certification criterion would encompass the necessary 
capabilities to support the performance of the MU objective and measure 
as discussed in the MU Stage 2 proposed rule.

    <bullet> Imaging

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Imaging results and information are accessible through Certified EHR
 Technology.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(a)(12) (Imaging)
------------------------------------------------------------------------

    We propose to adopt the 2014 Edition EHR certification criterion at 
Sec.  170.314(a)(12) to support the performance of the proposed MU 
objective and measure. We clarify that the phrase ``immediate 
electronic access'' is intended to mean that a user should be able to 
electronically access images and their narrative interpretations 
directly and without, for example, having to login to a separate 
electronic system or repository. This access could be provided by 
multiple means, including, but not limited to, ``single sign-on'' and 
``secure identity parameter passing.'' We also note that there are data 
format standards for the transmission of imaging data (Digital Imaging 
and Communications in Medicine (DICOM)) that we reviewed for this 
certification criterion, but do not believe that the adoption of these 
standards is necessary to enable users to electronically access images 
and their narrative interpretations, as required by this certification 
criterion. We request public comment regarding whether there are 
appropriate and necessary standards and implementation specifications 
for this certification criterion.

    <bullet> Family health history

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Record patient family health history as structured data.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(a)(13) (Family health history)
------------------------------------------------------------------------

    We propose to adopt the 2014 Edition EHR certification criterion at 
Sec.  170.314(a)(13) to support the performance of the proposed MU 
objective and measure. In defining family health history, this 
capability requires, at minimum, the ability to electronically record, 
change, and access the health history of a patient's first-degree 
relatives. As proposed in the Stage 2 proposed rule, a first degree 
relative is a family member who shares about 50 percent of their genes 
with a particular individual in a family (first degree relatives 
include parents, offspring, and siblings).
    We considered adopting specific standards for this certification 
criterion, including the HL7 Pedigree standard \3\ and the use of 
Systematized Nomenclature of Medicine--Clinical Terms (SNOMED-
CT[supreg]) \4\ terms for familial conditions. We seek comments on the 
maturity and breadth of industry adoption of the HL7 Pedigree standard 
format for export and import of family health history and the use of 
SNOMED-CT[supreg] terms for familial conditions and their inclusion, 
where appropriate, on a patient's problem list. We also note that the 
Surgeon General has produced a tool that can capture, save, and manage 
family health histories using standard vocabularies and can export the 
data in eXtensible Markup Language (XML) format.\5\ We seek comments on 
the maturity and breadth of adoption of this tool and its export 
format.
---------------------------------------------------------------------------

    \3\ http://www.hl7.org/implement/standards/product_brief.cfm?product_id=8.
    \4\ http://www.nlm.nih.gov/research/umls/Snomed/snomed_main.html.
    \5\ https://familyhistory.hhs.gov.

    <bullet> Amendments

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Protect electronic health information created or maintained by the
 Certified EHR Technology through the implementation of appropriate
 technical capabilities.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(d)(4) (Amendments)
------------------------------------------------------------------------

    We propose to adopt the 2014 Edition EHR certification criterion at 
Sec.  170.314(d)(4). Based on HITPC recommendations submitted to the 
National Coordinator on July 25, 2011, the HITSC recommended two 
versions of a draft 2014 Edition EHR certification criterion for 
amendments. As part of its recommendation, the HITPC (based on the work 
done by its Privacy and Security Tiger Team) noted that the technical 
capabilities included in a certification criterion should be ``kept as 
simple as possible and evolve over time to greater complexity, 
including potentially greater standardization and automation.'' The 
HITPC also recommended that this certification criterion be adopted to 
assist stakeholders by providing them with some of the technical tools 
to comply with parts of the Health Insurance Portability and 
Accountability Act of 1996 (HIPAA) Privacy Rule requirements specified 
at 45 CFR 164.526. In addition, the HITPC considered issues related to 
``data integrity and quality when a clinician corrects errors that were 
not reported by the patient or needs to communicate updates to a 
patient's information.'' We agree with the HITPC and HITSC 
recommendations, including that a certification criterion should be 
adopted that provides some of the basic technical tools necessary to 
comply with the HIPAA Privacy Rule. The proposed certification 
criterion does not address all of the requirements specified at 45 CFR 
164.526 and we note that EHR technology certification is not a 
substitute for, or guarantee of, HIPAA Privacy Rule compliance. 
However, we believe that by adopting the proposed certification 
criterion, EPs, EHs, and CAHs would be provided some of the basic 
technical tools for compliance with 45 CFR 164.526.
    We specifically request comment on whether EHR technology should be

[[Page 13839]]

required to be capable of appending patient supplied information in 
both free text and scanned format or only one or these methods to be 
certified to this proposed certification criteria.

    <bullet> View, download, and transmit to 3rd party

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
EPs
Provide patients 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 the ability to view online, download, and transmit
 information about a hospital admission.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(e)(1) (View, download, and transmit to 3rd party)
 
Standards
Sec.   170.204(a) (Web Content Accessibility Guidelines (WCAG) 2.0,
 Level AA Conformance); Sec.   170.205(a)(3) (Consolidated CDA); Sec.
 170.205(j) (DICOM PS 3-2011); Sec.   170.207(f) (OMB standards for the
 classification of federal data on race and ethnicity); Sec.
 170.207(j) (ISO 639-1:2002 (preferred language)); Sec.   170.207(l)
 (smoking status types); Sec.   170.207(a)(3) (SNOMED-CT[supreg]
 International Release January 2012); Sec.   170.207(m) (ICD-10-CM);
 Sec.   170.207(b)(2) (HCPCS and CPT-4) or Sec.   170.207(b)(3) (ICD-10-
 PCS); Sec.   170.207(g) (LOINC version 2.38); Sec.   170.207(h) (RxNorm
 February 6, 2012 Release); Sec.   170.202(a)(1) (Applicability
 Statement for Secure Health Transport) and Sec.   170.202(a)(2) (XDR
 and XDM for Direct Messaging); and Sec.   170.210(g) (synchronized
 clocks)
------------------------------------------------------------------------

    The HITPC issued a MU recommendation that patients (or their 
authorized representative(s)) be able to view and download their health 
information online (i.e., Internet/Web-based). The HITPC recommended 
that this objective should replace or subsume the objectives for 
providing patients with timely electronic access to their health 
information and providing patients with an electronic copy of their 
health information and hospital discharge instructions upon request. 
Consistent with these recommendations, the HITSC recommended a 
certification criterion that framed the capabilities EHR technology 
would need to include to support this new objective and that, for the 
2014 Edition EHR certification criteria, the criterion should replace 
the certification criteria previously adopted at Sec. Sec.  170.304(f), 
170.304(g), 170.306(d), and 170.306(e) because the new criterion 
encompassed the data elements required by these capabilities and was 
seen as a more efficient and effective means for patients to access 
their health information. We have made several refinements to the 
recommended certification criterion, while maintaining the critical 
elements recommended by the HITSC.
    In addition to the view and download capabilities recommended by 
the HITSC, we propose to include a third specific capability in this 
certification criterion--the ability to transmit a summary care record 
to a third party. Given that this objective is about making health 
information more accessible to patients and their caregivers, we 
believe that patients should have another option available to access 
their health information. We also believe that in certain cases 
patients may want to direct their health care provider(s) to transmit a 
copy of their electronic health information to another entity the 
patient might use for centralizing their health information (e.g., a 
personal health record). This additional capability is consistent with, 
and supports, the right of access standard at 45 CFR 164.524 of the 
HIPAA Privacy Rule as expanded by section 13405(e) of the HITECH Act 
with respect to covered entities that use or maintain an EHR on an 
individual. Section 13405(e) states that, in applying 45 CFR 164.524, 
an ``individual shall have a right to obtain from [a HIPAA] covered 
entity a copy of such information in an electronic format and, if the 
individual chooses, to direct the covered entity to transmit such copy 
directly to an entity or person designated by the individual* * *.'' 
Coupled with this addition, we have proposed that EHR technology would 
need to be capable of transmitting a summary care record according to 
both transport standards we propose to adopt. These transport standards 
include the two transport specifications developed under the Direct 
Project \6\: (1) Applicability Statement for Secure Health Transport 
\7\ and (2) External Data Representation (XDR) and Cross-Enterprise 
Document Media Interchange (XDM) for Direct Messaging.\8\ The 
Applicability Statement for Secure Health Transport specification 
describes how electronic health information can be securely transported 
using simple mail transport protocol (SMTP), Secure/Multipurpose 
Internet Mail Extensions (S/MIME), and X.509 certificates. The XDR and 
XDM for Direct Messaging specification describes the use of XDR and XDM 
as a means to transport electronic health information and serve as a 
bridge between entities using/following Web services and SMTP transport 
methods. We believe that these transport standards are ideal for these 
purposes and will make it possible for patients to transmit a copy of 
their summary care record to the destination of their choice. 
Additionally, because we have proposed requiring the capability to 
perform transmissions in accordance with these transport standards 
(which provide for encryption and integrity protection) in this 
criterion and in the ``transitions of care--create and transmit summary 
care record'' certification criterion, we have determined that it is 
not necessary to include in the 2014 Edition EHR certification criteria 
the ``encrypting when exchanging'' certification criterion adopted in 
the 2011 Edition EHR certification criteria (Sec.  170.302(v)). We 
believe that to include the 2011 Edition EHR certification criterion 
would be redundant and that our proposed approach more explicitly ties 
security to a particular transmission.
---------------------------------------------------------------------------

    \6\ http://wiki.directproject.org/Documentation+Library.
    \7\ http://wiki.directproject.org/Applicability+Statement+for+Secure+Health+Transport.
    \8\ http://wiki.directproject.org/XDR+and+XDM+for+Direct+Messaging.
---------------------------------------------------------------------------

    At the recommendation of the HITSC, this proposed certification 
criterion requires that EHR technology certified to this criterion 
include a ``patient accessible log'' to track the use of the view, 
download, and transmit capabilities included in this certification 
criterion (i.e., record the user identification, the user's actions, 
and the health information viewed, downloaded, or transmitted) and make 
that information available to the patient. We have required this 
specific capability within this certification criterion because we 
believe that it is highly likely numerous EHR Modules could be 
certified to this criterion without also being certified to the 
auditable events and tamper resistance certification criterion we 
propose to adopt at Sec.  170.314(d)(2) due to the proposed policy 
change we specify in section IV.C.1 below related to EHR Modules and 
privacy and security. Thus, this express requirement guarantees that an 
EHR Module certified to this criterion would include the capability to 
track who has viewed, downloaded, or transmitted to a third party 
electronic health information and that patients would have access to 
this information. That being said, we do not intend for this portion of 
the certification criterion to impose a redundant requirement on EHR 
technology developers who present a Complete EHR or EHR Module for 
certification to both this certification criterion and the auditable 
events and

[[Page 13840]]

tamper resistance certification criterion. Accordingly, we provide in 
paragraph (e)(1)(ii)(B) of Sec.  170.314 that EHR technology presented 
for certification may demonstrate compliance with paragraph 
(e)(1)(ii)(A) of Sec.  170.314 if it is also certified to the 
certification criterion proposed for adoption at Sec.  170.314(d)(2) 
and the information required to be recorded in paragraph (e)(1)(ii)(A) 
of Sec.  170.314 is accessible to the patient. In other words, an EHR 
technology certified to Sec.  170.314(d)(2) would not need to also 
include the ``patient accessible log'' capability specified in 
paragraph (e)(1)(ii)(A) of Sec.  170.314 because it would be capable of 
logging such events and providing the information to the patient.
    We also propose for the ``patient accessible log'' capability to 
require that the date and time each action occurs be recorded using a 
system clock that has been synchronized following either Request for 
Comments (RFC) 1305 Network Time Protocol (NTP) v3 or RFC 5905 Network 
Time Protocol Version 4: Protocol and Algorithms Specification (NTPv4). 
These are final standards published by the Internet Engineering Task 
Force, a voluntary consensus standards body. Having correctly 
synchronized clocks is an information security best practice and the 
NTP, especially version 3, has been widely used and implemented since 
its publication in 1992.\9\ RFC 5905 NTPv4 was published in 2010 \10\ 
and is backwards compatible with NTPv3. It does, however, include a 
modified protocol header to accommodate the Internet Protocol version 6 
(IPv6) address family. For the same reasons we discuss here, we have 
included in the new certification criterion for electronic medication 
administration proposed for adoption at Sec.  170.314(a)(17) and the 
auditing standard proposed for adoption at Sec.  170.210(e) this same 
``synchronized clocks'' standard because each includes a capability 
that requires date and time to be recorded. As a general best practice, 
we highly encourage and expect EHR technology developers that associate 
date and/or time with capabilities included in certification criteria 
not specifically mentioned here to utilize a system clock that has been 
synchronized following NTPv3 or NTPv4. Additionally, the HITSC 
recommended that we require as a condition of certification other 
privacy and security oriented capabilities such as single factor 
authentication and secure download. We did not include these additional 
capabilities in our proposals because we believe their technical 
implementations are commonplace and ubiquitous. Thus, there would seem 
to be little value added by requiring that these capabilities be 
demonstrated as a condition of certification.
---------------------------------------------------------------------------

    \9\ http://www.ietf.org/rfc/rfc1305.txt.
    \10\ http://www.ietf.org/rfc/rfc5905.txt.
---------------------------------------------------------------------------

    We propose to require EHR technology to be capable of enabling 
images formatted according to the Digital Imaging and Communications in 
Medicine (DICOM) standard \11\ to be downloaded and transmitted to a 
third party. We believe 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 fact, the National 
Institutes of Health has recently funded activities focused on 
personally controlled sharing of medical images \12\ and published a 
solicitation notice on the same topic.\13\
---------------------------------------------------------------------------

    \11\ ftp://medical.nema.org/medical/dicom/2011/.
    \12\ http://report.nih.gov/recovery/investmentreports/ViewARRAInvRpt.aspx?csid=211.
    \13\ https://www.fbo.gov/index?s=opportunity&mode=form&id=ccb2340f4d8711b16f9e625b6b519371&tab=core&_cview=0 [solicitation <greek-i>: NHLBI-CSB-EB-2012-5-RP].
---------------------------------------------------------------------------

    We believe that all patients should have an equal opportunity to 
access their electronic health information without barriers or 
diminished functionality or quality. Thus, after consultation with the 
HHS Office for Civil Rights and HHS Office on Disability and reviewing 
the efforts of other Federal agencies, we propose that the viewing 
capability must meet Level AA conformance with the most recent set of 
the Web Content Accessibility Guidelines (WCAG). Federal agencies are 
considering, or proposing to adopt, WCAG 2.0 Level AA conformance for 
industries and technology they regulate. The Architectural and 
Transportation Barriers Compliance Board (Access Board) is considering 
applying WCAG 2.0 Level AA conformance to Federal agencies and 
telecommunications accessibility, which apply to telecommunication 
manufacturers.\14\ The Department of Transportation is proposing to 
require WCAG 2.0 Level AA conformance for air carrier Web sites and 
airport kiosks.\15\
---------------------------------------------------------------------------

    \14\ 76 FR 76640 (December 8, 2011). http://www.gpo.gov/fdsys/pkg/FR-2011-12-08/pdf/2011-31462.pdf#page=1.
    \15\ 76 FR 59307 (September 26, 2011). http://www.gpo.gov/fdsys/pkg/FR-2011-09-26/pdf/2011-24298.pdf.
---------------------------------------------------------------------------

    The WCAG were developed through an open process by the World Wide 
Web Consortium (W3C \16\).\17\ The most recent set of guidelines (WCAG 
2.0) were published in 2008 and are organized under 4 central 
principles with testable ``success criteria'': Perceivable, Operable, 
Understandable, and Robust.\18\ Each guideline offers 3 levels of 
conformance: A, AA, and AAA. Level A conformance corresponds to the 
most basic requirements for displaying Web content. 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. 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. We are proposing compliance with Level AA because it 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. In addition to WCAG 2.0 Level 
AA conformance, we are interested in whether commenters believe 
additional standards are needed for certification to ensure 
accessibility for the viewing capability, such as the User Agent 
Accessibility Guidelines (UAAG).\19\ Version 2.0 of the UAAG is 
designed to align with WCAG 2.0, but is currently only in draft form.
---------------------------------------------------------------------------

    \16\ http://www.w3.org/Consortium/.
    \17\ http://www.w3.org/WAI/intro/wcag.
    \18\ http://www.w3.org/TR/WCAG20/.
    \19\ http://www.w3.org/WAI/intro/uaag.php.
---------------------------------------------------------------------------

    The HITSC recommended that we move to one summary care record 
standard. We agree with this recommendation and believe that moving to 
one summary care record standard would lead to increased 
interoperability and spur innovation. The Consolidated CDA is the most 
appropriate standard to achieve this goal because it was designed to be 
simpler and more straightforward to implement and, in relation to this 
rulemaking, its template structure can accommodate the formatting of a 
summary care record that includes all of the data elements that CMS is 
proposing be available to be populated in a summary care record. 
Accordingly, we are proposing to require that EHR technology be capable 
of providing the information that CMS is proposing be required in a 
summary care record that

[[Page 13841]]

is provided to patients or their authorized representatives.
    In certain instances in Sec.  170.314(e)(1), we propose to require 
that the capability be demonstrated in accordance with the specified 
vocabulary standard. These vocabulary standards have been previously 
adopted or are proposed for adoption in this proposed rule consistent 
with the recommendations of the HITSC. With the exception of the four 
standards discussed below (LOINC, ICD-10-CM, ICD-10-PCS, and HCPCS), 
the vocabulary standards included in this certification criterion are 
discussed elsewhere in this preamble in connection with the 
certification criteria where the vocabulary standard is central to the 
required data or serves a primary purpose (e.g., RxNorm for e-
prescribing).
    For encounter diagnoses and procedures, we propose the use of ICD-
10 (ICD-10-CM and ICD-10-PCS, respectively). We request comment, 
however, on whether we should be more flexible with this proposed 
requirement based on any potential extension of the ICD-10 compliance 
deadline or possible delayed enforcement approach. More specifically, 
we are interested in whether commenters believe it would be more 
appropriate to require EHR technology to be certified to a subset of 
ICD-10; either ICD-9 or ICD-10; or to both ICD-9 and ICD-10 for 
encounter diagnoses and procedures. We also ask that commenters 
consider these options when reviewing and commenting on the other 
proposed certification criteria that include these standards (i.e., 
Sec.  170.314(a)(3), (b)(2), and (e)(2)). For procedures, we propose to 
continue to permit a choice for EHR technology certification, either 
ICD-10-PCS or the combination of Health Care Financing Administration 
Common Procedure Coding System (HCPCS) and Current Procedural 
Terminology, Fourth Edition (CPT-4). For outbound messages including 
laboratory tests, EHR technology must be capable of transmitting the 
tests performed in LOINC 2.38 to meet this certification criterion and 
for all other proposed certification criteria that include the 
capability to transmit laboratory tests in the LOINC 2.38 standard. We 
propose to adopt the ``view, download, and transmit to 3rd party'' 
certification criterion at Sec.  170.314(e)(1) and the ICD-10-PCS and 
ICD-10-CM standards at Sec.  170.207(b)(3) and (m), respectively.
    In August 2011, we published an advance notice of proposed 
rulemaking (ANPRM) (76 FR 48769) to seek public comment on the metadata 
standards we could propose for adoption in this proposed rule. In the 
ANPRM, we stated:

    We are considering whether to propose, as a requirement for 
certification, that EHR technology be capable of applying the 
metadata standards in the context of the use case selected by the 
HIT Policy Committee (i.e., when a patient downloads a summary care 
record from a health care provider's EHR technology or requests for 
it to be transmitted to their PHR). For example, if a patient seeks 
to obtain an electronic copy of her health information, her doctor's 
EHR technology would have to be capable of creating a summary care 
record and subsequently assigning metadata to the summary care 
record before the patient receives it.

    We noted in the ANPRM that, after reviewing public comments, we 
would re-consider our proposals and use this proposed rule to seek 
further public comment on more specific proposals. Given our proposed 
adoption of solely the Consolidated CDA standard for summary care 
records and the fact that this standard requires EHR technology 
developers to follow the requirements specified in the ``US Realm 
Header'' (section 2.1 of the Consolidated CDA), which includes the 
metadata elements we were considering for patient identity and 
provenance, we do not believe that it would be necessary or prudent to 
propose separate metadata standards at this time. Accordingly, we 
believe that for the first use case we identified in the ANPRM our 
policy goals can be accomplished through the adoption of the 
Consolidated CDA standard. This approach also addresses the HITSC's 
recommendation for this certification criterion to include ``data 
provenance'' with any health information that is downloaded. Finally, 
consistent with public comments on the ANPRM, we are not proposing 
metadata standards for ``privacy'' and intend to continue to work with 
the industry to further flesh out what such metadata standards could 
be. However, we note that one of the metadata elements required by the 
US Realm Header is the ConfidentialityCode which should be populated 
with a value from the value set of BasicConfidentialityKind (this value 
set includes 3 possible values: ``N'' Normal, ``R'' Restricted, and 
``V'' Very Restricted). We intend to continue to work with SDOs and 
other stakeholders on some of the HITSC recommendations discussed in 
the ANPRM relative to the CDA header. For example, we welcome comment 
on, and will consider moving from, the use of object identifiers (OIDs) 
to uniform resource identifiers (URIs).

    <bullet> Automated numerator recording

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
N/A
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(g)(1) (Automated numerator recording)
------------------------------------------------------------------------

    To complement the ``automated measure calculation'' certification 
criterion adopted at Sec.  170.302(n) (and now proposed for adoption as 
a revised certification criterion at Sec.  170.314(g)(2)), we propose 
to adopt a 2014 Edition EHR certification criterion which would apply 
solely to EHR Modules that include capabilities for an MU objective 
with a percentage-based measure. This certification criterion would 
focus on the EHR Module's capability to automatically record the 
numerator for those measures. While a Complete EHR would need to be 
capable of meeting the automated measure calculation certification 
criterion which requires the capability to accurately calculate MU 
denominators, we do not believe that it would be practicable for an EHR 
Module to do the same because, in most cases, an EHR Module would 
likely be unable to record or have access to an accurate denominator, 
especially in the case where multiple certified EHR Modules are being 
used by an EP, EH, or CAH. That said, we believe that EHR Modules 
presented for certification to certification criteria that include 
capabilities for supporting an MU objective with a percentage-based 
measure should at least be able to readily and accurately record the 
numerator for those capabilities. Therefore, we propose to adopt this 
new certification criterion at Sec.  170.314(g)(1).
    As noted, a Complete EHR would need to be certified to the proposed 
automated measure calculation criterion (Sec.  170.314(g)(2)). We would 
consider a Complete EHR certified to Sec.  170.314(g)(2) as having met 
the proposed automated numerator recording certification criterion at 
Sec.  170.314(g)(1) and, thus, there would be no need for the Complete 
EHR to be separately certified to Sec.  170.314(g)(1). However, as 
discussed under section IV.C.2 of this preamble, EHR Modules that are 
presented for certification to certification criteria that include 
capabilities for supporting an MU objective with a percentage-based 
measure would need to be certified to this proposed certification 
criterion. This would not preclude an EHR Module from being certified 
to the automated measure calculation certification criterion if the EHR 
Module developer sought such certification. In such instances, similar 
to our stance on Complete EHR certification to Sec.  170.314(g)(2), 
there would be no need

[[Page 13842]]

for the EHR Module to be separately certified to Sec.  170.314(g)(1).

    <bullet> Non-percentage-based measure use report

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
N/A
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(g)(3) (Non-percentage-based measure use report)
 
Standard
Sec.   170.210(g) (synchronized clocks)
------------------------------------------------------------------------

    To further complement the certification criteria proposed for 
adoption at Sec.  170.314(g)(1) and (g)(2), we propose to adopt a new 
2014 Edition EHR certification criterion at Sec.  170.314(g)(3) which 
would apply to any EHR technology presented for certification that 
includes capabilities associated with MU objectives and measures that 
are not percentage based. This certification criterion would focus on a 
Complete EHR's or EHR Module's capability to record that a user had 
certain EHR technology capabilities enabled during an EHR reporting 
period and had used those capabilities to demonstrate MU. We also 
propose to require that the date and time be recorded according to the 
``synchronized clocks'' standard that we explain in more detail in the 
preamble discussion of the new ``view, download, and transmit to 3rd 
party'' certification criterion proposed for adoption at Sec.  
170.314(e)(1).
    In consultation with CMS, we believe that EPs, EHs, and CAHs would 
benefit from this type of capability being required as a condition of 
certification. Additionally, we believe that such a capability could 
provide EPs, EHs, and CAHs with valuable evidence in the event of an MU 
audit. We propose that any EHR technology presented for certification 
to any one of the following certification criteria would need to be 
certified to this certification criterion.

170.314(a)(2)..........................  Drug-drug, drug-allergy
                                          interaction checks.
170.314(a)(8)..........................  Clinical decision support.
170.314(a)(10).........................  Drug-formulary checks.
170.314(a)(14).........................  Patient lists.
170.314(a)(17).........................  Electronic medication
                                          administration record.
170.314(f)(2)..........................  Transmission to immunization
                                          registries.
170.314(f)(4)..........................  Transmission to public health
                                          agencies (surveillance).
170.314(f)(6)..........................  Transmission of reportable
                                          laboratory tests and values/
                                          results.
170.314(f)(8)..........................  Transmission to cancer
                                          registries.
 

    EHR technology that is presented for certification to any of these 
certification criteria would need to be able to record the date and 
time and enable a user to create a report that indicates when each 
capability was enabled and disabled, and/or executed. We intend for the 
term ``executed'' to apply only to the certification criteria in the 
table above except those proposed for adoption at Sec.  170.314(a)(2) 
and (17). The MU measures associated with Sec.  170.314(a)(2) and (17) 
require that the capabilities CEHRT include be ``enabled'' or 
``implemented'' for an entire EHR reporting period. Moreover, they do 
not require unique action(s) by an EP, EH, or CAH. Last, we clarify 
that the privacy and security certification criteria proposed for 
adoption in Sec.  170.314(d) which are associated with the MU objective 
``protect electronic health information created or maintained by the 
Certified EHR Technology through the implementation of appropriate 
technical capabilities'' and measure which is not percentage based 
would not be included within the scope of this certification criterion. 
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.

    <bullet> Safety-enhanced design

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
N/A
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(g)(4) (Safety-enhanced design)
------------------------------------------------------------------------

    The International Organization for Standardization (ISO) defines 
usability as ``[t]he extent to which a product can be used by specified 
users to achieve specified goals with effectiveness, efficiency, and 
satisfaction in a specified context of use.'' \20\ Many industry 
stakeholders have acknowledged that a gap exists between optimal 
usability and the usability offered by some current EHR technologies. 
However, to date, little consensus has been reached on what might help 
close this gap and what role, if any, the Federal government should 
play related to the usability of EHR technology. In June 2011, the 
HITPC issued a report to ONC that explored the challenges associated 
with EHR technology usability and user-centered design (UCD). In its 
report, the HITPC identified certain ``desired outcomes of improved 
usability'' including improved safety and reduced cost, clinician 
frustration, training time, and cognitive load for clinical and non-
clinical users alike.
---------------------------------------------------------------------------

    \20\ ISO 9241-11.
---------------------------------------------------------------------------

    In November 2011, the Institute of Medicine (IOM) released a report 
titled ``Health IT and Patient Safety: Building Safe Systems for Better 
Care,'' in which the usability of EHR technology and quality management 
was often referenced. The IOM noted that ``[w]hile many vendors already 
have some types of quality management principles and processes in 
place, not all vendors do and to what standard they are held is 
unknown.'' Moreover, given this concern, the IOM recommended that 
``[t]he Secretary of HHS should specify the quality and risk management 
process requirements that health IT vendors must adopt, with a 
particular focus on human factors, safety culture, and usability.''
    We fundamentally agree with the sentiment expressed by both the 
HITPC and the IOM. As we consider the shared goals stated by 
stakeholders from all sides of this discussion, we believe that a 
significant first step toward improving overall usability is to focus 
on the process of UCD. While valid and reliable usability measurements 
exist, including those specified in NISTIR 7804 ``Technical Evaluation, 
Testing and Validation of the Usability of Electronic Health Records,'' 
\21\ we are concerned that it would be inappropriate at this juncture 
for ONC to seek to measure EHR technology in this way. Recognizing that 
EHR technologies exist and are in use today, we have prioritized eight 
certification criteria \22\ and associated capabilities to which this 
proposed certification criterion would require UCD to have

[[Page 13843]]

been applied. We chose these eight because we believe they pose the 
greatest risk for patient harm and, therefore, the greatest immediate 
opportunity for error prevention and user experience improvement. We 
believe this approach limits this new certification criterion's 
potential burden while providing for a much needed focus on the 
application of UCD to medication-related certification criteria.
---------------------------------------------------------------------------

    \21\ http://www.nist.gov/healthcare/usability.
    \22\ Sec.  170.314(a)(1) (CPOE); Sec.  170.314(a)(2) (Drug-drug, 
drug-allergy interaction checks); Sec.  170.314(a)(6) (Medication 
list); Sec.  170.314(a)(7) (Medication allergy list); Sec.  
170.314(a)(8) (Clinical decision support); Sec.  170.314(a)(17) 
(Electronic medication administration record); Sec.  170.314(b)(3) 
(Electronic prescribing); and Sec.  170.314(b)(4) (Clinical 
information reconciliation).
---------------------------------------------------------------------------

    The methods for how an EHR technology developer could employ UCD 
are well defined in documents and requirements such as ISO 9241-11, ISO 
13407, ISO 16982, and NISTIR 7741. Presently, we believe it is best to 
enable EHR technology developers to choose their UCD approach and not 
to prescribe one or more specific UCD processes that would be required 
to meet this certification criterion. Thus, the use of any one of these 
processes to apply UCD would meet this certification criterion. 
Moreover, we acknowledge and expect that EHR technology developers who 
have already followed UCD in past development efforts for the 
identified certification criteria would be performing a retrospective 
analysis to document for the purposes of testing and certification that 
UCD had been applied to the specified certification criteria. However, 
if UCD had not been previously applied to capabilities associated with 
any of the certification criteria proposed, the EHR technology would 
ultimately need to have such UCD processes applied before it would be 
able to be certified.
    We propose to adopt this certification criterion at Sec.  
170.314(g)(4). If we adopt this certification criterion in a final 
rule, we anticipate that testing \23\ to this certification criterion 
would entail EHR technology developers documenting that their UCD 
incorporates, in any form or format, all of the data elements defined 
in the Customized Common Industry Format Template for EHR Usability 
Testing (NISTIR 7742). We note that with respect to demonstrating 
compliance with this certification criterion that this information 
would need to be available to an ONC-ACB for review. This documentation 
would become a component of the publicly available testing results on 
which a certification is based (see section IV.D of this preamble for 
our proposal to make the test results used for certification publicly 
available).
---------------------------------------------------------------------------

    \23\ The National Voluntary Laboratory Accreditation Program, as 
administered by NIST, is responsible for testing under the permanent 
certification program (``ONC HIT Certification Program'') (76 FR 
1278).
---------------------------------------------------------------------------

    In addition to our proposed safety-enhanced design certification 
criterion, we request comment on two other safety-related certification 
criteria under consideration for adoption by the Secretary.
Quality Systems
    The IOM also recommended that we ``[establish] quality management 
principles and processes in health IT.'' Working with other Federal 
agencies, we intend to publish a quality management document that is 
customized for the EHR technology development lifecycle and expresses 
similar principles to those included in ISO 9001, IEC 62304, ISO 13485, 
ISO 9001, and 21 CFR 820. The document would provide specific guidance 
to EHR technology developers on best practices in software design 
processes in a way that mirrors established quality management systems, 
but would be customized for the development of EHR technology. We 
understand that some EHR technology developers already have processes 
like these in place, but do not believe, especially in light of the IOM 
recommendation, that the EHR technology industry as a whole 
consistently follows such processes. We expect that this document would 
be published around the same time as this proposed rule and would be 
available for public comment.\24\ Accordingly, we are considering 
including in the final rule an additional certification criterion that 
would require an EHR technology developer to document how their EHR 
technology development processes either align with, or deviate from, 
the quality management principles and processes that would be expressed 
in the document. We emphasize that this certification criterion would 
not require EHR technology developers to comply with all of the 
document's quality management principles and processes in order to be 
certified. Rather, to satisfy the certification criterion, EHR 
technology developers would need to review their current processes and 
document how they do or do not meet principles and processes specified 
in the document (and where they do not, what alternative processes they 
use, if any). We expect that this documentation would be submitted as 
part of testing and would become a component of the publicly available 
testing results on which a certification is based.
---------------------------------------------------------------------------

    \24\ The quality management document will be published on ONC's 
Web site during the public comment period of this proposed rule and 
notice of its availability will be made through a notice published 
in the Federal Register.
---------------------------------------------------------------------------

    We are considering adopting this additional certification criterion 
as part of the 2014 Edition EHR certification criteria for three 
reasons. First, all EHR technology developers that seek certification 
of their EHR technology would become familiar with quality management 
processes. Second, the public disclosure of the quality management 
processes used by EHR technology developers would provide transparency 
to purchasers and stakeholders, which could inform and improve the 
development and certification of EHR technology. Last, EHR technology 
developers' compliance with the certification criterion would establish 
a foundation for the adoption of a more rigorous certification 
criterion for quality management processes in the future without 
placing a significant burden on developers. We request public comment 
on this additional certification criterion and the feasibility of 
requiring EHR technology developers to document their current 
processes.
Patient Safety Events
    We are considering adopting a certification criterion (as mandatory 
or optional) that would require EHR technology to enable a user to 
generate a file in accordance with the data required by the Agency for 
Healthcare Research and Quality (AHRQ) Common Format,\25\ including the 
``Device or Medical/Surgical Supply, including HIT v1.1a.'' \26\ The 
Common Formats are designed to capture information about patient safety 
events. In line with IOM's recommendations, we believe that requiring 
this capability for certification could be an essential first step in 
creating the infrastructure that would support the reporting of 
potential adverse events involving EHR technology to patient safety 
organizations (PSOs). We request public comment on whether we should 
adopt such a certification criterion and what, if any, challenges EHR 
technology developers would encounter in implementing this capability.
---------------------------------------------------------------------------

    \25\ http://www.pso.ahrq.gov/formats/commonfmt.htm.
    \26\ https://psoppc.org/web/patientsafety/ahrq-common-formats-device-or-medical/surgical-supply-including-hit-device.
---------------------------------------------------------------------------

b. Ambulatory Setting
    We propose to adopt 3 certification criteria that would be new 
certification criteria for the ambulatory setting.

    <bullet> Secure messaging

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Use secure electronic messaging to communicate with patients on relevant
 health information.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(e)(3) (Ambulatory setting only--secure messaging)
 

[[Page 13844]]

 
Standard
Sec.   170.210(f)
------------------------------------------------------------------------

    The HITSC recommended two versions (based in large part on the work 
of the Implementation Workgroup and Privacy and Security Workgroup) of 
the 2014 Edition EHR certification criterion for secure messaging to 
support the MU objective and measure recommended by the HITPC, and now 
proposed by CMS. We agree with the direction provided by both 
recommendations and have merged the two into a refined certification 
criterion. We have also included what we believe should be the baseline 
standard in terms of encryption and hashing algorithms used to 
implement secure messaging. More specifically, we are proposing that 
only those identified in FIPS 140-2 Annex A be permitted to be used to 
meet this criterion. As such, we propose to adopt a new standard in 
Sec.  170.210(f) to refer to FIPS 140-2 Annex A's encryption and 
hashing algorithms. Additionally, we are proposing, consistent with the 
HITSC's recommendations, that methods for meeting this certification 
criterion could include, but would not be limited to, designing EHR 
technology to meet the following standards: IETF RFC 2246 (TLS 1.0) and 
SMTP/SMIME as well as implementation specifications such as NIST 
Special Publication 800-52 (``Guidelines for the Selection and Use of 
TLS Implementations'') and specifications developed as part of 
nationwide health information network initiatives. We propose to adopt 
this new certification criterion at Sec.  170.314(e)(3).

    <bullet> Cancer registry

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
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.
------------------------------------------------------------------------
2014 Edition EHR Certification Criteria
Sec.   170.314(f)(7) (Ambulatory setting only--cancer case information)
Sec.   170.314(f)(8) (Ambulatory setting only--transmission to cancer
 registries)
 
Standards and Implementation Specifications
Sec.   170.205(i) (HL7 CDA, Release 2 and Implementation Guide for
 Healthcare Provider Reporting to Central Cancer Registries, Draft,
 February 2012); Sec.   170.207(a)(3) (SNOMED CT[supreg] International
 Release January 2012); and Sec.   170.207(g) (LOINC version 2.38)
------------------------------------------------------------------------

    The HITPC provided recommendations that CMS consider requiring EPs 
to submit reportable cancer conditions. CMS has proposed this as a new 
objective and measure for EPs. We propose to adopt two new 2014 Edition 
EHR certification criteria to enable the performance of the objective 
and measure with the use of CEHRT. The proposed adoption of two 
criteria, one focused on the data capture and the other focused on the 
formatting and transmission of such data in the proposed standards is 
consistent with the HITSC recommendation to consider splitting the 
public health certification criteria in this manner. In consultation 
with the Centers for Disease Control and Prevention (CDC), we propose 
to adopt HL7 CDA, Release 2 as the content exchange standard. We also 
propose to adopt SNOMED CT[supreg] International Release January 2012 
and LOINC version 2.38 as the vocabulary standards. Additionally, we 
propose to adopt the Implementation Guide for Healthcare Provider 
Reporting to Central Cancer Registries, Draft, February 2012. This 
implementation guide was jointly developed by the CDC and the North 
American Association of Central Cancer Registries (NAACCR) and is 
available at http://www.cdc.gov/ehrmeaningfuluse. CDC will consider 
comments received on this proposed rule in finalizing the guide. 
Assuming CDC finalizes the guide, we would consider adopting the final 
version of the guide in a final rule with consideration of public 
comment on the appropriateness of the guide for certification.
    We propose to adopt these certification criteria at Sec.  
170.314(f)(7) and (8). We propose to adopt the HL7 CDA standard and 
implementation guide at Sec.  170.205(i). We propose to adopt SNOMED 
CT[supreg] International Release January 2012 and LOINC version 2.38 at 
Sec.  170.207(a)(3) and (g), respectively.
c. Inpatient Setting
    We propose to adopt 3 certification criteria that would be new 
certification criteria for the inpatient setting.

    <bullet> 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).
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(a)(17) (Inpatient setting only--electronic medication
 administration record)
 
Standard
Sec.   170.210(g) (synchronized clocks)
------------------------------------------------------------------------

    The HITSC recommended a new 2014 Edition EHR certification 
criterion to support the MU objective and measure recommended by the 
HITPC, now proposed by CMS, for EHs and CAHs to automatically track 
medications from order to administration. We have refined the 
recommended certification criterion to clearly state the capabilities 
that must be tested and certified. The certification criterion 
continues to reflect the intent of the HITPC and HITSC, including the 
basic ``rights'' (right patient, right medication, right dose, right 
route, and right time). It is our intent, consistent with the HITSC's 
recommendation, to permit a range of acceptable technical solutions for 
certification. However, we wish to make clear that in order to 
demonstrate compliance with this certification criterion, EHR 
technology must enable a user to electronically confirm the ``rights'' 
in relation to the medication(s) to be administered in combination with 
an assistive technology (such as bar-coding, location tracking, and 
radio-frequency identification (RFID)) which provides automated 
information on the ``rights.'' An electronic ``checklist'' through 
which a user would manually confirm the ``rights'' without any 
automated and assistive feedback from EHR technology would not be 
sufficient to demonstrate compliance with this certification criterion. 
We believe this clarification and distinction are important because an 
electronic medication administration record together with some type of 
assistive technology has been shown to decrease medication errors \27\ 
and it is not our intent to digitize a paper process that would not 
realize the safety benefits that could be provided with the use of an 
assistive technology. We propose to adopt this new certification 
criterion at Sec.  170.314(a)(17) with inclusion of the ``synchronized 
clocks'' standard as discussed earlier in this preamble under the 
``view, download, and transmit to 3rd party'' certification criterion.
---------------------------------------------------------------------------

    \27\ Poon EG, Keohane CA, Yoon CS, et al. (2010) Effect of Bar-
Code Technology on the Safety of Medication Administration New 
England Journal of Medicine 362:1698-1707.

    <bullet> Electronic prescribing

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Generate and transmit permissible discharge prescriptions electronically
 (eRx).
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(b)(3) (Electronic prescribing)
 
Standards
Sec.   170.205(b)(2) (NCPDP SCRIPT version 10.6) and Sec.   170.207(h)
 (RxNorm February 6, 2012 Release)
------------------------------------------------------------------------

    In response to the HITPC's recommendation for a new MU Stage 2 
objective and measure for e-prescribing

[[Page 13845]]

of discharge medications by EHs and CAHs (now proposed by CMS), the 
HITSC recommended a certification criterion for electronic prescribing 
of discharge medications. As part of the HITSC recommendation, it was 
recommended that we require as a condition of certification for the 
inpatient setting that certain HL7 standards be adopted for exchange 
within a legal entity. We did not accept this part of the 
recommendation because it is inconsistent with our approach of adopting 
standards for the electronic exchange of health information between 
different legal entities. We are proposing to adopt for the inpatient 
setting the same revised electronic prescribing certification criterion 
we propose to adopt for the ambulatory setting (i.e., we propose to 
adopt the certification criterion at Sec.  170.314(b)(3) for both 
settings). We discuss this revised certification criterion in further 
detail under the ambulatory setting subsection of the revised 
certification criteria section of this preamble.
    <bullet> Transmission of electronic laboratory tests and values/
results to ambulatory providers


------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Provide structured electronic laboratory results to eligible
 professionals.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(b)(6) (Inpatient setting only--transmission of electronic
 laboratory tests and values/results to ambulatory providers)
 
Standards and Implementation Specifications
Sec.   170.205(k) (HL7 2.5.1 and HL7 Version 2.5.1 Implementation Guide:
 Standards and Interoperability Framework Lab Results Interface, Release
 1 (US Realm)); and Sec.   170.207(g) (LOINC version 2.38)
------------------------------------------------------------------------

    The HITSC recommended a new 2014 Edition EHR certification 
criterion to support the MU objective and measure recommended by the 
HITPC for EHs and CAHs to send electronic laboratory tests and values/
results to eligible professionals. CMS has not proposed the MU 
objective and measure for Stage 2, but has requested public comment on 
whether the objective and measure should be incorporated into Stage 2.
    We have refined the recommended certification criterion, primarily 
to include the standards and implementation guide recommended by the 
HITSC and HITPC. The HITSC recommended that we consider requiring the 
Standards and Interoperability Framework Laboratory Results Interface 
Initiative (S&I Framework LRI).\28\ The S&I Framework LRI was created 
to reduce the variability of ambulatory laboratory interfaces as well 
as reduce the cost and time to initiate new electronic laboratory tests 
and values/results interfaces between clinical labs and ambulatory EHR 
technology. The S&I Framework LRI focused on the identification of a 
consistent set of data content that would need to be exchanged when 
laboratory tests and values/results are electronically delivered. We 
believe that our proposal to require for certification that inpatient 
EHR technology be capable of creating for transmission laboratory tests 
and values/results formatted in accordance with the LRI specification 
could make it more cost effective for electronic laboratory results 
interfaces to be set up in an ambulatory setting (i.e., minimal 
additional configuration and little to no additional/custom mapping) 
and that the electronic exchange of laboratory tests and values/results 
would improve.
---------------------------------------------------------------------------

    \28\ http://wiki.siframework.org/Lab+Results+Interface+%28LRI%29+Initiative.
---------------------------------------------------------------------------

    To further reduce costs and improve the electronic exchange of 
laboratory tests and values/results, we are building off the HITSC 
recommendation and are proposing to adopt a revised certification 
criterion for the ambulatory setting that would require EHR technology 
to be capable of incorporating laboratory tests and values/results 
according to the standards and implementation specifications discussed 
here, including the LRI implementation guide (see discussion of 
proposed Sec.  170.314(b)(5) under the revised certification criteria 
section below). We are also proposing to adopt LOINC version 2.38 as 
the vocabulary standard. The HITPC recommended using LOINC where 
available and the HITSC expressed agreement with this approach during 
their deliberations. Moreover, the LRI implementation guide requires 
the use of LOINC for laboratory tests. With respect to testing and 
certification for this certification criterion, we expect, among other 
aspects, that inpatient EHR technology would need to demonstrate its 
compliance with the ``Common Profile Component'' and other required 
profiles included within the LRI implementation guide.
    We propose to adopt this new certification criteria for the 2014 
Edition EHR certification criteria at Sec.  170.314(b)(6). We propose 
to adopt the HL7 2.5.1 standard and LRI implementation guide at Sec.  
170.205(k), acknowledging that the LRI specification is currently 
undergoing HL7 balloting. We intend to continue to monitor its progress 
and anticipate that a completed specification will be available before 
we publish a final rule. We propose to adopt LOINC version 2.38 at 
Sec.  170.207(g).
5. Revised Certification Criteria
    In the Permanent Certification Program final rule (76 FR 1302) we 
described revised certification criteria as certification criteria 
previously adopted by the Secretary that are modified to add, remove, 
or otherwise alter the specified capabilities and/or the standard(s) or 
implementation specification(s) referred to by the certification 
criteria. We also stated that revised certification criteria may also 
include certification criteria that were previously adopted as 
optional, but are subsequently adopted as mandatory. Again, based on 
our experience in trying to appropriately categorize the certification 
criteria we propose to be part of the 2014 Edition EHR certification 
criteria we have determined that our description of revised 
certification criteria needs to be refined. Accordingly, we list below 
the factors that we would consider when determining whether a 
certification criterion is ``revised:''
    <bullet> The certification criterion includes changes to 
capabilities that were specified in the previously adopted 
certification criterion;
    <bullet> The certification criterion has a new mandatory capability 
that was not included in the previously adopted certification 
criterion; or
    <bullet> The certification criterion was previously adopted as 
``optional'' for a particular setting and is subsequently adopted as 
``mandatory'' for that setting.
    To clarify, in some cases, a certification criterion could be both 
``revised'' and ``new.'' For example, a previously adopted 
certification criterion could have been adopted for only the ambulatory 
setting. Subsequently, we could revise the certification criterion by 
adding a new capability and making it mandatory for both the ambulatory 
and inpatient settings. Once adopted, the certification criterion would 
be ``new'' for the inpatient setting and ``revised'' for the ambulatory 
setting.
    We propose to adopt revised certification criteria that will 
support proposed revisions to MU objectives and measures and that will 
increase the interoperability, functionality, utility, safety, and 
security of EHR technology.

[[Page 13846]]

a. Ambulatory and Inpatient Setting
    We propose to adopt the following revised certification criteria 
for both the ambulatory and inpatient settings.

    <bullet> Drug-drug, drug-allergy interaction checks

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Implement drug-drug and drug-allergy interaction checks.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(a)(2) (Drug-drug, drug-allergy interaction checks)
------------------------------------------------------------------------

    The HITSC recommended a revised certification criterion for the 
2014 Edition EHR certification criteria to eliminate the ability for 
EHR technology to permit users to adjust drug-allergy interaction 
checks and to provide additional clarity for the capabilities that EHR 
technology must demonstrate. The HITSC reasoned that it would be 
clinically inappropriate to allow users to adjust drug-allergy 
interaction checks. The HITSC also reasoned that clarity could be 
provided with additional revisions. The HITSC recommended replacing the 
term ``real-time'' with ``before the order is executed.'' The HITSC 
also recommended revising the language to specify that notifications 
should happen during CPOE. Additionally, the HITSC recommended 
specifying that the level of severity of the notifications is what can 
be adjusted. The HITSC also recommended limiting the ability to make 
adjustments to an identified set of users or available as a system 
administrative function. Last, the HITSC recommended that drug-allergy 
contraindications should be interpreted to include adverse reaction 
contraindications. We agree with all of the HITSC's recommendations. We 
have revised and refined the language of the HITSC's recommended 
certification criterion, but otherwise have included all the 
recommended capabilities. As to the phrase ``identified set of users,'' 
we clarify that the EHR technology must enable an EP, EH, and CAH to 
assign only certain users (e.g., system administrator) with the ability 
to adjust severity levels. In other certification criteria that use the 
phrase ``identified set of users,'' a similar principle would apply 
(i.e., assigning the capability to only certain users). We believe this 
revised language more clearly indicates the intent of the criterion. We 
propose to adopt this revised certification criterion at Sec.  
170.314(a)(2).

    <bullet> Demographics

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Record the following demographics: preferred language; gender; 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.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(a)(3) (Demographics)
 
Standards
Sec.   170.207(f)(OMB standards); Sec.   170.207(j) (ISO 639-1:2002);
 and Sec.   170.207(k) (ICD-10-CM )
------------------------------------------------------------------------

    The HITSC recommended that we adopt a revised ``demographics'' 
certification criterion that requires the use of ISO 639-1 as the 
vocabulary standard for preferred language.\29\ We agree with the 
HITSC's recommendation because it appropriately limits the burden on 
EHR technology developers since the ISO 639-1 code set which uses an 
alpha-2 code for language names is roughly 40% that of the ISO 639-2 
code set which uses an alpha-3 code. We also propose to adopt ICD-10-CM 
for recording the preliminary cause of death. We believe that the use 
of ICD-10-CM will permit additional specificity for this data element. 
As for the Office of Management and Budget (OMB) standards for the 
classification of federal data on race and ethnicity, we note that the 
standard for classifying federal data according to race and ethnicity 
requires that the option for selecting one or more racial designations 
be provided. The standard also permits the use of more than the minimum 
standard categories for race and ethnicity as long as the data can be 
aggregated to the minimum standard categories, which would be confirmed 
through the testing and certification processes. We also propose to 
clarify the reference to the adopted standard as the ``Revisions to the 
Standards for the Classification of Federal Data on Race and 
Ethnicity,'' which was issued on October 30, 1997, as referenced at 
Sec.  170.207(f). Last, we propose to revise this criterion to require 
that EHR technology be capable of recording that a patient declined to 
specify his or her race, ethnicity, and/or preferred language. This 
proposed revision would ensure inclusion of such patients in the 
numerator of the MU percentage-based measure. We propose to adopt this 
revised certification criterion for the 2014 Edition EHR certification 
criteria at Sec.  170.314(a)(3) and the proposed standards at Sec.  
170.207(j) and (k).
---------------------------------------------------------------------------

    \29\ http://www.loc.gov/standards/iso639-2/php/code_list.php--
Also note that The Library of Congress has been designated the ISO 
639-2/RA for the purpose of processing requests for alpha-3 language 
codes comprising the International Standard.

    <bullet> Problem list

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Maintain an up-to-date problem list of current and active diagnoses.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(a)(5) (Problem list)
 
Standards
Sec.   170.207(a)(3) (SNOMED CT[supreg] International Release January
 2012)
------------------------------------------------------------------------

    Consistent with our discussion in the preamble section titled 
``Explanation and Revision of Terms Used in Certification Criteria,'' 
we have replaced the terms ``modify'' and ``retrieve'' in the 
recommended criterion with ``change'' and ``access,'' respectively. 
Further, consistent with the interpretation we provided in the S&CC 
July 2010 final rule, we are reiterating and clarifying that 
``longitudinal care'' is used to mean over an extended period of time. 
For the ambulatory setting, this would be over multiple office visits. 
For the inpatient setting, this would be for the duration of an entire 
hospitalization, which would include the patient moving to different 
wards or units (e.g., emergency department, intensive care, and 
cardiology) within the hospital during the hospitalization. The HITSC 
suggested that we consider longitudinal care to cover multiple 
hospitalizations, but we believe this could be difficult to achieve and 
may not offer added value based on the duration of time between a 
patient's hospitalizations and the reason for the hospitalizations. To 
note, our clarification of the meaning of longitudinal care applies 
equally to its use in other certification criteria, such as 
``medication list'' and ``medication allergy list.'' If we were to 
change our interpretation of longitudinal care as suggested by the 
HITSC, it would apply to these certification criteria as well and could 
constitute a change in the capabilities included in the criteria, which 
in turn would cause them to become revised certification criteria. We 
welcome comments on our interpretation of longitudinal care. We also 
welcome comments on whether a term other than ``longitudinal care'' 
could and should be used to express the capability required by this 
certification criterion and the other referenced certification criteria 
(``medication list'' and ``medication allergy list''). We understand 
that the longitudinal care description we use for the purposes of EHR 
technology certification may differ from the meaning that providers 
attribute to it, including the meaning given to it by the Longitudinal

[[Page 13847]]

Coordination of Care Workgroup within the Standards and 
Interoperability Framework.\30\
---------------------------------------------------------------------------

    \30\ http://wiki.siframework.org/Longitudinal+Coordination+of+Care+WG.
---------------------------------------------------------------------------

    The HITSC recommended that we adopt the appropriate version of 
SNOMED CT[supreg] for the revised criterion. We have determined, and 
propose to adopt, the International Release January 2012 version of 
SNOMED CT.[supreg] This is the most recent version of the code set.\31\ 
The HITSC also recommended that ICD-9-CM be replaced with ICD-10-CM. We 
agree that the use of ICD-9-CM should no longer be required due to the 
pending move to ICD-10-CM. However, we do not believe it would be 
appropriate to require the use of ICD-10-CM for problem lists. SNOMED 
CT[supreg] (and not ICD-10-CM) will be required for calculation of 
CQMs. Therefore, we propose that only SNOMED CT[supreg] is an 
appropriate standard for the recording of patient problems in a problem 
list. This does not, however, preclude the use of ICD-10-CM for the 
capture and/or transmission of encounter billing diagnoses. We propose 
to adopt this revised certification criterion for the 2014 Edition EHR 
certification criteria at Sec.  170.314(a)(5) and the International 
Release January 2012 version of SNOMED CT[supreg] at Sec.  
170.207(a)(3).
---------------------------------------------------------------------------

    \31\ http://www.nlm.nih.gov/research/umls/licensedcontent/snomedctfiles.html.

    <bullet> Clinical decision support

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Use clinical decision support to improve performance on high-priority
 health conditions.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(a)(8) (Clinical decision support)
 
Standard
Sec.   170.204(b)(1) (HL7 Context-Aware Knowledge Retrieval
 (``Infobutton'') Standard, International Normative Edition 2010)
------------------------------------------------------------------------

    The HITSC recommended a revised clinical decision support (CDS) 
certification criterion for the 2014 Edition EHR certification 
criteria. We have refined the recommended certification criterion to 
provide a clearer understanding of the capabilities that must be tested 
and certified and to provide greater flexibility to EHR technology 
developers in designing EHR technology to meet this proposed 
certification criterion. We also propose to require the use of the HL7 
Context-Aware Knowledge Retrieval (``Infobutton'') Standard, 
International Normative Edition 2010, for retrieving diagnostic or 
therapeutic reference information and specifically require the use of 
CDS with the incorporation of a summary care record.
    We have replaced the term ``clinical decision support rule'' used 
in the 2011 Edition EHR certification criteria and the HITSC 
recommended criterion with the term ``clinical decision support 
intervention'' to better align with, and clearly allow for, the variety 
of decision support mechanisms available that help improve clinical 
performance and outcomes. A CDS intervention is not simply an alert, 
notification, or explicit care suggestion. Rather, it should be more 
broadly interpreted as the user-facing representation of evidence-based 
clinical guidance. Our goal in clarifying the nomenclature is to focus 
more on the representation of the guidance (the CDS intervention) that 
the EHR technology should offer to the user rather than prescribe the 
form of either the logical representation of the clinical guidance or 
how the intervention interacts with the user.
    Referential sources such as medical texts, primary research 
articles, and clinical practice guidelines have long been available in 
electronic form, but the means and manner of accessing them have 
historically been disconnected from the points in providers' patient 
care workflows when the immediate availability of the reference sources 
would optimize clinical decisions. Increasingly, these tools are being 
made available through links in EHRs, offering information at relevant 
points within the clinical workflow. The Infobutton standard has been 
in active use for several years with many reference content vendors now 
providing their products in this form, and we propose to adopt its most 
recent edition (International Normative Edition 2010) in order to 
enable a user to retrieve diagnostic or therapeutic reference 
information. The use of standard reference information retrieval 
formats will accelerate the delivery of content to providers and 
hospitals, and will enhance the flexibility of such implementations 
because these formats reduce the need to ``hard wire'' the content 
databases to installed EHR technology. This flexibility allows EPs, 
EHs, and CAHs more choices and easier migration across content 
providers, encouraging innovation and competitiveness among these 
content providers.
    We believe it is important for CDS interventions to be triggered 
when new information is incorporated into EHR technology as a result of 
a care transition. Therefore, we are proposing that EHR technology 
enable interventions to be triggered when the specified data elements 
are incorporated into a summary care record pursuant to the capability 
specified at Sec.  170.314(b)(1) (transitions of care--incorporate 
summary care record). We are also considering whether EHR technology 
should be capable of importing or updating value sets for the 
expression of CDS vocabulary elements using the HL7 Common Terminology 
Services, Revision 1, standard. We request comment on industry 
readiness to adopt this standard and on the benefits it could provide 
if required as a part of this certification criterion.
    Consistent with the HITSC stated intent, for EHR technology to be 
certified to this criterion it must be capable of providing 
interventions and the reference resources in paragraph (a)(8)(ii)(A) of 
Sec.  170.314 by leveraging each one or any combination of the patient-
specific data elements listed in paragraphs (a)(8)(i) and (ii) of Sec.  
170.314 as well as one or any combination of the user context data 
points listed in paragraph (a)(8)(iii)(A) of Sec.  170.314. EHR 
technology must also be capable of generating interventions 
automatically and electronically when a user is interacting with the 
EHR technology. Last, the HITSC recommended that the source attributes 
of suggested interventions be displayed or available for users. We 
agree that this capability is important, but believe further 
clarification is necessary regarding what types of information must be 
provided for EHR technology to meet this criterion. We believe that, at 
a minimum, a user should be able to review the: bibliographic citation 
(i.e., the clinical research/guideline) including publication; 
developer of the intervention (i.e., the person or entity who 
translated the intervention from a clinical guideline into electronic 
form, for example, Company XYZ or University ABC); funding source of 
the intervention development; and release and, if applicable, revision 
date of the intervention. The availability of this information will 
enable the user to fully evaluate the intervention. The availability of 
this information will also enhance the transparency of all CDS 
interventions, and thus improve their utility to healthcare 
professionals and patients.
    We propose to adopt this revised certification criterion at Sec.  
170.314(a)(8) and the Infobutton standard at Sec.  170.204(b)(1).

    <bullet> Patient-specific education resources

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective

[[Page 13848]]

 
Use clinically relevant information from Certified EHR Technology to
 identify patient-specific education resources and provide those
 resources to the patient.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(a)(16) (Patient-specific education resources)
 
Standard
Sec.   170.204(b)(1) (HL7 Context-Aware Knowledge Retrieval (Infobutton)
 Standard, International Normative Edition 2010)
------------------------------------------------------------------------

    We propose to adopt a revised 2014 Edition EHR certification 
criterion that does not have the language ``as well as provide such 
resources to the patient'' at the end of the paragraph. This language 
is in the 2011 Edition EHR certification criterion, but is redundant of 
the capability expressed at the beginning of the paragraph. 
Additionally, we propose to adopt the HL7 Context-Aware Knowledge 
Retrieval (Infobutton) Standard, International Normative Edition 2010, 
as the required standard. Infobutton is being increasingly used by more 
providers to electronically identify and provide patient-specific 
education resources. Therefore, we believe it is appropriate now to 
require EHR technology to enable a user to identify and provide 
patient-specific education resources based on the specified data 
elements and in accordance with Infobutton. We propose to adopt this 
revised certification criterion at Sec.  170.314(a)(16) and the 
Infobutton standard at Sec.  170.204(b)(1).
    <bullet> 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.
------------------------------------------------------------------------
2014 Edition EHR Certification Criteria
Sec.   170.314(b)(1) (Incorporate summary of care record)
Sec.   170.314(b)(2) (Create and transmit summary care record)
 
Standards
Sec.   170.205(a)(3) (Consolidated CDA); Sec.   170.207(f) (OMB
 standards for the classification of federal data on race and
 ethnicity); Sec.   170.207(j) (ISO 639-1:2002 (preferred language));
 Sec.   170.207(l) (smoking status types);
Sec.   170.207(a)(3) (SNOMED-CT[supreg] International Release January
 2012); Sec.   170.207(m) (ICD-10-CM); Sec.   170.207(b)(2) (HCPCS and
 CPT-4) or Sec.   170.207(b)(3) (ICD-10-PCS); Sec.   170.207(g) (LOINC
 version 2.38); Sec.   170.207(h) (RxNorm February 6, 2012 Release); and
 Sec.   170.202(a)(1) (Applicability Statement for Secure Health
 Transport); Sec.   170.202(a)(2) (XDR and XDM for Direct Messaging);
 and Sec.   170.202(a)(3) (SOAP-Based Secure Transport RTM version 1.0)
------------------------------------------------------------------------

    The HITSC recommended a merged revised certification criterion for 
the 2014 Edition EHR certification criteria that would be generally 
applicable to both the ambulatory and inpatient settings, with a 
deviation based on the setting-specific information that would be 
included in the summary care record. We have made refinements to the 
recommended certification criterion. We believe that the criterion 
should be split into two separate certification criteria based on the 
capabilities required. We base this revision on stakeholder feedback 
received after the publication of the S&CC July 2010 final rule, which 
explained that (especially for inpatient settings) two different EHR 
technologies are sometimes used to perform the capabilities of 
incorporation and creation of a summary care record. Consequently, 
adopting two separate certification criteria provides developers 
greater flexibility for certification. The first proposed certification 
criterion would require EHR technology to be able to incorporate a 
summary care record formatted according to the Consolidated CDA, and 
the second certification criterion would require that EHR technology be 
capable of generating and transmitting a summary care record in 
accordance with the Consolidated CDA, with certain specified vocabulary 
standards, and two specified transport standards.
    For the same reasons we discussed for the new ``view, download, and 
transmit to 3rd party'' certification criterion (Sec.  170.314(e)(1)), 
we believe that adopting the Consolidated CDA for this certification 
criterion is advantageous since its template structure can accommodate 
the formatting of a summary care record that includes all of the data 
elements that CMS is proposing be available to be populated in a 
summary care record. We recognize that care plan, additional care team 
members, referring or transitioning provider's name and contact 
information as well as certain hospital discharge information are not 
explicitly required to be captured by separate certification criteria, 
unlike most other data elements included in the clinical summary. The 
ability to capture these data elements is both implicit and necessary 
to satisfy this certification criterion (as well as the other 
certification criteria that rely on the same data). Therefore, we 
considered, but have not proposed, adopting separate data capture 
certification criteria for each of these data elements in order to make 
it clear that they are required to be captured. We request public 
comment on whether in the final rule we should create separate 
certification criteria for all of these data elements. For certain 
other data elements in Sec.  170.314(b)(2), we propose to require that 
the capability to provide the information be demonstrated in accordance 
with the specified vocabulary standard. These vocabulary standards have 
been previously adopted or are proposed for adoption in this proposed 
rule consistent with the recommendations of the HITSC. Additionally, we 
request public comment on whether we should require, as part of the 
``incorporate summary care record'' certification criterion proposed at 
Sec.  170.314(b)(1), that EHR technology be able to perform some type 
of demographic matching or verification between the patient in the EHR 
technology and the summary care record about to be incorporated. This 
would help prevent two different patients summary care records from 
being combined.
    As with the ``view, download, and transmit to 3rd party'' 
certification criterion, we are proposing that EHR technology be 
capable of transmitting a summary care record according to both the 
transport standards we propose to adopt to enable directed exchange. We 
believe the use of these standards is a critical first step in 
achieving a common means of transporting health information to support 
MU and future exchange needs. For this certification criterion, we also 
propose to adopt as an optional standard at Sec.  170.202(a)(3) the 
SOAP-Based Secure Transport RTM version 1.0 \32\ which was developed 
under the nationwide health information network Exchange Initiative and 
to which we believe EHR technology should be able to be certified. We 
believe including this option provides added flexibility to those EPs, 
EHs, or CAHs that may seek to use EHR technology with the ability to 
transmit health information using SOAP as a transport standard in 
addition to SMTP to meet MU. While we would only permit EHR technology 
to be certified to these two transport

[[Page 13849]]

standards, we intend to monitor innovation around transport and would 
consider including additional transport standards, such as a RESTful 
implementation, in this certification criterion. The inclusion of 
additional standards in this certification criterion would permit EHR 
technology to be certified to added transport standard(s) and could 
ultimately enable EPs, EHs, and CAHs to meet MU using EHR technology 
certified with the added transport standard(s).
---------------------------------------------------------------------------

    \32\ http://modularspecs.siframework.org/NwHIN+SOAP+Based+Secure+Transport+Artifacts.
---------------------------------------------------------------------------

    In deciding whether additional standards are appropriate for 
inclusion, we would seek the HITSC's recommendation on whether a new 
transport standard should be adopted. We expect that the HITSC would 
consider, among other factors, whether the standard is ``open'' or non-
proprietary, the public comment processes involved in its development, 
and any pilot testing completed/results. If the HITSC were to recommend 
that we adopt an additional transport standard, we believe that it 
should be designated as optional (consistent with our discussion at 75 
FR 44599) and that we would likely pursue interim final rulemaking with 
comment to adopt the transport standard, which would enable EHR 
technology to be expeditiously certified to the transport standard and 
EPs, EHs, and CAHs to subsequently use EHR technology certified to this 
added transport standard to meet MU.
    We welcome comments on whether equivalent alternative transport 
standards exist to the ones we propose to exclusively permit for 
certification. We also welcome comment on our proposed approaches for 
deciding whether additional transport standards are appropriate and for 
adopting any such standards through interim final rulemaking with 
comment. Additionally, in the context of the proposed limitations 
included as part of the proposed MU Stage 2 measure associated with 
this objective (which is percentage-based), we request public comment 
on any difficulties EHR technology developers might face in determining 
the numerator and denominator values to demonstrate compliance with the 
automated numerator calculation or automated measure calculation 
certification criteria we propose to adopt.
    We propose to adopt these revised certification criteria for the 
2014 Edition EHR certification criteria at Sec.  170.314(b)(1) and (2).

    <bullet> Clinical information reconciliation


------------------------------------------------------------------------
 
-------------------------------------------------------------------------
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.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(b)(4) (Clinical information reconciliation)
------------------------------------------------------------------------

    In the S&CC January 2010 interim final rule, we adopted a 
certification criterion for medication reconciliation that stated 
``[e]lectronically complete medication reconciliation of two or more 
medication lists by comparing and merging into a single medication list 
that can be electronically displayed in real-time.'' In response to 
public comments requesting additional clarity and expressing concerns 
that EHR technology should not automatically (i.e., without any human 
intervention) be required to perform this capability, we revised this 
certification criterion (adopted at Sec.  170.302(j) in the S&CC July 
2010 final rule) to say ``[e]nable a user to electronically compare two 
or more medication lists.''
    At the end of one of our responses to comments in the S&CC July 
2010 final rule, we stated ``[w]e do, however, see great promise in 
making this capability more comprehensive and anticipate exploring ways 
to improve the utility of this capability before we adopt a subsequent 
round of certification criteria'' (75 FR 44613). We now propose to 
revise this certification criterion and adopt as part of the 2014 
Edition EHR certification criteria an expanded version that focuses on 
the reconciliation of data elements in each of a patient's medication, 
problem, and medication allergy lists. We believe that EHR technology 
can be designed to assist users in remarkable ways and that reconciling 
information from multiple sources in a way that is assistive to a user 
is something at which EHR technology should excel. We also believe that 
with an increased focus on care coordination and use of CDS for 
advanced care processes, it will be significantly more important for 
EPs, EHs, and CAHs to have accurate and updated medication, problem, 
and medication allergy lists.
    Accordingly, we propose a revised certification criterion which we 
are labeling as ``clinical information reconciliation'' to express 
three specific capabilities that EHR technology would need to include. 
First, EHR technology would need to be able to electronically display 
the data elements from two or more sources in a manner that allows a 
user to view the data elements and their attributes, which must 
include, at a minimum, the source and last modification date of the 
information. For example, when assisting a user to reconcile a 
medication list, the EHR technology would need to display the 
medication(s) and, at a minimum, the source of medications (e.g., 
``patient'' or ``summary care record from XYZ'') and the last 
modification date of the information associated with those medications. 
The second medication source in this example would be the current 
medication list the EHR technology maintains for the patient. The 
second specific capability EHR technology would need to include would 
be to enable a user to merge and remove individual data elements. For 
example, if a medication from source <greek-i>1 and a medication from 
source <greek-i>2 were the same, the user would be able to use EHR 
technology to merge such medications into a single representation. 
While not required or expected for certification, this capability could 
be designed to automatically suggest to the user which medications 
could be merged or removed. The third and final specific capability EHR 
technology would need to include would be to enable a user to review 
and validate the accuracy of a final set of data elements and, upon a 
user's confirmation, automatically update the patient's medication, 
problem, and/or medication allergy list. Per comments on our prior 
rules, we want to make clear that EHR technology's role is to be 
assistive and not to determine without human judgment which data 
elements should be reconciled. Thus, this third specific capability 
would require EHR technology to present a final set of merged data 
elements for a user to validate and confirm before updating the prior 
list. Finally, we request public comment on whether as part of this 
certification criterion we should require EHR technology to perform 
some type of demographic matching or verification between the data 
sources used. This would help prevent two different patients' clinical 
information from being reconciled. We propose to adopt this revised 
certification criterion at Sec.  170.314(b)(4).
    <bullet> Incorporate laboratory tests and values/results


------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Incorporate clinical laboratory test results into Certified EHR
 Technology as structured data.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(b)(5) (Incorporate laboratory tests and values/results)
 
Standards and Implementation Specifications

[[Page 13850]]

 
Sec.   170.205(k) (HL7 2.5.1 and HL7 Version 2.5.1 Implementation Guide:
 Standards and Interoperability Framework Lab Results Interface, Release
 1 (US Realm)); and Sec.   170.207(g) (LOINC version 2.38)
------------------------------------------------------------------------

    The HITSC did not recommend that we revise the incorporate 
laboratory test results certification criterion (adopted as part of the 
2011 Edition EHR certification criteria at 45 CFR 170.302(h)). We 
believe, however, that we should leverage the significant progress made 
by the S&I Framework LRI discussed under the proposed new certification 
criterion for the transmission of electronic laboratory tests and 
values/results to ambulatory providers (Sec.  170.314(b)(6)). This can 
be achieved by proposing revisions to this certification criterion for 
the ambulatory setting. By requiring ambulatory EHR technology to be 
capable of receiving laboratory tests and values/results formatted in 
accordance with the HL7 2.5.1 standard and the LRI implementation 
guide, it would be significantly easier and more cost effective for 
electronic laboratory results interfaces to be set up in an ambulatory 
setting (i.e., minimal additional configuration and little to no 
additional/custom mapping). Moreover, it would increase the likelihood 
that data would be properly incorporated into ambulatory EHR technology 
upon receipt and thus, facilitate the subsequent use of the data by the 
EHR technology for other purposes, such as CDS. We propose to adopt 
LOINC version 2.38 as the vocabulary standard, because the LRI 
implementation guide requires the use of LOINC for laboratory tests. We 
request public comment on whether the proposed standards for the 
ambulatory setting should also apply for the inpatient setting and 
whether the LRI specification (even though it was developed for an 
ambulatory setting) is generalizable to an inpatient setting and could 
be adopted for certification for that setting as well. Besides the 
proposed revisions discussed, we have used the term ``incorporate'' to 
replace the terms ``attribute,'' ``associate,'' and ``link'' which were 
used in the 2011 Edition EHR certification criterion.
    We propose to adopt this revised certification criteria for the 
2014 Edition EHR certification criteria at Sec.  170.314(b)(5). We 
propose to adopt the HL7 2.5.1 standard and LRI implementation guide at 
Sec.  170.205(k), acknowledging that the LRI specification is currently 
undergoing HL7 balloting. We intend to continue to monitor its progress 
and anticipate that a completed specification will be available before 
we publish a final rule. We propose to adopt LOINC version 2.38 at 
Sec.  170.207(g).

    <bullet> Clinical quality measures

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
N/A
------------------------------------------------------------------------
2014 Edition EHR Certification Criteria
Sec.   170.314(c)(1) (Clinical quality measures--capture and export)
Sec.   170.314(c)(2) (Clinical quality measures--incorporate and
 calculate)
Sec.   170.314(c)(3) (Clinical quality measures--reporting)
 
Standard
Sec.   170.204(c) (NQF Quality Data Model)
------------------------------------------------------------------------

    The HITSC recommended certain vocabularies and codes sets for 
inclusion in the Quality Data Model (QDM),\33\ but did not recommend 
CQM certification criteria or offer recommendations for the 
certification of CQMs. For the 2014 Edition EHR certification criteria, 
we propose to revise previously adopted CQM certification criteria for 
the ambulatory and inpatient settings to specify more explicitly the 
capabilities EHR technology would need to include, focusing on:
---------------------------------------------------------------------------

    \33\ Quality Data Model--National Quality Forum: http://www.qualityforum.org/Projects/h/QDS_Model/Quality_Data_Model.aspx.
---------------------------------------------------------------------------

    <bullet> Data capture--The capability of EHR technology to record 
the data that would be required in order to calculate CQMs.
    <bullet> Export--The capability of EHR technology to create a data 
file that can be incorporated by another EHR technology to calculate 
CQMs.
    <bullet> Calculate--The capability of EHR technology to incorporate 
data (from other EHR technology where necessary) and correctly 
calculate the result for CQMs.
    <bullet> Reporting--The capability of EHR technology to create a 
standard data file that can be electronically accepted by CMS.

By explicitly separating the certification of CQMs into these discrete 
criteria, we believe that user experiences relative to CQMs can be 
enhanced, the burden of capturing data elements necessary for CQMs can 
be reduced, and ultimately, EPs, EHs, and CAHs would be better 
positioned to assess in real-time the quality of care they provide.
Data Capture
    Prior to the EHR Incentive Programs, measure stewards did not 
routinely or traditionally specify CQMs with consideration of EHR 
technology and its capacity to capture certain data. To assist in the 
effort of preparing CQMs in a more uniform manner, the National Quality 
Forum (NQF), under contract with CMS, created the QDM which today 
serves as the information model from which new CQMs are specified. 
Because older CQMs were not specified as ``EHR-ready'' when initially 
developed, they specify certain data capture requirements that most EHR 
technologies cannot perform (or do not perform in any structured way) 
as well as constructs that would still require human intervention or 
judgment (i.e., ``chart abstraction''). Despite the best efforts to 
``re-tool'' older measures for inclusion at the beginning of the EHR 
Incentive Programs, we now understand that the CQMs required for 
certification as part of the S&CC July 2010 final rule did not, in some 
cases, adequately reflect a pure ``EHR-ready'' CQM. We have been 
informed that as a result EHR technology developers created new data 
fields and/or advised their customers to use specified (and in some 
cases alternative and atypical) workflows, templates, or form elements 
to capture these data elements in a consistent manner that would enable 
such data to be captured for a CQM calculation.
    To build on past feedback and lessons learned, we have, with CMS, 
jointly conducted extensive research, consulted with subject matter 
experts, and received recommendations (on CQMs generally) from the 
HITPC and HITSC. We have sought to determine how to best address the 
difference between the data capture capabilities we believe most EHR 
technologies can reasonably perform and the requirements that measure 
stewards have specified in CQMs. This work has led us to believe that a 
more explicit and extensible approach for CQM certification is 
required, an approach that would be able to support the CQMs proposed 
for MU Stages 1 and 2 beginning in FY/CY 2014 as well as CQMs adopted 
for future MU stages.
    The CQM lifecycle starts with the determination of data elements to 
be captured and the subsequent capture of clinical or demographic data. 
Thus, the first specific capability we propose for CQM certification 
(Sec.  170.314(c)(1)(i)) focuses on the capability of EHR technology to 
electronically record all of the data elements that are represented in 
the QDM. More specifically, EHR technology would need to be able to 
record data in some representation that can be associated with the 
categories, states, and attributes represented by the QDM. As a simple 
example, EHR technology would need to be able to record a 
representation of ``Medication active'' or ``Problem active'' where the 
first term represents the QDM category and the second represents the 
QDM

[[Page 13851]]

``state of being.'' In certain cases, such as in the prior example with 
``Problem active,'' the data capture necessary is already specified by 
another certification criterion proposed for adoption as part of the 
2014 Edition EHR certification criteria (i.e., Sec.  170.314(a)(5) to 
record active problems). However, in other cases an EHR technology 
developer would need to review the QDM to ensure the EHR technology 
presented for certification captures data elements that are not 
explicitly required to be recorded in other proposed certification 
criteria. Because the QDM is agnostic to health care settings (e.g., 
ambulatory and inpatient settings) and all of the CQMs ultimately 
adopted by CMS in a final rule would be based on the QDM, we do not 
believe that it would be necessary or possible to propose specific 
separate ambulatory and inpatient setting certification requirements as 
we have with other proposed certification criteria. Thus, all EHR 
technology regardless of the setting for which it is designed would 
need to meet Sec.  170.314(c)(1)(i) if it is presented for 
certification to this certification criterion. Furthermore, because 
data capture is fundamental to the eventual calculation of CQMs, we 
have proposed an EP, EH, or CAH would need to have EHR technology 
certified to Sec.  170.314(c)(1) in order to have EHR technology that 
meets the definition of a Base EHR (discussed later in this preamble).
    We recognize that EPs, EHs, and CAHs may employ many methods to 
capture the information required by CQMs and we do not intend for this 
certification criterion to imply that EHR technology developers would 
need to include manual data entry requirements if such data can be 
easily obtained from other electronic sources. For example, we 
anticipate that a patient's smoking status could be captured through a 
variety of approaches such as an ``app'' on a mobile phone, a portal, 
personal health record (PHR), from a patient registration kiosk, or 
practice management system. Regardless of the data's origin or source 
system, an EHR technology developer would need to show for 
certification that its EHR technology can electronically record a 
representation of that data. Moreover, we do not require for 
certification that data must be recorded according to a specific 
vocabulary standard, in recognition of, and to accommodate, 
environments in which local codes and terminologies have been used or 
where the data may originate from another electronic source. We do, 
however, expect that wherever possible, EHR technology developers will 
use standard vocabularies as this will minimize the need for mapping 
processes that will require development and maintenance. As described 
below, we expect that exported quality data would be formatted 
according to the standard vocabularies in the QDM, where applicable.
Alternative Data Capture Certification Options Considered
    The above proposal for data capture represents the certification 
option that best describes the capabilities that EHR technology would 
need to include in order to capture the data required for the EHR 
Incentive Programs CQM proposals from CMS. We recognize that this 
option may be a suboptimal long-term solution--compared to one that can 
fundamentally reshape the path measure stewards take to develop ``EHR-
ready'' CQMs. Through our work with CMS, it has become clear that gaps 
still remain between the data capture expectations of the CQMs included 
by CMS in its Stage 2 proposed rule and the capabilities of EHR 
technology. While the QDM was created in order to facilitate the 
development of ``EHR-ready'' CQMs, it is a model that reflects the data 
representation of CQMs and does not consider whether a given data type 
would or should be captured by EHR technology. We recognize that the 
gap between the data defined by the QDM and the data traditionally 
captured in EHR technology is, in some areas, broad and we request 
comments regarding (1) Industry readiness for the expansion of EHR 
technology data capture; (2) how this would impact system quality, 
usability, safety, and workflow; and (3) how long the industry believes 
it would take to close this gap. Additionally, we recognize that some 
specialty-focused EHR technologies may not need to capture all of the 
data that the QDM describes. We request public comment regarding how 
certification can accommodate specialty EHR technology developers so 
that they would not have to take on development work (solely to get 
certified) for functionality that their customers may not require.
    We believe that there are alternative options to our proposal and 
request public comment with respect to whether we should pursue one or 
more of the alternative approaches below for certification in the final 
rule.
    <bullet> CQM-by-CQM Data Capture: Our proposed data capture 
certification criterion specifies that EHR technology must be able to 
capture all of the data elements represented in the QDM. As an 
alternative to our proposal, we considered an approach to certification 
for data capture that would be based on the data elements reflected in 
the individual CQMs selected by CMS instead of the entire QDM. When EHR 
technology is presented for certification for data capture, the 
developer would identify the specific CQMs that the technology is 
capable of supporting, and the technology must capture each and every 
data element reflected in those CQMs in order to be certified. For 
example, if a developer presents for certification EHR technology 
designed for an inpatient (e.g., emergency department) setting that 
would support the hospital quality measures NQF 0495 and 0497, the 
technology would have to demonstrate that it could capture all of the 
data elements included in those measures. An EHR technology developer 
would design its EHR technology to capture the data elements for those 
CQMs it believed its EHR technology would need to support for the types 
of providers to which it markets its EHR technology. We believe this 
approach may be advantageous because it poses a lower initial burden 
for EHR technology developers. But it also has its disadvantages 
because it could lead to a void in the market for EHR technology that 
would support certain CQMs that EPs, EHs and CAHs would need to report 
beginning in 2014. We request public comment on whether we should take 
this approach instead of our proposal on certification for data 
capture.
    <bullet> Explicit Certification Criteria: In some cases, we 
recognize that while not required for certification, many EHR 
technologies already capture data elements included in the QDM. For 
example, inactive medical problems may be captured and represented as 
past medical history. For these cases, we considered and believe that 
it would be clearer (and easier for EHR technology developers) if we 
were to either add specific CQM data capture requirements to already 
existing certification criteria or adopt new certification criteria in 
order to explicitly require the data that is specified by the QDM to be 
captured. In other cases, despite a measure steward specifying that 
certain data capture occur, we are unaware of a consistent or 
established method with which EHRs capture certain information. For 
example, most EHR technology of which we are aware does not 
consistently capture why a particular medication was not prescribed, 
nor do they systematically make a distinction between ``patient 
reason,'' ``system reason,'' and ``medical

[[Page 13852]]

reason.'' We request public comment on whether this approach would be 
preferred, which certification criteria should be expanded, and where 
new certification criteria would be appropriate. We believe this 
approach could also ensure when EHR Modules are used in combination to 
meet the definition of CEHRT that all of the data necessary to capture 
for CQM calculations would be electronically available.
    <bullet> CQM Exclusions: Our research indicates that CQM exclusions 
represent the majority of CQM data that are expected by measure 
stewards to be captured or represented in EHR technology but are not. 
In cases where a CQM specifies a negation exclusion,\34\ we propose 
that EHR technology would not be required to capture the ``reason'' 
justification attribute of any data element in an encoded way. Rather, 
we would permit ``reason'' to allow for free text entries. For 
calculation and reporting purposes, the presence of text in the 
``reason'' field may be used as a proxy for any ``reason'' attribute. 
We request public comment regarding the impact this flexibility would 
have on the accuracy of CQM reporting.
---------------------------------------------------------------------------

    \34\ A negation exclusion or exception is a factor that removes 
a given patient from the denominator of a CQM with a statement about 
why a given event or intervention did not occur. For example, a CQM 
may state that all patients with X condition must have Y 
intervention, except patients who did not receive the intervention 
for reason Z. A CQM may state that all patients over the age of 6 
months should have an influenza vaccine between October and February 
(Y intervention), except patients with allergy to egg albumin 
(reason Z-1) or patients who decline vaccination (reason Z-2). In 
some measures, the unit of analysis is not a patient, but an 
encounter or a procedure. In such measures the exclusion or 
exception can apply to individual patient factors or factors 
affecting the specific unit of analysis. Additionally, exclusions 
for ratio measures can also remove a patient from the numerator.
---------------------------------------------------------------------------

    <bullet> Constrain the QDM: Working with CMS and NQF, we have 
considered the creation of a draft ``style guide'' to constrain the QDM 
in a manner that would identify a subset of data types and their 
associated attributes that we believe EHR technology could reasonably 
be expected to be captured. Measure stewards would then need to 
constrain CQMs to reference only data elements that are within the 
boundaries of the data types/attribute pairs expressed in the 
constrained QDM style guide. Such CQMs would be identified as ``2014-
EHR-ready'' while other CQMs would not. We would subsequently 
collaborate with CMS to remove CQMs that do not qualify as ``2014-EHR-
ready'' from the EHR Incentive Programs requirements and, as discussed 
above, could add certification criteria in our final rule in order to 
explicitly define the data types and attributes that will be necessary 
for complete CQM data capture according to the constrained QDM style 
guide. This option would serve to align the capabilities of EHR 
technology with the expectations of CQMs and would provide a solid path 
toward an additional alignment of CQMs with CDS for future stages of 
the EHR Incentive Programs. CDS can provide the interactive capability 
that would be required in order to capture the granular exclusion data 
that is expected today by many CQMs. With the inclusion of CDS in the 
clinical quality improvement strategy for future stages of this 
program, we expect to be able to remove the flexibility outlined above 
for the capture of ``reason'' attributes. This would improve the 
accuracy of CQMs while retaining optimal clinical workflow, as CDS 
would ideally be engaged to prompt for this information only where 
indicated, rather than in all cases. We seek public comment, especially 
from measure stewards, as to the difficulty and timeliness with which 
CQMs could be re-specified in accordance with the constrained QDM style 
guide.
    <bullet> Explicit Data Capture List: Another approach we considered 
instead of specifying the QDM would be to publish the complete list of 
unique data elements that would be required for data capture in order 
to be assured that CQMs could be calculated. The advantage of this list 
is that it would provide explicit guidance to EHR technology developers 
and could potentially reduce the upfront work that each individual EHR 
technology developer would need to do in order to prepare their EHR 
technology for certification.
Data Export
    Equally fundamental to data capture is the ability of EHR 
technology to put the data that has been captured to use. Thus, we 
believe that it is prudent to propose that EHR technology presented for 
certification not only be able to capture data for CQMs based on the 
QDM, but be able to export this data as it is represented in the QDM in 
the event that an EP, EH, or CAH chooses to use another certified EHR 
Module to perform the calculation of CQM results--which is why we 
include the export capability as part of the certification criterion 
proposed at Sec.  170.314(c)(1). We recognize that in many care 
delivery settings, CQM calculation and reporting may occur through the 
use of different EHR technologies from those used to capture data. For 
example, certified EHR Module <greek-i>1 may be part of an EH's Base 
EHR, but the EH may use certified EHR Module <greek-i>2 to perform the 
analytics needed for CQM calculation and reporting. By requiring that 
all EHR technology presented for certification capture CQM data and 
also export the data, we believe EPs, EHs, and CAHs would be provided 
the flexibility to use separate EHR Modules for calculation and/or 
reporting, even if they have purchased or licensed an integrated 
solution.
    We believe this approach preserves portability and flexibility and 
offers the EPs, EHs, and CAHs the option of using regional or national 
CQM calculation and/or reporting solutions, such as registries or other 
types of data intermediaries that could obtain modular certification 
for the services that they offer. We are unaware of the existence of a 
widely adopted standard to export captured CQM data. Thus, for 
certification, it would be at the EHR technology developer's discretion 
to determine the format of the data file that its EHR technology would 
be able to produce as well as whether the data would be exported in 
aggregate or by individual patients. While this scenario is not ideal, 
we believe that it could also create a market in which EHR Modules 
focused on CQM calculation (and reporting) could be designed to exploit 
the disparate data files that EHR technologies produce. We request 
comment on whether any standards (e.g., QRDA category 1 or 2, or 
Consolidated CDA) would be adequate for CQM data export as well as 
whether Complete EHRs (that by definition would include calculation and 
reporting capabilities) should be required to be capable of data 
export.
Calculation
    In the S&CC July 2010 final rule (75 FR 44611) and finalized in the 
respective certification program rules (75 FR 36170, 76 FR 1276), we 
discussed requirements that ONC-Authorized Testing and Certification 
Bodies (ONC-ATCBs) and ONC-Authorized Certification Bodies (ONC-ACBs) 
must report to ONC the CQMs to which a Complete EHR or EHR Module has 
been certified and that ONC-ATCBs and ONC-ACBs must ensure that 
Complete EHR and EHR Module developers include on their Web sites and 
in all marketing materials, communications statements, and other 
assertions related to a Complete EHR or EHR Module's certification the 
CQMs to which the Complete EHR or EHR Module was certified. These 
requirements can be found at Sec.  170.423(h)(5) and (k)(1)(ii) and

[[Page 13853]]

Sec.  170.523(f)(5) and (k)(1)(ii). The posting of this information on 
the Certified HIT Products List (CHPL) combined with Complete EHR and 
EHR Module developers making this information available in association 
with their certified Complete EHRs and EHR Modules provides both 
transparency and useful information for potential purchasers (e.g., 
EPs, EHs, and CAHs) that are trying to determine what EHR technology 
best meets their needs.
    In the S&CC July 2010 final rule, we adopted at Sec.  170.304(j) 
the CQM certification criterion for EHR technology designed for an 
ambulatory setting. As expressed in the S&CC July 2010 final rule and 
in ONC FAQ 9-10-012 \35\ and CMS FAQ 10649,\36\ this certification 
criterion was treated as a threshold. In other words, if an EHR 
technology included all 6 of the core CQMs specified by CMS and at 
least 3 other additional CQMs, it could meet the certification 
criterion, and if there was an additional CQM that the EHR technology 
included, CMS permitted the EP to report on that CQM, even though it 
was not expressly listed on the CHPL. Some EHR technology developers 
sought certification to only the 9 CQMs required to meet the threshold, 
and thus the criterion, but subsequently communicated to EPs that their 
EHR technology was certified for all of the CQMs it included. Other EHR 
technology developers took the opposite approach and sought 
certification for more than the 9 CQMs. Those EHR technologies were 
consequently listed on the CHPL as being certified to more CQMs. We 
seek to eliminate this disparity by proposing that EHR technology 
presented for certification to Sec.  170.314(c)(2) would need to be 
certified to each and every individual CQM for which the EHR technology 
developer seeks to indicate its EHR technology is certified. We believe 
this approach provides transparency and greater certainty regarding the 
``certified CQMs'' that EHR technology includes, given CMS' proposal to 
only permit EPs, EHs, and CAHs to report on CQMs with EHR technology 
that has been certified to capture and calculate those CQMs.
---------------------------------------------------------------------------

    \35\ http://healthit.hhs.gov/portal/server.pt/community/onc_regulations_faqs/3163/faq_12/20774.
    \36\ https://questions.cms.hhs.gov/app/answers/detail/a_id/10649.
---------------------------------------------------------------------------

    As noted above, we anticipate that in many cases the calculation of 
CQMs could be performed by an EHR technology that is different from the 
one that was certified to capture the CQM data. For this reason, we 
propose a separate certification criterion for the calculation of CQMs. 
We believe this separation enables market flexibility and creates room 
for innovation. The certification criterion we propose includes two 
specific capabilities. The first capability would require that EHR 
technology presented for certification would need to be able to 
electronically incorporate all of the data elements necessary to 
calculate CQMs for which it is to be certified. In cases where an EHR 
technology developer presents an EHR technology for certification that 
is also being certified to Sec.  170.314(c)(1) and (3) (i.e., the EHR 
technology would be able to do all three capabilities: Capture, 
calculate, and report), we do not believe that it would be necessary 
for an EHR technology to demonstrate its compliance to Sec.  
170.314(c)(2)(i). However, we specifically request public comment on 
this assumption before we will add this exception to the certification 
criterion, which we may do in our final rule. In all other cases, an 
EHR technology would need to meet Sec.  170.314(c)(2)(i) and (ii).
    The second specific capability, Sec.  170.314(c)(2)(ii), focuses on 
an EHR technology's ability to calculate each CQM for which it is 
presented for certification. For example, if an EHR technology is 
presented for certification with test results for 20 CQMs, then the 
most CQMs that could be included as part of its certification and 
listed on the CHPL would be 20. Furthermore, an ONC-ACB would need to 
review each of the 20 CQMs for which the EHR technology is presented 
for certification and make a separate determination as to whether the 
calculation test results for each CQM are satisfactory and accurate. It 
is our expectation that EHR technology certified to this criterion 
would be capable of accurately, and without errors, calculating CQMs. 
We expect the accuracy of these calculations would be verified through 
thorough testing. We request public comment, especially from measure 
stewards and EHR technology developers, on the best way for CQM test 
data sets to be developed.
    Given the separation between capture and calculation, combined with 
CMS's policy that only CQMs calculated by CEHRT would count for 
attestation and electronic submission, we could foresee a scenario 
where an EP's, EH's, or CAH's CEHRT (composed of certified EHR 
Modules--perhaps from different vendors) could capture more data than 
it is certified to calculate. We recognize that this scenario could 
present challenges for providers who possess licenses to such 
mismatched certified EHR modules and we request comment regarding this 
scenario and its likelihood and any additional methods we could employ 
to mitigate this risk.
Reporting
    The last CQM-oriented certification criterion we propose would 
require EHR technology to enable a user to electronically create for 
transmission CQM results in a data file defined by CMS. We expect that 
this capability would require EHR technology to generate an eXtensible 
Markup Language (XML) data file with aggregate CQM calculation results 
in the format CMS would have the capacity to accept. Similar to other 
CMS quality programs' reporting requirements, we expect that CMS would 
make available the XML data file template in time for us to adopt it in 
our final rule. We believe that this approach gives EPs, EHs, and CAHs 
a default solution for reporting CQMs electronically. We note that if 
EPs, EHs, and CAHs elect to use their CEHRT to pursue an alternative 
reporting mechanism permitted by CMS for the EHR Incentive Programs, 
then it would be the EP, EH, or CAH's responsibility for ensuring 
compliance with the alternative mechanism's requirements.

    <bullet> Auditable events and tamper-resistance; and audit 
report(s)

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Protect electronic health information created or maintained by the
 Certified EHR Technology through the implementation of appropriate
 technical capabilities.
------------------------------------------------------------------------
2014 Edition EHR Certification Criteria
Sec.   170.314(d)(2) (Auditable events and tamper-resistance)
Sec.   170.314(d)(3) (Audit report(s))
 
Standard
Sec.   170.210(e) (Record actions related to electronic health
 information, audit log status, and encryption of end user devices)
------------------------------------------------------------------------

    The HITSC recommended two revised certification criteria--one 
focused on the capability to record auditable events and another 
focused on the capability to create audit reports--in place of the 
single 2011 Edition EHR certification criterion for audit logs adopted 
at Sec.  170.302(r). It also recommended, for clarity, that we move the 
specific capability ``detection'' from the integrity certification 
criterion (Sec.  170.302(s)(3)) to the proposed auditable events and 
tamper-resistance certification criterion. Further, it recommended two 
versions of this certification criterion. We agree with the HITSC's 
recommendations because they provide more flexibility and are 
consistent with the stakeholder feedback we have received since the 
publication of the S&CC July 2010 final rule. As for the two 
recommended

[[Page 13854]]

versions of the certification criterion, we propose a certification 
criterion that combines both recommended versions.
    Stakeholder feedback has indicated that splitting this 2011 Edition 
certification criterion into two separate certification criteria would 
permit a wider variety of EHR technologies to be certified as EHR 
Modules. We have also expanded upon the scope of the HITSC's 
recommendation to address input from the HHS Office of Inspector 
General (May 2011 report \37\) and reflect our general belief that a 
more stringent certification policy for audit logs will ultimately 
assist EPs, EHs, and CAHs to better detect and investigate breaches. 
This expansion includes the specific capabilities that the audit log 
must be enabled by default (i.e., turned on), immutable (i.e., unable 
to be changed, overwritten, or deleted), and able to record not only 
which action(s) occurred, but more specifically the electronic health 
information to which the action applies. The proposed certification 
criterion would also require that the ability to enable and disable the 
recording of actions be limited to an identified set of users (e.g., 
system administrator). Further, to accommodate these changes, we are 
proposing a revised standard at Sec.  170.210(e) and proposing to 
require that: (1) When the audit log is enabled or disabled, the date 
and time (in accordance with the standard specified at Sec.  170.210(g) 
(synchronized clocks)), user identification, and the action(s) that 
occurred must be recorded; and (2) as applicable, when encryption for 
end-user devices managed by EHR technology is enabled or disabled, the 
date and time (in accordance with the standard specified at Sec.  
170.210(g) (synchronized clocks)), user identification, and the actions 
that occurred must be recorded.
---------------------------------------------------------------------------

    \37\ http://oig.hhs.gov/oas/reports/other/180930160.pdf.
---------------------------------------------------------------------------

    We did not use the phrase ``security-relevant events'' in the 
standard, as recommended by the HITSC, because we believe it is 
ambiguous and provides insufficient guidance in terms of what 
constitutes an event that would need to be audited. Rather, we believe 
that the proposed minimum set of actions that would be required to be 
captured provides greater clarity for EHR technology developers and 
allows for consistent testing. Finally, we acknowledge, as recommended 
by the HITSC, that an example implementation specification which could 
be followed in designing EHR technology to meet these certification 
criteria could include, but is not limited to ASTM E2147-01, Standard 
Specification for Audit and Disclosure Logs for Use in Health 
Information Systems. We propose to adopt these revised certification 
criteria at Sec.  170.314(d)(2) and (3); and the revised standard at 
Sec.  170.210(e).

    <bullet> Encryption of data at rest

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Protect electronic health information created or maintained by the
 Certified EHR Technology through the implementation of appropriate
 technical capabilities.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(d)(7) (Encryption of data at rest)
------------------------------------------------------------------------

    The HITSC recommended that we revise the ``general encryption'' 
certification criterion adopted at Sec.  170.302(u) in favor of a 
certification criterion focused on the capability of EHR technology to 
encrypt and decrypt electronic health information managed by EHR 
technology on end-user devices if such electronic health information 
would remain stored on the devices after use of EHR technology on that 
device has stopped. Their rationale, with which we agree, was that this 
approach would be more practical, effective, and easier to implement 
than the otherwise general encryption requirement adopted at Sec.  
170.302(u). Further, we interpret this HITSC recommendation to suggest 
that we should focus more attention on promoting EHR technology to be 
designed to secure electronic health information on end-user devices 
(which are often a contributing factor to a breach of unsecured 
protected health information \38\). The OIG provided similar rationale 
in its May 2011 report (cited above) in which it recommended that ONC 
address IT security controls for encrypting data on mobile devices. 
Additionally, we understand that the HITSC intended to recommend a 
certification criterion that would complement already existing HHS 
policy related to breaches of unsecured protected health information 
(i.e., the guidance from the HHS Office for Civil Rights on rendering 
unsecured protected health information unusable, unreadable, or 
indecipherable to unauthorized individuals \39\). As noted in the 
guidance provided by the HHS Office for Civil Rights, NIST Special 
Publication (SP) 800-111 \40\ serves as a resource to guide how 
encryption should be applied to end-user devices.
---------------------------------------------------------------------------

    \38\ http://www.hhs.gov/ocr/privacy/hipaa/administrative/breachnotificationrule/breachrept.pdf.
    \39\ http://www.hhs.gov/ocr/privacy/hipaa/administrative/breachnotificationrule/brguidance.html.
    \40\ http://csrc.nist.gov/publications/nistpubs/800-111/SP800-111.pdf.
---------------------------------------------------------------------------

    This proposed certification criterion is drafted to permit EHR 
technology developers to demonstrate in one of two ways that a Complete 
EHR or EHR Module is compliant. The first way, Sec.  170.314(d)(7)(i), 
accounts for circumstances in which EHR technology is designed to 
manage electronic health information on end-user devices \41\ and on 
which electronic health information would remain stored on the end-user 
devices after use of the EHR technology on the devices has stopped. We 
use ``stopped'' to mean that the session has been terminated, including 
the termination of the network connection. In these circumstances, EHR 
technology presented for certification must be able to encrypt the 
electronic health information that remains on end-user devices. And, to 
comply with paragraph (d)(7)(i), this capability must be enabled (i.e., 
turned on) by default and only be permitted to be disabled (and re-
enabled) by a limited set of identified users. We did not include 
``decrypt'' in the proposed certification criterion because we believe 
that the critical capability to require for certification is the act of 
encryption after use of the EHR technology on the end-user device has 
stopped. We presume that EHR technology developers would also include 
the capability to decrypt the electronic health information, when 
appropriate; otherwise subsequent use or access to the data would not 
be possible. We use the phrase ``manages electronic health 
information'' in this certification criterion to mean that the EHR 
technology is designed in a way that it can exert control over the 
electronic health information that remains on an end-user device after 
the use of EHR technology on that device has stopped. For example, if 
an EHR technology is designed to manage a client application that can 
be executed on a laptop or tablet, and electronic health information 
would remain stored--even in temporary storage--on that end-user device 
when a user stops using the client application on the laptop or tablet, 
the EHR technology would need to meet the requirements

[[Page 13855]]

specified at Sec.  170.314(d)(7)(i) in order to be certified.
---------------------------------------------------------------------------

    \41\ Consistent with NIST SP 800-111, we consider ``end-user 
devices'' to include, but not be limited to: personal computers, 
laptops, smart phones, tablet computers, external memory devices and 
similar removable storage media (e.g., universal serial bus [USB] 
flash drive, memory card, external hard drive, writeable or re-
writeable CD or DVD).
---------------------------------------------------------------------------

    We recognize that in some scenarios EHR technology may not be 
designed to manage electronic health information on the end-user 
devices on which a user may ultimately choose to store electronic 
health information. For example, an EHR technology may not be designed 
to manage electronic health information on a USB-drive, but a user may 
choose to store electronic health information from the EHR technology 
on such an end-user device. We wish to make clear that in order to 
comply with this certification criterion, an EHR technology developer 
would not need to anticipate such scenarios. More specifically, the EHR 
technology developer would not have to demonstrate for certification 
that the EHR technology could encrypt electronic health information on 
the USB-drive (or similar end-user device) since the EHR technology was 
not designed to manage electronic health information on that USB-drive. 
We further note that if a user chooses to store electronic health 
information on an end-user device on which EHR technology was not 
designed to manage electronic health information, then the user would 
be responsible for ensuring such information is protected in accordance 
with applicable law.
    The second way to demonstrate compliance with this certification 
criterion would be for an EHR technology developer to demonstrate that 
its EHR technology can meet Sec.  170.314(d)(7)(ii) and prove that 
electronic health information managed by EHR technology never remains 
on end-user devices after use of EHR technology on those devices has 
stopped. We believe this alternative method is important to include 
because it: (1) Verifies as part of certification that the EHR 
technology was, in fact, designed in a way such that it does not enable 
electronic health information to remain on end-user devices after use 
of EHR technology on those devices has stopped; (2) Provides EHR 
technology developers a way to demonstrate compliance with this 
certification criterion; and (3) It encourages an outcome that is more 
secure (i.e., when no electronic health information is permitted to 
remain, the potential for a breach is mitigated). An example of this 
circumstance would be a situation where an EHR technology is designed 
to manage a client application on an end-user device (locally or over 
the Internet) and the client application enables the user to complete a 
full suite of actions related to electronic health information. Once 
the use of EHR technology on the end-user device has stopped, the 
electronic health information does not remain on the device on which 
the client application was executed.
    We propose to adopt this revised certification criterion at Sec.  
170.314(d)(7).

    <bullet> 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.
------------------------------------------------------------------------
2014 Edition EHR Certification Criteria
Sec.   170.314(f)(1) (Immunization information)
Sec.   170.314(f)(2) (Transmission to immunization registries)
 
Standards and Implementation Specifications
Sec.   170.205(e)(3) (HL7 2.5.1 and Implementation Guide for
 Immunization Messaging Release 1.3); and
Sec.   170.207(i) (CVX code set: August 15, 2011 version)
------------------------------------------------------------------------

    The HITSC recommended that we consider splitting this certification 
criterion into two criteria--one focused on the data capture and the 
other focused on the formatting of such data in the proposed standards 
and implementation specifications. We have followed this recommendation 
and propose two separate certification criteria. We believe this 
approach could enable additional EHR technologies (likely in the form 
of EHR Modules) to be certified and provides additional pathways and 
flexibility to EPs, EHs, and CAHs to have EHR technology that can be 
used to satisfy the proposed revised definition of CEHRT. We note that 
we are discussing these criteria together for simplicity and to prevent 
confusion, but we do not consider the certification criterion we 
propose to focus on data capture to be a ``revised'' certification 
criterion. Rather, we believe that the certification criterion proposed 
at Sec.  170.314(f)(1) constitutes an unchanged certification criterion 
because all the capabilities included in the criterion are the same as 
the capabilities included in the corresponding 2011 Edition EHR 
certification criterion (Sec.  170.302(k)).
    For the certification criterion proposed at Sec.  170.314(f)(1), 
consistent with our discussion in the preamble section titled 
``Explanation and Revision of Terms Used in Certification Criteria,'' 
we have replaced the terms ``retrieve'' and ``modify'' in the revised 
criterion with ``access'' and ``change,'' respectively. For the 
certification criterion proposed at Sec.  170.314(f)(2), we have stated 
the ``transmission capability'' as the capability to electronically 
create immunization information for electronic transmission in 
accordance with the applicable standards and implementation 
specifications. We clarify that this criterion focuses on the 
capability of EHR technology to properly create for transmission 
immunization information in accordance with the applicable standards 
and implementation specifications. The criterion does not address the 
ability to query and evaluate immunization history from the 
immunizations information systems (IIS) to determine a patient's 
vaccination need, nor does it address the specific connectivity 
requirements that an EP, EH, or CAH would need to establish or meet to 
successfully transmit immunization information, as such requirements 
are likely to vary from State to State and are outside the scope of 
certification.
    The HITSC recommended, and we agree, that the use of only the HL7 
2.5.1 standard should be permitted for submitting immunization 
information because immunization registries are rapidly moving to this 
standard. In consultation with the Centers for Disease Control and 
Prevention, we also propose to adopt the HL7 2.5.1 Implementation Guide 
for Immunization Messaging Release 1.3 as the implementation 
specification. This release provides corrections and clarifications to 
Release 1.0 and contains new guidance on how to message vaccines for 
children (VFC) eligibility. Finally, we propose to adopt the August 15, 
2011 version of CVX code sets. We propose to adopt the revised 
certification criteria for the 2014 Edition EHR certification criteria 
at Sec.  170.314(f)(1) and (2). We propose to adopt the HL7 2.5.1 
standard with implementation guide at Sec.  170.205(e)(3) and the CVX 
code set at Sec.  170.207(i).

    <bullet> Public health agencies

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Capability to submit electronic syndromic surveillance data to public
 health agencies except where prohibited, and in accordance with
 applicable law and practice.
------------------------------------------------------------------------
2014 Edition EHR Certification Criteria
Sec.   170.314(f)(3) (Public health surveillance)
Sec.   170.314(f)(4) (Transmission to public health agencies)
 
Standards and Implementation Specifications
Sec.   170.205(d)(2) (HL7 2.5.1) and Sec.   170.205(d)(3) (HL7 2.5.1 and
 the PHIN Messaging Guide for Syndromic Surveillance: Emergency
 Department and Urgent Care Data HL7 Version 2.5.1)
------------------------------------------------------------------------


[[Page 13856]]

    Similar to the immunization certification criteria above, the HITSC 
recommended that we consider splitting the public health surveillance 
certification criterion into two separate certification criteria. We 
have followed this recommendation, and we have made similar wording 
changes to these proposed certification criteria for the same reasons 
expressed in the revisions to the certification criteria for 
immunization information and transmission. As noted under the proposed 
immunization certification criteria, we are discussing these two 
proposed syndromic surveillance criteria together for simplicity and to 
prevent confusion, but we do not consider the certification criterion 
we propose to focus on data capture to be a ``revised'' certification 
criterion. Rather, we believe that the certification criterion proposed 
at Sec.  170.314(f)(3) constitutes an unchanged certification criterion 
because all the capabilities included in the criterion are the same as 
the capabilities included in the corresponding 2011 Edition EHR 
certification criterion (Sec.  170.302(l)).
    The HITSC recommended and we agree that the use of only the HL7 
2.5.1 standard should be permitted for formatting syndrome-based public 
health surveillance information because public health agencies are 
rapidly moving to this standard and all stakeholders would benefit from 
focusing on a single public health surveillance standard. The HITSC 
also recommended and we agree that the standard be constrained for 
hospitals with the PHIN Messaging Guide for Syndromic Surveillance: 
Emergency Department and Urgent Care Data HL7 Version 2.5.1. We also 
believe that certification of ambulatory EHR technology to this guide 
can be useful for EHR developers that provide EHR technology to 
eligible professionals that practice in urgent care settings. 
Therefore, we propose that certification to this guide be optional for 
the ambulatory setting. We propose to adopt the revised certification 
criteria for the 2014 Edition EHR certification criteria at Sec.  
170.314(f)(3) and (4) and the HL7 2.5.1 standard and implementation 
guide for the inpatient setting (and optional for the ambulatory 
setting) at Sec.  170.205(d)(3). The required exchange standard for the 
ambulatory setting has already been adopted at Sec.  170.205(d)(2).

    <bullet> Automated measure calculation

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
N/A
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(g)(2) (Automated measure calculation)
------------------------------------------------------------------------

    We propose to adopt a revised automated measure calculation 
certification criterion for the 2014 Edition EHR certification 
criteria. We have revised the certification criterion to clearly 
identify that the recording, calculating, and reporting capabilities 
required by this certification criterion apply to the numerator and 
denominator associated with the capabilities that support an MU 
objective with a percentage-based measure. To be clear, the 
capabilities to which we refer are the capabilities included in the 
certification criteria to which the EHR technology is presented for 
certification.
    We want to emphasize that testing to this certification criterion 
would not only include verification of the ability of EHR technology to 
generate numerators and denominators, but would also verify the 
accuracy of the numerators and denominators generated by the EHR 
technology. We believe that testing to ensure the accuracy of these 
calculations would significantly reduce the reporting burden for MU 
attestation. Additionally, testing and certification to this proposed 
revised certification criterion would include testing and certifying 
the ability to electronically record the numerator and denominator and 
create a report including the numerator, denominator, and resulting 
percentage associated with each applicable MU measure that is supported 
by a capability in the new certification criteria proposed in this rule 
that are adopted in a final rule.
    We propose to adopt this revised certification criterion at Sec.  
170.314(g)(2).
b. Ambulatory Setting
    We propose to adopt the following revised certification criteria 
for the ambulatory setting.

    <bullet> Electronic prescribing

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objectives
Generate and transmit permissible prescriptions electronically (eRx).
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(b)(3) (Electronic prescribing)
 
Standards
Sec.   170.205(b)((2) (NCPDP SCRIPT version 10.6) and Sec.   170.207(h)
 (RxNorm February 6, 2012 Release)
------------------------------------------------------------------------

    The HITSC recommended that we adopt a revised certification 
criterion for the ambulatory setting that required the use of RxNorm as 
the vocabulary standard. We agree that RxNorm should be adopted as the 
vocabulary standard instead of the current adopted standard which 
specifies any source vocabulary that is included in RxNorm. 
Additionally, with respect to content exchange standards, we are 
proposing to no longer include the use of NCPDP SCRIPT version 8.1 as a 
way to meet the 2014 Edition EHR certification criterion because we 
understand that CMS is planning to propose retiring this standard 
(adopted as a Medicare Part D e-prescribing standard) in a proposed 
rule that is scheduled to be issued soon after this proposed rule is 
published. If we should receive information indicating a change in CMS' 
plans prior to the issuance of our final rule, we may, based also on 
public comment, reinstate this standard in a final revised 
certification criterion. We believe that it is appropriate for this 
certification criterion to be adopted for both the ambulatory and 
inpatient settings (as discussed under the proposed new certification 
criteria section) as it supports our desired policy and 
interoperability outcome for content exchange standards to be used when 
information is exchanged between different legal entities. We propose 
to adopt this revised certification criterion at Sec.  170.314(b)(3) 
and the February 6, 2012 Release of the RxNorm standard at Sec.  
170.207(h).

    <bullet> Clinical summaries

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Provide clinical summaries for patients for each office visit.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(e)(2) (Ambulatory setting only--clinical summaries)
 
Standards
Sec.   170.205(a)(3) (Consolidated CDA); Sec.   170.207(f) (OMB
 standards for the classification of federal data on race and
 ethnicity); Sec.   170.207(j) (ISO 639-1:2002 (preferred language));
 Sec.   170.207(l) (smoking status types);
Sec.   170.207(a)(3) (SNOMED-CT[supreg] International Release January
 2012); Sec.   170.207(m) (ICD-10-CM); Sec.   170.207(b)(2) (HCPCS and
 CPT-4) or Sec.   170.207(b)(3) (ICD-10-PCS); Sec.   170.207(g) (LOINC
 version 2.38); and Sec.   170.207(h) (RxNorm February 6, 2012 Release)
------------------------------------------------------------------------

    The HITSC recommended that the certification criterion be revised 
for the 2014 Edition EHR certification criteria to reflect the proposed 
new and revised standards for problem lists and other vocabulary 
standards. We agree with these recommendations. We have made several 
refinements to the recommended revised certification criterion to 
ensure that EHR technology meets the appropriate standards and is 
capable of making available the information CMS

[[Page 13857]]

is proposing be provided to a patient after an office visit.
    We further propose that when information is provided 
electronically, the information be provided according to the 
Consolidated CDA standard. For the same reasons as provided in the new 
``view, download, and transmit to 3rd party'' certification criterion 
discussion, we believe that adopting the Consolidated CDA for this 
certification criterion is advantageous since its template structure 
can accommodate the formatting of a summary care record that includes 
all of the data elements that CMS is proposing be provided to a patient 
after an office visit. As we similarly noted in the discussion of the 
transitions of care certification criteria (Sec.  170.314(b)(1) and 
(2)), we considered, but have not proposed, adopting separate 
certification criteria to explicitly require the capture of unique data 
elements included in clinical summaries, such as care plans and future 
scheduled tests. We welcome public comment on whether we should adopt 
separate certification criteria for these data elements. For certain 
other data elements in Sec.  170.314(e)(2), we propose to require that 
the capability to provide the information be demonstrated in accordance 
with the specified vocabulary standard. These vocabulary standards have 
been previously adopted or are proposed for adoption in this proposed 
rule, consistent with the recommendations of the HITSC. We propose to 
adopt this revised certification criterion for the 2014 Edition EHR 
certification criteria at Sec.  170.314(e)(2).
c. Inpatient Setting
    We propose to adopt the following revised certification criteria 
for the inpatient setting.
    <bullet> 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.
------------------------------------------------------------------------
2014 Edition EHR Certification Criteria
Sec.   170.314(f)(5) (Inpatient setting only--reportable laboratory
 tests and values/results)
Sec.   170.314(f)(6) (Inpatient setting only--transmission of reportable
 laboratory tests and values/results)
 
Standards and Implementation Specifications
Sec.   170.205(g) (HL7 2.5.1 and HL7 Version 2.5.1 Implementation Guide:
 Electronic Laboratory Reporting to Public Health, Release 1 (US Realm)
 with errata); Sec.   170.207(a)(3) (SNOMED CT[supreg] International
 Release January 2012); and Sec.   170.207(g) (LOINC version 2.38)
------------------------------------------------------------------------

    Similar to the immunization and syndromic surveillance 
certification criteria above, the HITSC recommended that we consider 
splitting the ``reportable laboratory results'' certification criterion 
into two separate certification criteria. We have followed this 
recommendation, and for the same reasons expressed above, we have made 
similar wording changes to these proposed certification criteria. Also, 
as noted under the proposed immunization and syndromic surveillance 
certification criteria, we are discussing these two proposed laboratory 
tests and values/results certification criteria together for simplicity 
and to prevent confusion, but we do not consider the certification 
criterion we propose to focus on data capture to be a revised 
certification criterion. Rather, we believe that the certification 
criterion proposed at Sec.  170.314(f)(5) constitutes an unchanged 
certification criterion because all the capabilities included in the 
criterion are the same as the capabilities included in the 
corresponding 2011 Edition EHR certification criterion (Sec.  
170.306(g)).
    The HITSC recommended that we maintain the use of only the HL7 
2.5.1 standard and that we adopt the most current version of LOINC as 
the vocabulary standard. We agree and propose to adopt LOINC version 
2.38 as the vocabulary standard as it is the most recent version. Based 
on our consultation with the Centers for Disease Control and 
Prevention, we also propose to adopt HL7 Version 2.5.1 Implementation 
Guide: Electronic Laboratory Reporting to Public Health, Release 1 (US 
Realm) with errata and SNOMED CT[supreg] International Release January 
2012 version. This version of the implementation guide contains 
corrections and will require minor changes to conformance testing and 
certification to account for newly assigned OIDs (object identifiers) 
identifying the message profiles in the implementation guide. The 
International Release January 2012 version of SNOMED CT[supreg] is the 
most recent version and SNOMED CT[supreg] is required by the 
implementation guide, as is LOINC. We propose to adopt the revised 
certification criteria for the 2014 Edition EHR certification criteria 
at Sec.  170.314(f)(5) and (6). We propose to adopt the HL7 2.5.1 
standard with the revised implementation guide at Sec.  170.205(g). We 
propose to adopt the version of SNOMED CT[supreg] at Sec.  
170.207(a)(3) and LOINC version 2.38 standard at Sec.  170.207(g).
6. Unchanged Certification Criteria
    In our prior rulemakings, we did not expressly describe what we 
considered to be ``unchanged'' certification criteria. Based on our 
experience with this rulemaking, we take this opportunity to describe 
the certification criteria that we would consider unchanged. We would 
consider the following factors in determining whether a certification 
criterion is unchanged:
    <bullet> The certification criterion includes only the same 
capabilities that were specified in previously adopted certification 
criteria;
    <bullet> The certification criterion's capabilities apply to the 
same setting as they did in previously adopted certification criteria; 
and
    <bullet> The certification criterion remains designated as 
``mandatory,'' or it is re-designated as ``optional,'' for the same 
setting for which it was previously adopted certification criterion.
    For clarity, we explain that an unchanged certification criterion 
could be a certification criterion that includes capabilities that were 
merged from multiple previously adopted certification criteria as long 
as the capabilities specified by the merged certification criterion 
remain the same. The ``authentication, access control, and 
authorization'' certification criterion discussed below and proposed 
for adoption at Sec.  170.314(d)(1) meets this description. 
Additionally, an unchanged certification criterion could be a 
certification criterion that has fewer capabilities than a previously 
adopted certification criterion as long as the capabilities that remain 
stay the same. The ``integrity'' certification criterion discussed 
below and proposed for adoption at Sec.  170.314(d)(8) meets this 
description. As discussed in the description of revised certification 
criteria, a certification criterion could be characterized differently 
based on the setting to which it applies or the designation it is given 
(``mandatory'' or ``optional''). For example, a certification criterion 
that includes the same capabilities that were specified in a previously 
adopted certification criterion would be considered unchanged for the 
ambulatory setting if the previously adopted certification criterion 
only applied to the ambulatory setting and certification to the 
criterion was ``mandatory.'' However, this same certification criterion 
would be considered new for the inpatient setting

[[Page 13858]]

if it were subsequently adopted for both settings.
    We identify some of the proposed unchanged certification criteria 
included in the 2014 Edition EHR certification criteria below and have 
also identified unchanged certification criteria previously in the 
preamble. As noted, the capabilities included in the certification 
criteria below are the same capabilities that were adopted in 2011 
Edition EHR certification criteria. We propose to add all of these 
unchanged certification criteria to the 2014 Edition EHR certification 
criteria at Sec.  170.314.
a. Refinements to Unchanged Certification Criteria
    We propose to refine the following certification criteria as 
discussed below.

    <bullet> Computerized provider order entry

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
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.
2014 Edition EHR Certification Criterion
Sec.   170.314(a)(1) (Computerized provider order entry)
------------------------------------------------------------------------

    We have merged the separate ambulatory and inpatient CPOE 
certification criteria in the 2011 Edition EHR certification criteria 
into one criterion because they are identical. Consistent with our 
discussion in the preamble section titled ``Explanation and Revision of 
Terms Used in Certification Criteria,'' we have also replaced the terms 
``modify'' and ``retrieve'' with ``change'' and ``access,'' 
respectively. We have also removed the term ``store'' from the 
criterion because it is redundant with our interpretation of the term 
``record.'' Finally, we moved the phrase ``at a minimum'' in the 
sentence to eliminate any possible ambiguity as to what the phrase 
modifies. As the proposed certification criterion is now written, we 
believe it is clear that the phrase modifies the order types and not 
the terms ``record,'' ``change,'' and ``access.''

    <bullet> 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.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(a)(4) (Vital signs, body mass index, and growth charts)
------------------------------------------------------------------------

    Consistent with our discussion in the preamble section titled 
``Explanation and Revision of Terms Used in Certification Criteria,'' 
we have replaced the terms ``modify'' and ``retrieve'' with ``change'' 
and ``access,'' respectively. We have also added the alternative term 
``length'' to go with ``height'' as it is the clinically appropriate 
term for newborns and clarified the intent of the ``vital signs'' 
capability. The only other refinements that we propose are for the plot 
and display growth charts capability. First, we propose that this 
capability be designated ``optional'' within this certification 
criterion because even though this certification criterion is proposed 
to be part of a Base EHR that every EP, EH, and CAH would need to have 
in order to satisfy the proposed revised definition of CEHRT, some EPs, 
EHs, and CAHs would not (or would never) use such a capability due to 
scope of practice or other reasons. Thus, to reduce regulatory burden 
and to not require EHR technology developers to include a specific 
growth chart capability when they do not intend to market their EHR 
technology to EPs, EHs, or CAHs that would use such a capability, we 
have designated it as ``optional'' for certification. In addition, we 
propose to remove the age range reference (2-20 years old) from this 
capability. This is consistent with other certification criteria such 
as ``smoking status'' where the MU objective it supports specifies an 
age threshold (13), but the capability is not dependent on the 
patient's age.

    <bullet> Smoking status

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Record smoking status for patients 13 years old or older.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(a)(11) (Smoking status)
 
Standard
Sec.   170.207(l) (smoking status types)
------------------------------------------------------------------------

    As part of the 2011 Edition EHR certification criteria, the smoking 
status certification criterion is codified at Sec.  170.302(g), 
specifying a list of six smoking status types that EHR technology must 
be capable of recording, modifying, and retrieving. Consistent with our 
discussion in the preamble section titled ``Explanation and Revision of 
Terms Used in Certification Criteria,'' we have replaced the terms 
``modify'' and ``retrieve'' with ``change'' and ``access,'' 
respectively. We also propose to specify the six smoking status types 
included in the 2011 Edition EHR certification criterion as a standard 
at Sec.  170.207(l). This refinement will provide additional clarity 
for the certification criterion and consistency with the structure of 
similar certification criteria.

    <bullet> Patient reminders

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Use clinically relevant information to identify patients who should
 receive reminders for preventive/follow-up care.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(a)(15) (Ambulatory setting only--patient reminders)
------------------------------------------------------------------------

    We clarify and emphasize that EHR technology certified to this 
certification criterion would need to be capable of creating a patient 
reminder list that includes a patient's communication preferences, 
which would be consistent with current testing procedures for this 
capability as included in the 2011 Edition EHR certification criterion 
(Sec.  170.304(d)). We also note that, consistent with patient 
communication preferences, we would anticipate that EPs, EHs, and CAHs 
could use communication mediums made available by EHR technology 
certified to the proposed ``secure messaging'' certification criterion 
(Sec.  170.314(e)(3)) or the ``view, download and transmit to 3rd 
party'' certification criterion (Sec.  170.314(e)(1)) to send patient 
reminders. We also anticipate that other modes of communication would 
be available and may be preferred by patients for sending patient 
reminders, such as regular mail.

    <bullet> 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.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(d)(1) (Authentication, access control, and authorization)
------------------------------------------------------------------------

    As part of the 2011 Edition EHR certification criteria, the 
``access control'' certification criterion is codified at Sec.  
170.302(o) and the ``authentication'' certification criterion is 
codified at Sec.  170.302(t). Based on consultations with NIST, the 
similarity of the two test procedures that were developed for these 
certification criteria, and that these capabilities go hand-in-hand, we 
have determined that it would be best to merge the two certification 
criteria. We believe this would allow for more efficient testing and is 
consistent with EHR technology development.

[[Page 13859]]

Given this proposal, we have adopted in part the recommendations of the 
HITSC, which are reflected in the proposed certification criterion. We 
have also expressed the HITSC's authentication recommendation as 
additional guidance for this certification criterion in that the 
capability to authenticate human users would consist of the assertion 
of an identity and presentation of at least one proof of that identity. 
We intend and believe that it is most appropriate for this 
certification criterion to focus on users that would be able to access 
electronic health information in EHR technology at a EP, EH, or CAH and 
not to focus on external users that may make requests for access to 
health information contained in the EHR technology for the purpose of 
electronic health information exchange. The latter purpose would likely 
require a different/additional security approach(es) and rely on a 
health care provider's overall infrastructure beyond its EHR 
technology. We also acknowledge, as recommended by the HITSC, that 
example standards and implementation specifications which could be 
followed in designing EHR technology to meet this certification 
criterion could include, but are not limited to: NIST Special 
Publication 800-63, Level 2 (single-factor authentication) and ASTM, 
E1986-09 (Information Access Privileges to Health Information).
    <bullet> Automatic log-off


------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Protect electronic health information created or maintained by the
 Certified EHR Technology through the implementation of appropriate
 technical capabilities.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(d)(5) (Automatic log-off)
------------------------------------------------------------------------

    We are not revising or refining this certification criterion as 
part of the proposed 2014 Edition EHR certification criteria, but are 
clarifying that to terminate a session should not be confused with 
locking a session, where access to an active session is permitted after 
re-authentication. EHR technology must have the capability to terminate 
the session, including terminating the network connection.
    <bullet> Emergency access


------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Protect electronic health information created or maintained by the
 Certified EHR Technology through the implementation of appropriate
 technical capabilities.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(d)(6) (Emergency access)
------------------------------------------------------------------------

    We are refining the 2011 Edition EHR certification criterion for 
emergency access codified at Sec.  170.302(p) for the 2014 Edition EHR 
certification criteria by removing the parenthetical ``who are 
authorized for emergency situations'' from the certification criterion 
and including the phrase ``identified set of users'' to more clearly 
convey this certification criterion's intent and to consistently use 
this phrase through every certification criterion where we intend for 
the same capability to be available. The purpose of this criterion is 
to provide certain users (``identified set of users'') with the ability 
to override normal access controls in the case of an emergency. The 
refinement to the criterion coupled with our explanation should provide 
sufficient clarity for testing and certifying to this certification 
criterion.

    <bullet> Integrity

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Protect electronic health information created or maintained by the
 Certified EHR Technology through the implementation of appropriate
 technical capabilities.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(d)(8) (Integrity)
 
Standard
Sec.   170.210(c) (Verification that electronic health information has
 not been altered)
------------------------------------------------------------------------

    The certification criterion at Sec.  170.314(d)(8) is consistent 
with the recommendation and recommended certification criterion by the 
HITSC for the 2014 Edition EHR certification criteria. The capability 
to detect changes to an audit log has been removed from this proposed 
certification criterion and added to the proposed certification 
criterion for ``auditable events and tamper resistance'' at Sec.  
170.314(d)(2). The adopted certification criterion at Sec.  170.304(b) 
specifies that EHR technology must be able to create a message digest 
in accordance with the standard specified at Sec.  170.210(c). The 
adopted standard is: ``A hashing algorithm with a security strength 
equal to or greater than SHA-1 (Secure Hash Algorithm (SHA-1)) * * * 
must be used to verify that electronic health information has not been 
altered.'' After consultation with NIST, we understand that the 
strength of a hash function in digital signature applications is 
limited by the length of the message digest and that in a growing 
number of circumstances the message digest for SHA-1 is too short for 
secure digital signatures (SHA-2 produces a 256-bit message digest that 
is expected to remain secure for a long period of time). We also 
understand that certain operating systems and applications upon which 
EHR technology may rely use SHA-1 and do not or cannot support SHA-2 at 
the present time. Thus, we request public comment on whether we should 
leave the standard as it currently reads or replace SHA-1 with SHA-2.
b. Unchanged Certification Criteria Without Refinements
    The following table (Table 2) identifies the proposed unchanged 
2014 Edition EHR certification criteria and the corresponding 2011 
Edition EHR certification criteria that include the same capabilities 
that are in the proposed unchanged 2014 Edition EHR certification 
criteria. We propose to adopt these certification criteria as part of 
the 2014 Edition EHR certification criteria without any substantial 
refinements, except, consistent with our discussion in the preamble 
section titled ``Explanation and Revision of Terms Used in 
Certification Criteria,'' we have, where appropriate, replaced the 
terms ``generate,'' ``modify,'' and ``retrieve'' with ``create,'' 
``change,'' and ``access,'' respectively. Table 2 also identifies the 
corresponding paragraphs of Sec.  170.314 where the certification 
criteria would be added and the proposed titles of those paragraphs/
certification criteria.

                          Table 2--Unchanged Certification Criteria Without Refinements
----------------------------------------------------------------------------------------------------------------
                      2014 Edition                                             2011 Edition
----------------------------------------------------------------------------------------------------------------
                                   Title of regulation                                      Title of regulation
       Regulation section               paragraph               Regulation section               paragraph
----------------------------------------------------------------------------------------------------------------
170.314(a)(10)..................  Drug-formulary checks  170.302(b)......................  Drug-formulary
                                                                                            checks.
170.314(a)(6)...................  Medication list......  170.302(d)......................  Maintain active
                                                                                            medication list.
170.314(a)(7)...................  Medication allergy     170.302(e)......................  Maintain active
                                   list.                                                    medication allergy
                                                                                            list.
170.314(a)(14)..................  Patient lists........  170.302(i)......................  Generate patient
                                                                                            lists.
170.314(d)(9)...................  Accounting of          170.302(w)......................  Accounting of
                                   disclosures.                                             disclosures.

[[Page 13860]]

 
170.314(a)(18)..................  Advance directives...  170.306(h)......................  Advance directives.
----------------------------------------------------------------------------------------------------------------

7. Gap Certification
    In the Permanent Certification Program final rule (76 FR 1307), we 
explained the concept of ``gap certification'' and defined it at Sec.  
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).'' 
We stated that gap certification will focus on the difference between 
certification criteria that are adopted through rulemaking at different 
points in time. We discussed in section III.A of this preamble the 
factors we would consider in determining whether a proposed 2014 
Edition EHR certification criterion is ``new'' or ``revised.'' Examples 
of new certification criteria are the ``secure messaging'' 
certification criterion we propose for adoption at Sec.  170.314(e)(3) 
and the ``electronic medication administration record'' certification 
criterion we propose for adoption at Sec.  170.314(a)(17). An example 
of a revised certification criterion is the ``CDS'' certification 
criterion we propose for adoption at Sec.  170.314(a)(8). This 
certification criterion is ``revised'' because it would add 
capabilities to the certification criteria for CDS that were previously 
adopted at Sec. Sec.  170.304(e) and 170.306(c). An example of a 
certification criterion that we would consider both new and revised is 
the ``e-prescribing'' certification criterion proposed for adoption at 
Sec.  170.314(b)(3). This certification criterion is a revised 
certification criterion for the ambulatory setting, but would be 
considered a new certification criterion for the inpatient setting.
    For a Complete EHR or EHR Module that was previously certified to 
the 2011 Edition EHR certification criteria to be certified to the 2014 
Edition EHR certification criteria, test results from a NVLAP-
accredited testing laboratory would be required for all of the 
applicable new and revised certification criteria that are adopted. 
However, for the certification criteria that we identify as unchanged, 
test results that were used previously to certify a Complete EHR or EHR 
Module to the 2011 Edition EHR certification criteria identified in 
Table 3 below could be used to certify the Complete EHR or EHR Module 
to the corresponding 2014 Edition EHR certification criteria identified 
in the table. To illustrate, for gap certification, an EHR Module that 
was previously certified to the ``CPOE'' and ``drug-drug, drug-allergy 
interaction checks'' certification criteria (i.e., previously tested 
and certified to Sec.  170.304(a) or Sec.  170.306(a) and Sec.  
170.302(a)) would not need to be retested to the ``CPOE'' certification 
criterion we propose to add to the 2014 Edition EHR certification 
criteria at Sec.  170.314(a)(1) because this criterion has been 
identified as an unchanged certification criterion. However, the 
previously certified EHR Module would need to be retested for ``drug-
drug, drug-allergy interaction checks'' because we have proposed to 
adopt a revised certification criterion for ``drug-drug, drug-allergy 
interaction checks'' as part of the 2014 Edition of EHR certification 
criteria at Sec.  170.314(a)(2). We note, as identified in Table 3, 
that for the proposed certification criterion at Sec.  170.314(b)(5) 
(Incorporate laboratory tests and values/results), EHR technology 
designed for an ambulatory setting would need to be tested by a NVLAP-
accredited testing laboratory because we propose to require that such 
EHR technology meet new standards and implementation specifications, 
while the capabilities required for the inpatient setting are 
unchanged.

 Table 3--Gap Certification: Crosswalk of Unchanged 2014 Edition EHR Certification Criteria to the Corresponding
                                     2011 Edition EHR Certification Criteria
----------------------------------------------------------------------------------------------------------------
                      2014 Edition                                             2011 Edition
----------------------------------------------------------------------------------------------------------------
                                   Title of regulation                                      Title of regulation
       Regulation section               paragraph               Regulation section               paragraph
----------------------------------------------------------------------------------------------------------------
170.314(a)(10)..................  Drug-formulary checks  170.302(b)......................  Drug-formulary
                                                                                            checks.
170.314(a)(6)...................  Medication list......  170.302(d)......................  Maintain active
                                                                                            medication list.
170.314(a)(7)...................  Medication allergy     170.302(e)......................  Maintain active
                                   list.                                                    medication allergy
                                                                                            list.
170.314(a)(4)...................  Vital signs, body      170.302(f)......................  Vital signs.
                                   mass index, and
                                   growth charts.
170.314(a)(11)..................  Smoking status.......  170.302(g)......................  Smoking status.
170.314(b)(5)...................  Incorporate            170.302(h)......................  Incorporate
                                   laboratory tests and                                     laboratory test
                                   values/results.                                          results.
                                  (inpatient setting
                                   only).
170.314(a)(14)..................  Patient lists........  170.302(i)......................  Generate patient
                                                                                            lists.
170.314(f)(1)...................  Immunization           170.302(k)......................  Submission to
                                   information.                                             immunization
                                                                                            registries.
170.314(f)(3)...................  Public health          170.302(l)......................  Public health
                                   surveillance.                                            surveillance.
170.314(d)(1)...................  Authentication,        170.302(o)......................  Access control.
                                   access control, and
                                   authorization.
170.314(d)(6)...................  Emergency access.....  170.302(p)......................  Emergency access.
170.314(d)(5)...................  Automatic log-off....  170.302(q)......................  Automatic log-off.
170.314(d)(8)...................  Integrity............  170.302(s)......................  Integrity.
170.314(d)(1)...................  Authentication,        170.302(t)......................  Authentication.
                                   access control, and
                                   authorization.
170.314(d)(9)...................  Accounting of          170.302(w)......................  Accounting of
                                   disclosures.                                             disclosures.
170.314(a)(15)..................  Patient reminders....  170.304(d)......................  Patient reminders.

[[Page 13861]]

 
170.314(a)(1)...................  CPOE.................  170. 304(a).....................  CPOE.
                                                         170. 306(a).....................
170.314(f)(5)...................  Reportable laboratory  170.306(g)......................  Reportable lab
                                   tests and values/                                        results.
                                   results.
170.314(a)(18)..................  Advance directives...  170.306(h)......................  Advance directives.
----------------------------------------------------------------------------------------------------------------

    As we have previously stated in our rules (75 FR 11351, 76 FR 
1308), we believe gap certification is a less costly and more efficient 
certification option for EHR technology developers to get their EHR 
technologies certified without the time and costs associated with 
retesting to unchanged certification criteria. As we established in the 
permanent certification program final rule (76 FR 1308), however, gap 
certification will only be available under the permanent certification 
program, which we are proposing to rename the ``ONC HIT Certification 
Program.'' We have extended the sunset date of the temporary 
certification program (and delayed the start of the ONC HIT 
Certification Program), which was originally anticipated to be December 
31, 2011. The sunset date will now coincide with the effective date of 
the final rule that will result from this proposed rule (76 FR 68192).

B. Redefining Certified EHR Technology and Related Terms

1. Proposed Revisions to the Definition of Certified EHR Technology
    Certified EHR Technology is defined in section 3000(1) of the PHSA 
as a ``qualified electronic health record that is certified pursuant to 
section 3001(c)(5) as meeting standards adopted under section 3004 that 
are applicable to the type of record involved (as determined by the 
Secretary, such as an ambulatory electronic health record for office-
based physicians or an inpatient hospital electronic health record for 
hospitals).'' In the S&CC July 2010 final rule (75 FR 44590), we 
further defined Certified EHR Technology (CEHRT) at Sec.  170.102 in 
relation to the applicable setting-specific certification criteria 
(ambulatory or inpatient) adopted by the Secretary to mean:
    1. A Complete EHR that meets the requirements included in the 
definition of a Qualified EHR and has been tested and certified in 
accordance with the certification program established by the National 
Coordinator as having met all applicable certification criteria adopted 
by the Secretary; or
    2. A combination of EHR Modules in which each constituent EHR 
Module of the combination has been tested and certified in accordance 
with the certification program established by the National Coordinator 
as having met all applicable certification criteria adopted by the 
Secretary, and the resultant combination also meets the requirements 
included in the definition of a Qualified EHR.
    Under the current definition, EPs, EHs, and CAHs must have 
Certified EHR Technology that has been tested and certified to all 
applicable certification criteria adopted for the setting (ambulatory 
or inpatient) for which it was designed. We refer readers to frequently 
asked question (FAQ) 9-10-017-2 for further explanation.\42\ Since the 
publication of the S&CC July 2010 Final Rule, ONC and CMS have received 
feedback on the definition of CEHRT from numerous stakeholders, 
including EPs, EHs, CAHs, EHR technology developers, and multiple 
associations representing these and other stakeholders. Overall, a 
majority of stakeholders felt that we should change our CEHRT policy to 
provide EPs, EHs, and CAHs the flexibility to have or possess only the 
CEHRT they will use to demonstrate MU. This view was supported by the 
HITSC in their November 16, 2011 recommendation (transmitted to ONC on 
January 17, 2012) that we consider requiring EPs, EHs, and CAHs to 
possess EHR technology that has been certified only to the 
certification criteria that include capabilities they will use to 
attempt to achieve MU. Such a change would mean that the definition of 
CEHRT would be largely determined or driven by how an EP, EH, or CAH 
chooses to accomplish MU rather than requiring certification to all 
certification criteria adopted for an applicable setting (ambulatory or 
inpatient).
---------------------------------------------------------------------------

    \42\ http://healthit.hhs.gov/portal/server.pt?open=512&mode=2&objID=3163&PageID=20779.
---------------------------------------------------------------------------

    We have considered all of the feedback we have received, 
particularly the recommendation of the HITSC, and are proposing a 
revised definition of CEHRT that would provide significantly more 
flexibility for EPs, EHs, and CAHs than exists under the current 
definition. We are convinced by stakeholder feedback and our own 
independent fact-finding that when combined with the complexity of the 
health care delivery environment, the current CEHRT definition has, in 
some cases, introduced challenges for certain EPs, EHs, and CAHs by 
requiring them to have EHR technology they would not necessarily choose 
to use to demonstrate MU under the EHR Incentive Programs. For example, 
under CMS regulations, an EP who has no office visits during the EHR 
reporting period may qualify for an exclusion for the MU objective and 
associated measure requiring clinical summaries to be provided to 
patients for each office visit, but under our current definition of 
CEHRT, the EP must still have EHR technology that supports this 
capability. Accordingly, consistent with the instruction of the 
President's Executive Order (EO) 13563 to identify and consider 
regulatory approaches that reduce burden and maintain flexibility for 
the public, we have decided to propose a revised definition of CEHRT 
that we believe would more closely align with the desired flexibility 
stakeholders have requested while reducing the potential burden 
associated with acquiring EHR technology. We propose to revise the 
definition of CEHRT at Sec.  170.102 to read:
    Certified EHR technology means:
    1. For any Federal fiscal year (FY) or calendar year (CY) up to and 
including 2013:
    i. A Complete EHR that meets the requirements included in the 
definition of a Qualified EHR and has been tested and certified in 
accordance with the certification program established by the National 
Coordinator as having met all applicable certification criteria adopted 
by the Secretary for the 2011 Edition EHR certification criteria or the 
equivalent 2014 Edition EHR certification criteria; or
    ii. A combination of EHR Modules in which each constituent EHR 
Module of the combination has been tested and

[[Page 13862]]

certified in accordance with the certification program established by 
the National Coordinator as having met all applicable certification 
criteria adopted by the Secretary for the 2011 Edition EHR 
certification criteria or the equivalent 2014 Edition EHR certification 
criteria, and the resultant combination also meets the requirements 
included in the definition of a Qualified EHR.
    2. For FY and CY 2014 and subsequent years, the following: EHR 
technology certified under the ONC HIT Certification Program to the 
2014 Edition EHR certification criteria that has:
    i. The capabilities required to meet the definition of a Base EHR; 
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.
    As noted in the ``Executive Summary'' (section I.A) of this 
preamble, FY applies to EHs and CAHs and CY applies to EPs. For the 
first part of the revised definition of CEHRT that would apply for the 
FYs/CYs up to and including 2013, we note two specific changes. The 
first is to include a reference to ``the 2011 Edition EHR certification 
criteria'' in order to make clear that these are the certification 
criteria previously adopted by the Secretary at Sec. Sec.  170.302, 
170.304, and 170.306. This clarification is necessary because if the 
proposed 2014 Edition EHR certification criteria are subsequently 
adopted in a final rule at Sec.  170.314, there would be two 
``editions'' of adopted certification criteria in the CFR. Both the 
2011 Edition and the 2014 Edition EHR certification criteria must be 
effective at the same time for EHR technology to continue to be tested 
and certified to the 2011 Edition EHR certification criteria and so EHR 
technology developers may begin to have their EHR technology tested and 
certified to the 2014 Edition EHR certification criteria.
    The second change would allow EPs, EHs, and CAHs to satisfy the 
definition by having EHR technology certified to the 2014 Edition EHR 
certification criteria that are ``equivalent'' to the 2011 Edition EHR 
certification criteria. We would consider ''equivalent'' certification 
criteria to be those proposed 2014 Edition EHR certification criteria 
that include capabilities that are at least equal to the capabilities 
included in certification criteria that were previously adopted as part 
of the 2011 Edition EHR certification criteria. For a cross-walk 
between 2011 Edition EHR certification criteria and what we would 
consider equivalent proposed 2014 Edition EHR certification criteria, 
see Table 4 below. We believe this revision is necessary and that our 
proposal provides EPs, EHs, and CAHs with the flexibility to adopt or 
upgrade to EHR technology certified to the 2014 Edition EHR 
certification criteria without adversely affecting the certified status 
of previously adopted EHR technology or their ability to meet the 
definition of CEHRT. We note, however, that with respect to CQMs, EPs, 
EHs, and CAHs who adopt or upgrade to EHR technology certified to the 
2014 Edition EHR certification criteria during FY/CY 2012 or FY/CY 2013 
must ensure that their CEHRT will enable them to report on the CQMs 
required for the 2012 and 2013 EHR reporting periods. More 
specifically, the EHR technology required to electronically capture, 
calculate, and report CQMs during those years will be different than 
the EHR technology needed to do the same in FY/CY 2014 and subsequent 
years because CMS has not proposed to change the set of CQMs on which 
EPs, EHs, and CAHs would need to report until FY/CY 2014. Therefore, 
EPs, EHs, and CAHs will need to have EHR technology certified to the 
CQM certification criteria included in the 2011 Edition EHR 
certification criteria to be able to report on the CQMs required for 
the 2012 and 2013 EHR reporting periods. For further guidance, we 
encourage EPs, EHs, and CAHs to read CMS' Stage 2 proposed rule to 
understand the CQMs that would need to be reported for a given EHR 
reporting period.

[[Page 13863]]

[GRAPHIC] [TIFF OMITTED] TP07MR12.000

BILLING CODE 4150-45-C
    The second part of the revised definition of CEHRT that would apply 
beginning with FY/CY 2014 would accomplish four main policy goals:
    1. It defines CEHRT in plain language and makes the definition and 
its requirements readily understandable to EPs, EHs, CAHs, EHR 
technology developers, and other stakeholders.
    2. It continues the progress towards increased interoperability 
requirements

[[Page 13864]]

for EHR technology by requiring all CEHRT to have, at a minimum, the 
capabilities of a Base EHR.
    3. It accounts for stakeholder feedback, which expressed that the 
definition should align more closely with MU requirements under the EHR 
Incentive Programs.
    4. It follows the tenets expressed in EO 13563 by reducing 
regulatory burden, providing more flexibility to the regulated 
community, and making regulatory text more understandable.
    We believe it is important to briefly remind stakeholders that the 
definition of CEHRT does not speak to just one audience. EPs, EHs, and 
CAHs may view the definition of CEHRT in a way that informs them of the 
EHR technology that they must possess to accomplish MU. Alternatively, 
EHR technology developers may see the definition differently and in a 
way that informs them of the potential market demand for certain EHR 
technologies and, more specifically, the EHR technology that their 
customers will need to achieve MU.
    Two types of EHR technology, Complete EHRs and EHR Modules, can be 
certified under the ``ONC HIT Certification Program,'' which is the new 
name we are proposing for the permanent certification program (see 
section IV.A below). Under the revised definition of CEHRT that we are 
proposing for FY/CY 2014 and subsequent years, an EP, EH, or CAH could 
meet the definition with a certified Complete EHR, a single certified 
EHR Module, a combination of separately certified EHR Modules, or any 
combination of the three. For example, an EHR technology developer 
could get an EHR Module certified that would subsequently enable an EP, 
EH, or CAH to have EHR technology that would satisfy the proposed 
revised definition of CEHRT. Alternatively, an EP, EH, or CAH could use 
a certified Complete EHR and a certified EHR Module to meet the 
proposed revised definition of CEHRT.
    Consistent with stakeholder feedback, an EP, EH, or CAH would 
generally not need to have or possess EHR technology in the following 
two scenarios in order to satisfy the proposed revised definition of 
CEHRT for FY/CY 2014 and subsequent years. One scenario would be where 
an EP, EH, or CAH qualifies for an exclusion for a MU objective and 
associated measure. With respect to this scenario, we expect that this 
new flexibility would apply in situations where the MU objective and 
associated measure would not be applicable to the EP, EH, or CAH. In 
most cases, we expect this would occur for EPs based on their scope of 
practice and would be significantly less likely to occur for most EHs 
and CAHs. For example, a dentist will never give immunizations and, 
thus, would not need EHR technology with the capability to submit 
immunization information to immunization registries in order to satisfy 
the proposed revised definition of CEHRT. As another example, and as 
noted earlier, an EP may not have any office visits during an EHR 
reporting period and thus may qualify for the exclusion for the MU 
objective and associated measure requiring clinical summaries to be 
provided to patients for each office visit. Under the proposed revised 
definition of CEHRT, the EP would not need to have EHR technology that 
supports this capability. The second scenario would be where an EP, EH, 
or CAH is able to and has chosen to defer a MU ``menu set'' objective 
and associated measure for a particular stage of MU. In such a case, 
the EP, EH, or CAH would not necessarily need to have EHR technology 
with the capability to meet the menu set objective and associated 
measure in order to have EHR technology that satisfies the proposed 
revised definition of CEHRT. Ultimately, under the proposed revised 
definition of CEHRT for FY/CY 2014 and subsequent years, the EP, EH, 
and CAH will be responsible for ensuring that they have the necessary 
EHR technology to meet the definition of a Base EHR and support the MU 
objectives and measures that they seek to achieve under the EHR 
Incentive Programs. This means that EPs, EHs, and CAHs could run the 
risk of not having sufficient CEHRT to support their achievement of MU 
if, for example, they turn out not to be able to exclude a MU objective 
and measure as anticipated or they end up needing to satisfy a menu 
objective and measure that they originally expected to defer.
    We emphasize that under the proposed revised definition of CEHRT 
for FY/CY 2014 and subsequent years, all EPs, EHs, and CAHs must have 
EHR technology certified under the ONC HIT Certification Program to the 
2014 Edition EHR certification criteria that meets the definition of a 
Base EHR as defined below. For example, even if an EP could claim an 
exclusion from the MU objective and associated measure for CPOE, he or 
she would still need to have EHR technology that has been certified to 
the CPOE certification criterion adopted by the Secretary because this 
capability would be included in a Base EHR.
    We have consulted with CMS and have determined that it would be 
least confusing and burdensome for EPs, EHs, CAHs, and EHR technology 
developers if this revised definition would apply beginning with the 
EHR reporting periods that will occur in FY/CY 2014. This approach 
would account for the proposed start of MU Stage 2 in FY/CY 2014; the 
policy change we have made related to the definition of a Base EHR; the 
time it would take EHR developers to update their EHR technology to 
meet the proposed new and revised certification criteria and have the 
EHR technology tested and certified to those criteria; and the time it 
would take EPs, EHs, and CAHs to subsequently implement EHR technology 
certified to the 2014 Edition EHR certification criteria. We request 
public comment on alternative approaches we should consider that would 
provide equivalent simplicity and flexibility for EPs, EHs, and CAHs, 
as well as EHR technology developers, but that would still meet our 
programmatic goals and timelines.
    The revised definition of CEHRT would apply for all EPs, EHs, and 
CAHs, regardless of whether they are in Stage 1 or Stage 2 of MU. For 
example, EPs, EHs, and CAHs that are in Stage 1 or Stage 2 of MU for 
the EHR reporting periods in FY/CY 2014 would need to meet the revised 
definition of CEHRT (which includes the definition of a Base EHR). 
Table 5 is intended to provide a general overview of the proposed 
revised definition of CEHRT in relation to the stages of MU and the EHR 
reporting periods in FY/CY 2011 through 2014 (including the extension 
of Stage 1 in 2013 as proposed by CMS).

[[Page 13865]]



                                  Table 5--Proposed Revised Definition of CEHRT
----------------------------------------------------------------------------------------------------------------
                                              EHR reporting periods
-----------------------------------------------------------------------------------------------------------------
             FY/CY 2011                      FY/CY 2012              FY/CY 2013                FY/CY2014
----------------------------------------------------------------------------------------------------------------
             MU Stage 1                      MU Stage 1              MU Stage 1         MU Stage 1 or MU Stage 2
----------------------------------------------------------------------------------------------------------------
All EPs, EHs, and CAHs must have EHR technology that has been certified to all         All EPs, EHs, and CAHs
 applicable 2011 Edition EHR certification criteria or equivalent 2014 Edition EHR      must have EHR technology
 certification criteria adopted by the Secretary.                                       (including a Base EHR)
                                                                                        that has been certified
                                                                                        to the 2014 Edition EHR
                                                                                        certification criteria
                                                                                        that would support the
                                                                                        objectives and measures,
                                                                                        and their ability to
                                                                                        successfully report the
                                                                                        CQMs, for the MU stage
                                                                                        that they seek to
                                                                                        achieve.
----------------------------------------------------------------------------------------------------------------

2. Base EHR
    Section 3000(1) of the PSHA defines Certified EHR Technology to 
include a Qualified EHR. Section 3000(13), in turn, defines a 
``qualified electronic health record'' or Qualified EHR as 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; and
    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; and
    iv. To exchange electronic health information with, and integrate 
such information from other sources.
    This definition of Qualified EHR is codified at 45 CFR 170.102 and 
is part of the current definition of CEHRT. We now propose to add the 
term ``Base EHR'' to Sec.  170.102. This term is essentially a 
substitution for the term ``Qualified EHR'' in the revised definition 
of CEHRT that would apply in FY/CY 2014 and subsequent years. A Base 
EHR would have all of the capabilities specified in the statutory 
definition of a Qualified EHR (that is, in section 3000(13) of the 
PHSA) and additional capabilities as described below. Hereafter, we 
intend to use the term ``Qualified EHR'' only as necessary and to refer 
to the statutory definition, unless otherwise indicated. We believe 
that the term ``Base EHR'' is more intuitive and conveys a plain 
language meaning. Moreover, the term ``Qualified EHR'' does not 
inherently convey the kinds of capabilities it includes. The term 
``Base EHR,'' though, conveys that the EHR technology possesses 
capabilities that are fundamental and should be a part of any CEHRT 
that an EP, EH, or CAH must have to demonstrate MU. We also note that 
the terms ``qualified EHR'' and ``qualified EHR products'' have been 
used by CMS in other programs and with a different meaning. Therefore, 
we believe that the term ``Base EHR'' will be more easily understood 
and readily accepted by stakeholders.
    We propose to define a Base EHR as 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. Meets the certification criteria adopted by the Secretary at: 
Sec.  170.314(a)(1) through (8); (b)(1) and (2); (c)(1) and (2); (d)(1) 
through (8); and (e)(1).
    We previously adopted, without modification, the statutory 
definition of Qualified EHR in regulation (Sec.  170.102). This was due 
to our requirement that the definition of CEHRT could only be met if 
the EHR technology an EP, EH, or CAH had in its possession was 
certified to all of the general certification criteria and all 
applicable ambulatory or inpatient setting specific certification 
criteria. This requirement ensured that EPs', EHs', and CAHs' CEHRT 
included capabilities related to privacy and security even though the 
statutory definition of Qualified EHR did not include a requirement for 
those capabilities. Based on our proposed revised definition of CEHRT, 
we believe it is necessary now to expand the Base EHR definition to 
include a capacity that addresses privacy and security.
    In Table 6, we explain the certification criteria specified in 
paragraph (3) of the proposed Base EHR definition. As discussed in 
section III.A.1 of this preamble, some capabilities within the proposed 
2014 Edition EHR certification criteria may only apply to the 
ambulatory or inpatient setting. For example, to be certified to the 
proposed ``demographics'' certification criterion (Sec.  
170.314(a)(3)), EHR technology designed for either an ambulatory or 
inpatient setting would need to enable a user to electronically record, 
change, and access patient demographic data including preferred 
language, gender, race, ethnicity, and date of birth (Sec.  
170.314(a)(3)(i)), while EHR technology designed specifically for an 
inpatient setting would also need to enable a user to electronically 
record, change, and access the ``date and preliminary cause of death in 
the event of mortality in accordance with the standard specified in 
Sec.  170.207(k)'' (Sec.  170.314(a)(3)(ii)).
    In relation to CQMs, we propose that a Base EHR include EHR 
technology certified to the certification criteria proposed at Sec.  
170.314(c)(1) and (2). The inclusion of Sec.  170.314(c)(2) in a Base 
EHR ensures that EPs, EHs, and CAHs have the capability to incorporate 
all the data elements of, and calculate, at least one CQM. We 
anticipate that EHR technology developers would design EHR technology 
to incorporate the data elements for, and calculate, those CQMs they 
believe their EHR technology would need to include in order to support 
the providers to which they market their EHR technology. Therefore, we 
expect that EHR technology certified to Sec.  170.314(c)(2) would be 
capable of incorporating all necessary data elements and calculating 
more than one CQM. This approach may, however, leave a void in the 
market for EHR technology that would support certain CQMs that EPs, 
EHs, and CAHs would need to report beginning in 2014.
    Accordingly, we are interested in comments on whether we should 
require certification to a set number of CQMs as part of certification 
to Sec.  170.314(c)(2). For example, we could require EHR technology 
designed for the ambulatory setting and that would constitute an EP's 
Base EHR to be able to incorporate data elements and calculate a 
specific number of CQMs for each of the CQM ``domains'' proposed by CMS 
for EPs in the Stage 2 proposed

[[Page 13866]]

rule. And for EHR technology designed for the inpatient setting and 
that would constitute an EH's or CAH's Base EHR, we could require that 
it be able to incorporate data elements and calculate a minimum 
threshold number of CQMs proposed by CMS for EHs and CAHs (e.g., 24 or 
36). However, we see a potential challenge with this more explicit 
approach. In order for EPs, EHs, and CAHs to have EHR technology that 
would meet the definition of a Base EHR, their EHR technology 
developers could be required to demonstrate that their EHR technology 
can incorporate and calculate data for certain CQMs that may ultimately 
be irrelevant to their customers, but nonetheless are necessary for the 
EHR technology to be certified. We also request comment on whether a 
Base EHR should include, in addition to Sec.  170.314(c)(1) and (2), 
the CQM reporting certification criteria proposed at Sec.  
170.314(c)(3), which would enable a user to electronically create a 
data file for transmission of clinical quality measurement results to 
CMS.
    With respect to the ``privacy and security'' certification criteria 
associated with the capacity to protect the confidentiality, integrity, 
and availability of health information stored and exchanged, we are 
proposing that the certification criteria should apply equally to both 
the ambulatory and inpatient settings. We are, however, interested in 
public comment on whether there should be a distinction between the 
ambulatory and inpatient settings for the certification of EHR 
technology to the privacy and security certification criteria, 
including for which certification criteria there could be a distinction 
and the basis for that distinction.
    We would like to make clear that the definition of Base EHR is a 
requirement that must be satisfied to meet the definition of CEHRT. The 
proposed Base EHR definition is not meant to convey our expectation 
that EHR technology must be separately certified as a Base EHR. Rather, 
similar to the proposed revised definition of CEHRT, the definition of 
a Base EHR can be satisfied through a certified Complete EHR, a single 
EHR Module certified to all of the certification criteria specified in 
Table 6 below, or a combination of certified EHR Modules where the 
resultant combination has been collectively certified to all of the 
certification criteria specified in Table 6 below. In section IV.D of 
this preamble, we discuss proposals and options for the representation 
and marketing of EHR technology that meets the definition of a Base 
EHR.
[GRAPHIC] [TIFF OMITTED] TP07MR12.001

3. Complete EHR
    We are proposing to slightly revise the Complete EHR definition for 
clarity. A Complete EHR is currently defined as ``EHR technology that 
has been developed to meet, at a minimum, all applicable certification 
criteria adopted by the Secretary.'' In the S&CC January 2010 interim 
final rule, we clarified, based on our understanding of Congress' 
intent, that the term ``applicable'' in the definition of Certified EHR 
Technology

[[Page 13867]]

meant the adopted certification criteria applicable to either an 
ambulatory or to an inpatient setting. Therefore, to be certified to 
the 2011 Edition EHR certification criteria adopted by the Secretary, a 
Complete EHR designed for an ambulatory setting must meet the mandatory 
certification criteria adopted at Sec.  170.302 and Sec.  170.304, 
while a Complete EHR designed for an inpatient setting must meet the 
mandatory certification criteria adopted under Sec. Sec.  170.302 and 
170.306.
    We intend to maintain the concept of a Complete EHR and permit EHR 
technology developers to seek certification of their EHR technology as 
Complete EHRs, but propose to revise the definition for clarity. We 
propose that ``Complete EHR'' mean ``EHR technology that has been 
developed to meet, at a minimum, all mandatory certification criteria 
of an edition of certification criteria adopted by the Secretary for 
either an ambulatory setting or inpatient setting.'' We believe this 
revised definition is consistent with the previous definition of 
Complete EHR and clarifies that a Complete EHR can be setting-specific 
and must meet all adopted mandatory certification criteria for a 
setting. Our proposed addition of paragraph (d) to Sec.  170.300 
clarifies which certification criteria in proposed Sec.  170.314 have 
general applicability (apply to both ambulatory and inpatient settings) 
or apply only to an inpatient setting or an ambulatory setting. This 
proposed revised definition, if adopted, would be effective upon the 
final rule's effective date.
    While a certified Complete EHR (under the proposed revised 
definition of CEHRT) will likely have more capabilities than are 
necessary for any single EP, EH, or CAH to achieve MU, we believe the 
``Complete EHR'' designation still has significant market value in 
that: It provides purchasing clarity and assurance to EPs, EHs, and 
CAHs that the EHR technology they have meets the regulatory definition 
of CEHRT; it can support EPs, EHs, and CAHs if they attempt to achieve 
all MU objectives and measures; and it ensures all the capabilities the 
Complete EHR includes have been tested and certified to work properly 
together. We believe that the choice to adopt or upgrade a Complete EHR 
may be more appealing (in some cases for EHs and CAHs and more so for 
EPs given that there are over 668 certified ambulatory Complete EHRs 
(which includes newer versions of the same Complete EHR)), than having 
to assume the responsibility to determine which certified EHR Modules 
include the capabilities needed to support the achievement of MU or 
having the responsibility to ensure that the certified EHR Modules work 
properly together.
4. Certifications Issued for Complete EHRs and EHR Modules
    Following the S&CC July 2010 final rule's publication, some 
stakeholders contended that the linkage between a certification issued 
for an EHR technology and the possession of all of that EHR 
technology's capabilities should be dropped. In other words, they 
argued that an EHR technology developer should be able to sell any 
component of a certified Complete EHR or EHR Module as certified and, 
equally, that an EP, EH, or CAH should be able to buy something less 
than 100% of a certified Complete EHR or EHR Module and still be able 
to say it is using ``certified'' EHR technology. In response to these 
stakeholder contentions, we issued FAQ 9-10-005-1.\43\ This FAQ 
clarifies that a stand-alone, separate component of a certified 
Complete EHR cannot derive ``certified'' status based solely on it 
having been included as part of the Complete EHR when the Complete EHR 
was certified. This same principle applies to certified EHR Modules 
with multiple capabilities in that the components of the EHR Modules 
cannot be separately sold or purchased as certified EHR technology 
unless they have been separately certified.
---------------------------------------------------------------------------

    \43\ http://healthit.hhs.gov/portal/server.pt/community/onc_regulations_faqs/3163/faq_5/20767.
---------------------------------------------------------------------------

    We believe that allowing separate components of a certified 
Complete EHR or certified EHR Module to derive ``certified'' status 
from the certification of the entire certified Complete EHR or 
certified EHR Module would undermine the purpose of the ONC HIT 
Certification Program. In essence, it would permit EHR technology 
developers to ``self-declare'' certifications for components of a 
certified Complete EHR or certified EHR Module that have never been 
independently reviewed by an ONC-ACB as actually being able to work as 
separate, independent technologies. This approach could result in 
inaccurate, deceptive, or false representations about an EHR 
technology's capabilities.
    It is important for all stakeholders to recognize that a 
certification is assigned to a Complete EHR or EHR Module, not to a 
capability. And, in the event that combined and/or workflow-based test 
procedures are developed, one would be unable to infer that a specific 
component of a certified Complete EHR or certified EHR Module was 
compliant with a particular certification criterion unless the 
component had been separately certified as performing the required 
capability.
    As we have stated in prior rulemakings, Congress made clear that 
the act of seeking certification must be voluntary. We therefore 
encourage EHR technology developers to seek, where possible, 
certification for separate components of a certified Complete EHR or 
certified EHR Module that would provide the solutions that EPs, EHs, 
and CAHs seek to adopt. Conversely, EPs, EHs, and CAHs should take note 
that in some cases it may not be practicable for an EHR technology 
developer to separate out one or more components for certification 
without adversely affecting the proper functioning of the remaining 
components.
5. Adaptations of Certified Complete EHRs or Certified EHR Modules
    As the hardware on which EHR technology can run continues to 
evolve, we expect and encourage EHR technology developers to pursue 
innovative ways to facilitate efficient workflows and user 
interactions. In this regard, we believe that it would be possible for 
an EHR technology developer of a certified Complete EHR or certified 
EHR Module (and only that EHR technology developer) to create an 
adaptation of a certified Complete EHR or certified EHR Module without 
the need for additional certification of the adaptation. We consider an 
``adaptation'' of a certified Complete EHR or certified EHR Module to 
be a software application designed to run on a different medium, which 
includes the exact same capability or capabilities included in the 
certified Complete EHR or certified EHR Module. For example, an 
adaptation of a certified Complete EHR that is capable of running on a 
tablet device or smart phone could include the capabilities of a 
certified Complete EHR to e-prescribe, take electronic notes, and 
manage a patient's active medication list. In this example, the 
adaptation would be covered by the Complete EHR's certification so long 
as the adaptation included the full and exact same capabilities 
required for the particular certification criteria to which the 
Complete EHR was certified (i.e., in this case, the capabilities 
required by the certification criteria proposed at Sec.  170.314(b)(3), 
(a)(9), and (a)(6), respectively)). We note that the user of the 
adaptation would need to ensure, perhaps through contractual assurances 
from the EHR technology developer that provides such adaptation, that 
the adaptation does not introduce privacy

[[Page 13868]]

and security vulnerabilities into the certified Complete EHR or 
certified EHR Module.
    If an adaptation does not make it possible for a user to use the 
capability or capabilities that were required for the Complete EHR or 
EHR Module to be certified, then the adaptation could jeopardize an 
EP's, EH's, or CAH's ability to meet MU because the user of the 
adaptation would not be meaningfully using EHR technology that had been 
certified. Furthermore, while an EHR technology developer may create an 
adaptation without needing to obtain an additional certification, the 
adaptation would be subject to the provisions of the certification 
issued for the Complete EHR or EHR Module. ONC-ATCBs and ONC-ACBs 
maintain authority over the certifications that they issue and can take 
appropriate action when there is evidence of non-conformance with those 
certifications. We invite comment on our proposed adaptation policy and 
whether it strikes an appropriate balance between permitting innovation 
and providing certainty that the EHR technology used by an EP, EH, or 
CAH has satisfied the certification criteria adopted by the Secretary.

IV. Provisions of the Proposed Rule Affecting the Permanent 
Certification Program for HIT (``ONC HIT Certification Program'')

A. Program Name Change

    We have established two certification programs, the ``temporary 
certification program for HIT'' and the ``permanent certification 
program for HIT'' (see 75 FR 36158 and 76 FR 1262, respectively). The 
permanent certification program will replace the temporary 
certification program, which we expect will occur upon the effective 
date of the final rule that would follow this proposed rule. At that 
time, there will no longer be a need to continue to differentiate 
between the certification programs based on their expected duration. 
Therefore, we propose to replace all references in Part 170 of the Code 
of Federal Regulations to the permanent certification program with 
``ONC HIT Certification Program.'' We believe this new program name 
provides clear attribution to the agency responsible for the program 
and an appropriate description of the program's scope, covering both 
current and potential future activities.

B. ``Minimum Standards'' Code Sets

    In Sec.  170.555, we allow ONC-ACBs to certify Complete EHRs and/or 
EHR Modules to newer versions of certain code sets identified as 
``minimum standards'' in Subpart B of part 170 if the Secretary has 
accepted a newer version for certification and implementation in EHR 
technology. This approach permits a Complete EHR and/or EHR Module to 
be certified to a newer version of an adopted code set without the need 
for additional rulemaking and enables CEHRT to be upgraded with a newer 
version of an adopted minimum standard code set without adversely 
affecting its certified status. We finalized two methods through which 
the Secretary would identify new versions of adopted ``minimum 
standards'' code sets (76 FR 1294-1295). The first method would allow 
any member of the general public to notify the National Coordinator 
about a new version. Under the second method, the Secretary would 
proactively identify newly published versions. After a new version has 
been identified, a determination would be issued as to whether the new 
version constitutes maintenance efforts or minor updates to the adopted 
code set and consequently may be permitted for use in certification.
    The process we have followed involves presenting the identified new 
version of an adopted ``minimum standard'' code set to the HITSC for 
assessment, solicitation of public comments on the new version, and 
issuing a recommendation to the National Coordinator which would 
identify whether the Secretary's acceptance of the newer version for 
voluntary implementation and certification would burden the HIT 
industry, negatively affect interoperability, or cause some other type 
of unintended consequence. After considering the recommendation of the 
HITSC, the National Coordinator would determine whether or not to seek 
the Secretary's acceptance of the new version of the adopted ``minimum 
standard'' code set. If the Secretary approves the National 
Coordinator's request, we would issue guidance indicating that the new 
version of the adopted ``minimum standard'' code set has been accepted 
by the Secretary.
    Our experience has shown that newer versions of the ``minimum 
standards'' code sets we adopted are issued more frequently than this 
process can reasonably accommodate. Additionally, based on the 
``minimum standard'' code sets we have previously adopted and are 
proposing in this rule, we believe that permitting EHR technology to be 
upgraded and certified to newer versions of these code sets would not 
normally pose an interoperability risk, cause unintended consequences, 
or place an undue burden on the HIT industry. We propose to revise 
Sec.  170.555 such that, unless the Secretary prohibits the use of a 
newer version of a ``minimum standard'' code set identified in subpart 
B of part 170, the newer version could be used voluntarily for 
certification and implemented as an upgrade to a previously certified 
Complete EHR or EHR Module without adversely affecting the EHR 
technology's certified status. We believe this proposed approach would 
reduce regulatory complexity by providing the industry with the 
flexibility to utilize newer versions of adopted ``minimum standard'' 
code sets. In consideration of this proposed new approach we want to 
clarify that when we refer to a ``newer'' version of a ``minimum 
standard'' code set, we mean a final version or release as opposed to a 
draft version or release of a code set.
    We expect that we would generally use the same process for 
determining whether to prohibit the use of a newer version of a 
``minimum standard'' code set. The public could inform ONC or the 
Secretary could proactively identify a newer version of a ``minimum 
standard'' code set that may not be appropriate for use. We expect that 
we would still seek a recommendation from the HITSC, based on their 
assessment of the newer version and on any public comments that they 
receive, as to whether the Secretary should prohibit the use of the 
newer version of the ``minimum standard'' code set. After considering 
the HITSC's recommendation, the National Coordinator would make a 
recommendation to the Secretary as to whether or not to allow the 
continued use of the newer version. Finally, if the Secretary decides 
to prohibit the use of a newer version of a minimum standard code set, 
we would issue guidance indicating that the newer version of the 
adopted ``minimum standard'' code set cannot be used for certification 
under the ONC HIT Certification Program, and thus upgrading previously 
certified Complete EHRs and EHR Modules to the newer version would 
adversely affect their certified status.
    As an exception to the process outlined above, we believe, in 
limited circumstances, it may be necessary for the Secretary to act 
more quickly to prohibit the use of a newer version of a ``minimum 
standard'' code set. Instances could arise where the use of a newer 
version of a ``minimum standard'' code set may have an immediate 
negative effect on interoperability, cause an obvious unintended 
consequence, or pose an undue burden on the HIT industry. Therefore, 
under such circumstances, the Secretary may choose to prohibit the

[[Page 13869]]

use of a newer version of a ``minimum standard'' code set for purposes 
of certification and upgrading certified EHR technology without seeking 
a recommendation from the HITSC in advance.
    We propose to also make minor revisions to the text of Sec.  
170.555, including removing the terms ``adopted'' and ``accepted'' and 
replacing the term ``Certified EHR Technology'' in Sec.  170.555(b)(2) 
with ``A certified Complete EHR or certified EHR Module.'' We believe 
the revisions provide additional clarity and specificity.

C. Revisions to EHR Module Certification Requirements

1. Privacy and Security Certification
    Section 170.550(e) states that ``EHR Module(s) shall be certified 
to all privacy and security certification criteria adopted by the 
Secretary, unless the EHR Module(s) is presented for certification in 
one of the following manners:
    1. The EHR Modules are presented for certification as a pre-
coordinated, integrated bundle of EHR Modules, which would otherwise 
meet the definition of and constitute a Complete EHR, and one or more 
of the constituent EHR Modules is demonstrably responsible for 
providing all of the privacy and security capabilities for the entire 
bundle of EHR Modules; or
    2. An EHR Module is presented for certification, and the presenter 
can demonstrate and provide documentation to the ONC-ACB that a privacy 
and security certification criterion is inapplicable or that it would 
be technically infeasible for the EHR Module to be certified in 
accordance with such certification criterion.''
    We propose not to apply the privacy and security certification 
requirements at Sec.  170.550(e) for the certification of EHR Modules 
to the 2014 Edition EHR certification criteria. Stakeholder feedback, 
particularly from EHR technology developers, has identified that this 
regulatory requirement is causing unnecessary burden (both in effort 
and cost). EHR Module developers have expressed that they have had to 
redesign their EHR technology in atypical ways to accommodate this 
regulatory requirement, which sometimes leads to the inclusion of a 
privacy or security feature that would not normally be found in a 
certain type of EHR Module. In turn, this has led to EPs, EHs, and CAHs 
purchasing EHR Modules that have redundant or sometimes conflicting 
privacy and security capabilities. Based on our proposal that EPs, EHs, 
and CAHs must have a Base EHR to meet our proposed revised definition 
of CEHRT that would apply beginning with FY/CY 2014, we believe that we 
can be responsive to stakeholder feedback with our proposal not to 
apply the privacy and security certification requirements at Sec.  
170.550(e) for the certification of EHR Modules, while still requiring 
an equivalent or higher level of privacy and security capabilities to 
be part of CEHRT.
    In section III.B of this preamble, we propose that a Base EHR 
include all the proposed mandatory privacy and security certification 
criteria (i.e., all privacy and security certification criteria except 
the optional ``accounting of disclosure'' certification criterion at 
Sec.  170.314(d)(9)). This ensures that EPs, EHs, and CAHs have the 
capabilities to support the MU objective to protect electronic health 
information created or maintained by CEHRT through the implementation 
of appropriate technical capabilities. In addition, EPs, EHs, and CAHs 
remain responsible for implementing their EHR technology in ways that 
meet applicable privacy and security requirements under Federal and 
applicable State law (e.g., the HIPAA Privacy Rule and Security Rule 
and 42 CFR Part 2). These factors reduce the importance of certifying 
EHR Modules to all of the privacy and security certification criteria 
or requiring EHR Module developers to demonstrate that privacy and 
security certification criteria are inapplicable to or technically 
infeasible to implement for their EHR Modules. Thus, a regulatory 
burden and associated costs for EHR Module developers would be 
eliminated, and EPs, EHs, and CAHs would not have to purchase EHR 
Modules that have privacy and security capabilities that are redundant 
or conflict with the capabilities of the EHR technology that would make 
up their Base EHR.
2. Certification to Certain New Certification Criteria
    As discussed in section III.A of this preamble, we propose to adopt 
new 2014 Edition EHR certification criteria that would require the 
following: Electronic recording of the numerator for each MU objective 
with a percentage-based measure (Sec.  170.314(g)(1) ``automated 
numerator recording''); electronic recording of activities related to 
non-percentage-based measures (Sec.  170.314(g)(3) ``non-percentage-
based measure use report''); and user-centered design processes to be 
applied to EHR technology that includes certain capabilities (Sec.  
170.314(g)(4) ``safety-enhanced design''). To ensure proper 
certification of EHR Modules to these proposed certification criteria, 
we propose to revise Sec.  170.550.
    We propose to revise Sec.  170.550 to ensure that EHR Modules that 
are presented for certification to certification criteria that include 
capabilities for supporting an MU objective with a percentage-based 
measure are certified to proposed Sec.  170.314(g)(1). However, we 
propose that this requirement would not apply if the EHR Module was 
certified to Sec.  170.314(g)(2) (automated measure calculation) in 
lieu of certification to Sec.  170.314(g)(1). We propose to revise 
Sec.  170.550 in order to ensure that EHR Modules that are presented 
for certification to certification criteria that include capabilities 
for supporting an MU objective with a non-percentage-based measure are 
certified to proposed Sec.  170.314(g)(3). We propose to revise Sec.  
170.550 to ensure that EHR Modules presented for certification to any 
of the certification criteria listed in proposed Sec.  170.314(g)(4) 
are also certified to Sec.  170.314(g)(4). We propose to include these 
three revisions at Sec.  170.550(f).

D. ONC-ACB Reporting Requirements

    In the permanent certification program final rule (76 FR 1318-
1323), we adopted (Sec.  170.523) principles of proper conduct to which 
ONC-ACBs must adhere for their authorization to remain in good standing 
under the program. The principle of proper conduct at Sec.  170.523(f) 
requires an ONC-ACB to provide ONC, no less frequently than weekly, a 
current list of Complete EHRs and/or EHR Modules that have been 
certified which includes, at a minimum: The Complete EHR or EHR Module 
developer name (if applicable); the date certified; the product 
version; the unique certification number or other specific product 
identification; the clinical quality measures to which a Complete EHR 
or EHR Module has been certified; where applicable, any additional 
software a Complete EHR or EHR Module relied upon to demonstrate its 
compliance with a certification criterion adopted by the Secretary; and 
where applicable, the certification criterion or certification criteria 
to which each EHR Module has been certified.
    We propose to require that ONC-ACBs include an additional data 
element in the set of data they are required to provide regarding the 
Complete EHRs and/or EHR Modules they report as certified to ONC under 
Sec.  170.523(f). Specifically, we propose that an ONC-ACB would need 
to provide to ONC a hyperlink for each

[[Page 13870]]

Complete EHR and EHR Module it certifies that would enable the public 
to access the test results that the ONC-ACB used to certify the EHR 
technology. As with all of the other data an ONC-ACB reports to ONC 
regarding a Complete EHR or EHR Module it certifies, we would make the 
hyperlink available on the CHPL with the respective certified Complete 
EHR or certified EHR Module. As with other records related to 
certification, we expect that ONC-ACBs would ensure the functionality 
of the hyperlink for a minimum of five years consistent with Sec.  
170.523(g), unless a certified Complete EHR or certified EHR Module is 
removed from the CHPL. Under such circumstances, the ONC-ACB would no 
longer need to ensure the functionality of the hyperlink, although 
retention of the test results would be required. We believe this 
additional element is important to increase transparency in the testing 
and certification processes and would serve to make more information 
available to prospective purchasers of certified Complete EHRs and 
certified EHR Modules as well as other stakeholders.

E. Continuation and Representation of Certified Status

1. 2011 or 2014 Edition EHR Certification Criteria Compliant
    In our certification program final rules (76 FR 1302, 75 FR 36189), 
we indicated that we anticipated adopting new and/or revised 
certification criteria every two years to coincide with changes to the 
MU objectives and measures under the EHR Incentive Programs. We did 
not, however, set a specific expiration date for certifications. 
Rather, we explained that once the Secretary adopts new and/or revised 
certification criteria, EHR technology may need to be tested and 
certified again. In other words, the previous certifications may no 
longer accurately represent what is required to meet the adopted 
certification criteria. Based on this expectation, we established in 
the Permanent Certification Program final rule and at Sec.  170.523(k) 
that ONC-ACBs must require as part of certification that EHR technology 
developers include on their Web sites and in all marketing materials, 
communications, statements, and other assertions, the years (``20[XX]/
20[XX]'') for which a certification issued for a Complete EHR or EHR 
Module would be considered compliant. Again, anticipating that every 
two years certification criteria would be adopted and EHR technology 
would need to be certified to the certification criteria to meet the 
definition of CEHRT, we clarified this provision in the Permanent 
Certification Program final rule with examples (76 FR 1305). These 
examples indicated that EHR technology certified to the adopted 
certification criteria (i.e., the certification criteria adopted at 
Sec. Sec.  170.302, 170.304, and 170.306) would include ``2011/2012'' 
compliant and that certifications based on certification criteria 
adopted through future rulemaking would indicate ``2013/2014'' 
compliant.
    In this proposed rule, we have referred to the adopted 
certification criteria collectively as the ``2011 Edition EHR 
certification criteria'' and the certification criteria proposed in 
this rule collectively as the ``2014 Edition EHR certification 
criteria'' (terms we also propose to include as defined terms in Sec.  
170.102). In line with this convention, we propose to revise Sec.  
170.523(k) to require the edition of certification criteria for which a 
certification issued for a Complete EHR or EHR Module would be 
considered compliant instead of the years (i.e., ``2014 Edition EHR 
certification criteria compliant).'' This proposed revision would apply 
to all certifications issued after the effective date of a final rule. 
We believe this proposal would further assist in eliminating confusion 
about the ``expiration'' of certifications, align with our proposed 
revised definition of CEHRT, and provide the market with greater 
clarity regarding the capabilities of certified Complete EHRs and 
certified EHR Modules.
    For certified EHR technologies that are already designated as 
``2011/2012'' compliant, we have considered multiple options and 
concluded that the best approach is to not require any changes to the 
``2011/2012'' designation, such as having them re-designated as ``2011 
Edition EHR certification criteria compliant.'' Rather, we would simply 
make clear that certified Complete EHRs and certified EHR Modules that 
are designated as ``2011/2012'' compliant would remain valid for 
purposes of the EHR reporting periods in FY/CY 2013. We believe this 
approach minimizes the burden on EHR technology developers. We request 
public comment on our approach and any other approach that would 
present the least burden for EHR technology developers and the least 
confusion for the market.
    Section 170.523(k)(1)(i) states, in part, that ``[A] certification 
does not represent an endorsement by the U.S. Department of Health and 
Human Services or guarantee the receipt of incentive payments.'' We 
propose to revise this statement by removing ``* * * or guarantee the 
receipt of incentive payments'' because although incentives will be 
available under the Medicaid EHR Incentive Program until 2021, they 
will no longer be available under the Medicare EHR Incentive Program 
after 2016. Therefore, to prevent confusion and to defer to CMS in 
establishing and specifying the parameters of the EHR Incentive 
Programs, we propose this revision to the statement.
2. Updating a Certification
    To ensure that the information required by Sec.  170.523(k)(1)(i) 
remains accurate and reflects the correct edition of EHR certification 
criteria, ONC-ACBs, under Sec.  170.550(d), are permitted to provide 
updated certifications to previously certified EHR Modules under 
certain circumstances. In the Permanent Certification Program final 
rule (76 FR 1306) and at Sec.  170.502, we defined ``providing or 
provide an updated certification'' to an EHR Module as ``the action 
taken by an ONC-ACB to ensure that the developer of a previously 
certified EHR Module(s) shall update the information required by Sec.  
170.523(k)(1)(i), after the ONC-ACB has verified that the certification 
criterion or criteria to which the EHR Module(s) was previously 
certified have not been revised and that no new certification criteria 
adopted for privacy and security are applicable to the EHR Module(s).'' 
Based on our proposal to not apply the privacy and security 
certification requirements at Sec.  170.550(e) to EHR Modules certified 
to the proposed 2014 Edition EHR certification criteria, we propose to 
revise the definition of ``providing or provide an updated 
certification'' to eliminate the requirement that ONC-ACBs would need 
to verify that any new privacy and security certification criteria 
apply when they issue an updated certification. However, ONC-ACBs would 
still need to verify whether the certification criterion or criteria to 
which the EHR Module(s) was previously certified have not been revised 
and that no new certification criteria are applicable to the EHR 
Module(s).
    The certification criteria and certification requirements that 
apply to previously certified EHR Modules may change with each new 
edition of certification criteria that is adopted by the Secretary. 
Therefore, we believe that we can provide the best guidance to 
stakeholders on when ``updating'' a certification would be permitted 
with each rulemaking for an edition of certification criteria. For the 
2014 Edition EHR certification criteria, if we were to adopt in a final 
rule all the proposed new certification criteria discussed above in 
section IV.C.2

[[Page 13871]]

(``Certification to Certain New Certification Criteria'') of this 
preamble, then no previously certified EHR Modules could be issued 
updated certifications because every EHR Module would require 
certification to, at a minimum, the certification criterion at Sec.  
170.314(g)(1) (automated numerator recording) (or Sec.  170.314(g)(2) 
in lieu of being certified to Sec.  170.314(g)(1)) or the certification 
criterion at Sec.  170.314(3) (non-percentage-based measure use 
report). Although ONC-ACBs would not be able to issue updated 
certifications to the 2014 Edition EHR certification criteria, 
``updating'' certifications may still be a viable option under certain 
conditions when the Secretary adopts another edition of certification 
criteria in the future.
3. Base EHR Representation
    An EHR technology developer's Complete EHR, single EHR Module or 
combination of EHR Modules could constitute a Base EHR by meeting all 
the certification criteria required by the definition of Base EHR for 
the ambulatory setting or inpatient setting. We believe EPs, EHs, and 
CAHs would benefit from knowing which certified EHR technologies on the 
market constitute a Base EHR because they would need to have a Base EHR 
to satisfy the proposed revised definition of CEHRT beginning with FY/
CY 2014. We do not believe that it is necessary to expressly propose a 
requirement for ONC-ACBs related to the identification of EHR 
technology that meets the definition of a Base EHR. To gain a 
competitive advantage in the market, we believe EHR technology 
developers would likely identify on their Web sites and in marketing 
materials, communications, statements, and other assertions whether 
their certified Complete EHR or EHR Module(s) meet the definition of a 
Base EHR (designed for either the ambulatory or inpatient setting). 
However, we considered as a potential alternative or complementary 
approach to permit ONC-ACBs when issuing certifications to Complete 
EHRs and EHR Modules that meet the definition of a Base EHR to formally 
indicate such fact to the EHR technology developer and permit the EHR 
technology developer in association with its EHR technology's 
certification to represent that the EHR technology meets the definition 
of a Base EHR. We welcome comments on these and any other approaches 
that we have not identified.

V. Request for Additional Comments

A. Certification and Certification Criteria for Other Health Care 
Settings

    The HITECH Act did not authorize the availability of incentives 
under the EHR Incentive Programs for all health care providers. 
Consequently, the certification criteria proposed for adoption in this 
rule focus primarily on enabling EHR technology to be certified and 
subsequently adopted and used by EPs, EHs, and CAHs who seek to 
demonstrate MU under the EHR Incentive Programs.
    In the Permanent Certification Program final rule (76 FR 1294), we 
discussed the National Coordinator's statutory authority to establish a 
voluntary certification program or programs for other types of HIT 
besides EHR technology. However, as explained in the Permanent 
Certification Program final rule, any steps towards certifying other 
types of HIT, including EHR technology such as ``Complete EHRs'' or 
``EHR Modules'' for settings other than inpatient or ambulatory, would 
first require the Secretary to adopt certification criteria for other 
types of HIT and/or other types of health care settings.
    As we continue to adopt new and revised certification criteria to 
support MU, we believe that it is prudent to seek public comment on 
whether we should focus our efforts on the certification of the HIT 
used by health care providers that are ineligible to receive incentives 
under the EHR Incentive Programs. In particular, we are interested in 
commenters' thoughts on whether we should consider adopting 
certification criteria for other health care settings, such as the 
long-term care, post-acute care, and mental and behavioral health 
settings. For those commenters that believe we should consider 
certification criteria for other health care settings, we respectfully 
request that their comments specify the certification criteria that 
would be appropriate as well as the benefits they believe a regulatory 
approach would provide. Last, we ask that the public consider whether 
the private sector could alternatively address any perceived need or 
demand for such certification. For example, we are aware that the 
Certification Commission for Health Information Technology (CCHIT) has 
certification programs for long-term and post-acute care as well as 
behavioral health EHR technology.\44\
---------------------------------------------------------------------------

    \44\ http://www.cchit.org/get_certified/cchit-certified-2011.
---------------------------------------------------------------------------

B. 2014 Edition EHR Accounting of Disclosures Certification Criterion

    We previously adopted an ``accounting of disclosures'' optional 
certification criterion for the 2011 Edition EHR certification criteria 
(Sec.  170.302(w)), which requires EHR technology to be capable of 
electronically recording disclosures made for treatment, payment, and 
health care operations in accordance with the standard specified in 
Sec.  170.210(d) (``Record treatment, payment, and health care 
operations disclosures. The date, time, patient identification, user 
identification, and a description of the disclosure must be recorded 
for disclosures for treatment, payment, and health care operations, as 
these terms are defined at 45 CFR 164.501''). We are proposing to adopt 
this same certification criterion as an optional certification 
criterion for the 2014 Edition EHR certification criteria (Sec.  
170.314(d)(9)), but are requesting public comment on whether we should 
adopt a revised certification criterion. Since publication of the S&CC 
July 2010 final rule, the HHS Office for Civil Rights issued a proposed 
rule (76 FR 31426) addressing the changes required by section 13405(c) 
of the HITECH Act, including changes to the accounting of disclosure 
requirements under the HIPAA Privacy Rule.\45\ We are interested in 
whether commenters believe that the 2014 Edition EHR certification 
criterion for ``accounting of disclosures'' should be revised to be a 
mandatory certification criterion. We are also interested in whether 
commenters think that the 2014 Edition EHR certification criterion 
should be revised to include capabilities that would more fully support 
an EP's, EH's, and CAH's ability to comply with the current HIPAA 
Privacy Rule accounting for disclosure requirements at 45 CFR 164.528. 
Additionally, we are interested in receiving input on whether, and what 
additional, changes to the certification criterion would be needed to 
support compliance with the proposed HIPAA Privacy Rule accounting for 
disclosure provisions, if they were to be adopted by final rule in 
substantially the same form as they were proposed. For those commenters 
that believe revisions are appropriate, we respectfully request that 
their comments identify whether the certification criterion should be 
changed from optional to mandatory and identify the specific 
capabilities that the certification criterion should include

[[Page 13872]]

and the rationale for including those capabilities.
---------------------------------------------------------------------------

    \45\ http://www.gpo.gov/fdsys/pkg/FR-2011-05-31/pdf/2011-13297.pdf.
---------------------------------------------------------------------------

C. Disability Status

    We are interested in whether commenters believe that EHR technology 
certified to the 2014 Edition EHR certification criteria should be 
capable of recording the functional, behavioral, cognitive, and/or 
disability status of patients (collectively referred to as ``disability 
status''). The recording of disability status could have many benefits. 
It could facilitate provider identification of patients with 
disabilities and the subsequent provision of appropriate auxiliary aids 
and services for those patients by providers. It could also promote and 
facilitate the exchange of this type of patient information between 
providers of care, which could lead to better quality of care for those 
with disabilities. Further, the recording of disability status could 
help monitor disparities between the ``disabled'' and ``nondisabled'' 
population.
    We are specifically requesting comment on whether there exists a 
standard(s) that would be appropriate for recording disability status 
in EHR technology. We are aware of a standard for disability status 
approved by the Secretary for use in population health surveys 
sponsored by HHS \46\ and standards under development as part of the 
Standards and Interoperability Framework and the Continuity Assessment 
Record and Evaluation (CARE) assessment tool.\47\ We welcome comments 
on whether these standards or any other standards would be appropriate 
for recording disability status in EHR technology.
---------------------------------------------------------------------------

    \46\ http://www.minorityhealth.hhs.gov/templates/browse.aspx?lvl=2&lvlid=208.
    \47\ http://wiki.siframework.org/file/detail/CARE+Tool+Functional%2C+Cognitive+and+Skin+Status.xls.
---------------------------------------------------------------------------

    We ask that commenters consider whether the recording of disability 
status should be a required or optional capability that EHR technology 
would include for certification to the 2014 Edition EHR certification 
criteria. We also ask commenters to consider whether the recording of 
disability status should be part of a Base EHR and included in a 
separate certification criterion or possibly the ``demographics'' 
certification criterion (Sec.  170.314(a)(3)). Last, we ask commenters 
to consider whether disability status recorded according to the 
standard should also be included in other certification criteria such 
as ``transitions of care--incorporate summary care record'' (Sec.  
170.314(b)(1)), ``transitions of care--create and transmit summary care 
record'' (Sec.  170.314(b)(2)), ``view, download and transmit to 3rd 
party'' (Sec.  170.314(e)(1)), and ``clinical summaries'' (Sec.  
170.314(e)(2)).

D. Data Portability

    We seek public comment on whether we should adopt a certification 
criterion that focuses on the portability of data stored within CEHRT. 
When a provider seeks to change EHR technology, we believe that they 
should have the ability to easily switch EHR technology--at a low 
cost--and migrate most or all of their data in structured form to 
another EHR technology. In the absence of this capability, providers 
may be ``locked-in'' to their current EHR technology. This could 
ultimately impede innovation and is a key aspect of the EHR technology 
market that requires significant maturity. With these considerations, 
we seek responses to the following questions:
    1. Is EHR technology capable of electronically providing a 
sufficient amount of a patient's health history using summary of care 
records formatted according to the Consolidated CDA for the scenario 
described above?
    2. Is all of the data in a provider's EHR <greek-i>1 necessary to 
migrate over to EHR <greek-i>2 in the event the provider wants to 
switch? We recognize that medical record retention laws affect the 
provider's overall approach in terms of a full archived data set, but 
our question seeks to determine whether the loss of some data would be 
tolerable and if so, which data?
    3. Considering the standards we have adopted and propose for 
adoption in this rule, we request comment on what additional standards 
and guidance would be necessary to meet these market needs for data 
portability, including the portability of administrative data such as 
Medicare and Medicaid eligibility and claims. Additionally, we are 
interested in commenters' thoughts related to an incremental approach 
where a specific set of patient data could be used as a foundation to 
improve data portability for the situation described above as well as 
other situations.
    4. Does the concept of a capability to batch export a single 
patient's records (or a provider's entire patient population) pose 
unintended consequences from a security perspective? What factors 
should be considered to mitigate any potential abuse of this 
capability, if it existed?

E. EHR Technology Price Transparency

    Section 170.523(k)(3) requires that when an ONC-ACB issues a 
certification to a Complete EHR or EHR Module based solely on the 
applicable certification criteria adopted by the Secretary at subpart C 
of this part, the certification must be separate and distinct from any 
other certification(s) based on other criteria or requirements (such as 
those not part of the ONC HIT Certification Program). During 
implementation of the temporary certification program, we have received 
feedback from stakeholders that some EHR technology developers do not 
provide clear price transparency related to the full cost of a 
certified Complete EHR or certified EHR Module. Instead, some EHR 
technology developers identify prices for multiple groupings of 
capabilities even though the groupings do not correlate to the 
capabilities of the entire certified Complete EHR or certified EHR 
Module. Thus, with the transparency already required by Sec.  
170.523(k)(3) in mind, we believe that the EHR technology market could 
benefit from transparency related to the price associated with a 
certified Complete EHR or certified EHR Module. We believe price 
transparency could be achieved through a requirement that ONC-ACBs 
ensure that EHR technology developers include clear pricing of the full 
cost of their certified Complete EHR and/or certified EHR Module on 
their Web sites and in all marketing materials, communications, 
statements, and other assertions related to a Complete EHR's or EHR 
Module's certification. Put simply, this provision would require EHR 
technology developers to disclose only the full cost of a certified 
Complete EHR or certified EHR Module. It would in no way dictate the 
price an EHR technology developer could assign to its EHR technology, 
just that a single price for all the capabilities in the certified 
Complete EHR or certified EHR Module be made publicly available. We 
believe price transparency would provide purchasing clarity for health 
care providers and lead to more competitive EHR technology pricing. We 
request comment on the feasibility and value of price transparency for 
certified Complete EHRs and certified EHR Modules in the manner 
described.

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

[[Page 13873]]

VII. Collection of Information Requirements

    Under the Paperwork Reduction Act of 1995 (PRA), agencies are 
required to provide 60-day notice in the Federal Register and solicit 
public comment on a proposed collection of information before it is 
submitted to the Office of Management and Budget for review and 
approval. In order to fairly evaluate whether an information collection 
should be approved by the Office of Management and Budget, section 
3506(c)(2)(A) of the PRA requires that we solicit comment on the 
following issues:
    1. Whether the information collection is necessary and useful to 
carry out the proper functions of the agency;
    2. The accuracy of the agency's estimate of the information 
collection burden;
    3. The quality, utility, and clarity of the information to be 
collected; and
    4. Recommendations to minimize the information collection burden on 
the affected public, including automated collection techniques.
    Under the PRA, the time, effort, and financial resources necessary 
to meet the information collection requirements referenced in this 
section are to be considered. We explicitly seek, and will consider, 
public comment on our assumptions as they relate to the PRA 
requirements summarized in this section. To comment on the collection 
of information or to obtain copies of the supporting statements and any 
related forms for the proposed paperwork collections referenced in this 
section, email your comment or request, including your address and 
phone number to <a href="/cdn-cgi/l/email-protection#eab9828f988f9e9e8fc48c9f84848985868f878b84aa828299c48d859c"><span class="__cf_email__" data-cfemail="13407b7661766767763d75667d7d707c7f767e727d537b7b603d747c65">[email protected]</span></a>, or call the Reports 
Clearance Office at (202) 690-6162. Written comments and 
recommendations for the proposed information collections must be 
directed to the OS Paperwork Clearance Officer at the above email 
address within 60 days.

Abstract

    Under the permanent certification program, accreditation 
organizations that wish to become the ONC-Approved Accreditor (ONC--AA) 
must submit certain information, organizations that wish to become an 
ONC-Authorized Certification Bodies (ONC-ACBs) must submit the 
information specified by the application requirements, and ONC-ACBs 
must comply with collection and reporting requirements, records 
retention requirements, and submit annual surveillance plans and 
annually report surveillance results.
    In the Permanent Certification Program final rule (76 FR 1312-14), 
we solicited public comment on each of the information collections 
associated with the requirements described above (and included in 
regulation at 45 CFR 170.503(b), 170.520, and 170.523(f), (g), and (i), 
respectively). These collections of information are currently approved 
under OMB control number 0990-0378. In this proposed rule, we seek to 
revise Sec.  170.523(f) and, correspondingly, seek to revise the 
approved collection of information by requiring ONC-ACBs to include one 
additional data element in the list of information about Complete EHRs 
and EHR Modules they report to ONC.
    Section 170.523(f) requires an ONC-ACB to provide ONC, no less 
frequently than weekly, a current list of Complete EHRs and/or EHR 
Modules that have been certified as well as certain minimum information 
about each certified Complete EHR and/or EHR Module. We propose to 
require ONC-ACBs to additionally report to ONC a hyperlink with each 
EHR technology they certify that provides the public with the ability 
to access the test results used to certify the EHR technology. We 
propose to add this requirement at Sec.  170.523(f)(8).
    For the purposes of estimating this additional potential burden, we 
have used the following assumptions. We assume that all of the 
estimated applicants will apply and become ONC-ACBs (i.e., 6 
applicants) and that they will report weekly (i.e., respondents will 
respond 52 times per year). We assume an equal distribution among ONC-
ACBs in certifying EHR technology on a weekly basis. As such, based on 
the number of Complete EHRs and EHR Modules listed on the CHPL at the 
end of September of 2011 (approximately one year since the CHPL's 
inception), we estimate that, on average, each ONC-ACB will report 4 
test results hyperlinks to ONC on a weekly basis.
    We believe it will take approximately 5 minutes to report each 
hyperlink to ONC. Therefore, as reflected in the table below, we 
estimate an additional 20 minutes of work per ONC-ACB each week. Under 
the regulatory impact statement section, we discuss the estimated costs 
associated with reporting the hyperlinks to ONC.

                                        Estimated Annualized Burden Hours
----------------------------------------------------------------------------------------------------------------
                                                                  Number of      Average burden
             Type of respondent                  Number of      responses per      hours per       Total burden
                                                respondents       respondent        response          hours
----------------------------------------------------------------------------------------------------------------
45 CFR 170.523(f)(8)........................               6               52              .33              103
----------------------------------------------------------------------------------------------------------------

    With the additional proposed collection of information at Sec.  
170.523(f)(8), we believe 103 burden hours will be added to our burden 
estimate in OMB control number 0990-0378. Our estimates for the total 
burden hours under OMB control number 0990-0378 are expressed in the 
table below.

                                     Estimated Annualized Total Burden Hours
----------------------------------------------------------------------------------------------------------------
                                                                     Number of    Average burden
               Type of respondent                    Number of     responses per     hours per     Total burden
                                                    respondents     respondent       response          hours
----------------------------------------------------------------------------------------------------------------
45 CFR 170.503(b)...............................               2               1            1                  2
45 CFR 170.520..................................               6               1            1                  6
45 CFR 170.523(f)...............................               6              52            1.33             415
45 CFR 170.523(g)...............................             n/a             n/a          n/a                n/a
45 CFR 170.523(i)...............................               6               2            1                 12
                                                 ---------------------------------------------------------------

[[Page 13874]]

 
    Total burden hours for OMB control number     ..............  ..............  ..............             435
     0990-0378..................................
----------------------------------------------------------------------------------------------------------------

VIII. Regulatory Impact Statement

A. Statement of Need

    Section 3004(b)(1) of the PHSA requires the Secretary to adopt an 
initial set of standards, implementation specifications, and 
certification criteria. On January 13, 2010, the Department issued an 
interim final rule with a request for comments to adopt an initial set 
of standards, implementation specifications, and certification 
criteria. On July 28, 2010, the Department published in the Federal 
Register a final rule to complete the adoption of the initial set of 
standards, implementation specifications, and certification criteria. 
This proposed rule is being published to revise previously adopted 
standards, implementation specifications, and certification criteria 
and to propose the adoption of new standards, implementation 
specifications, and certification criteria in order to support future 
MU Stages' objectives and measures. Certification criteria and 
associated standards and implementation specifications will be used to 
test and certify Complete EHRs and EHR Modules in order to make it 
possible for EPs, EHs, and CAHs to adopt and implement CEHRT. EPs, EHs, 
and CAHs who seek to qualify for incentive payments under the EHR 
Incentive Programs are required by statute to use CEHRT.

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 because we estimate that the costs to prepare Complete 
EHRs and EHR Modules to be tested and certified will 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 that would establish the 
capabilities that EHR technology would need to demonstrate to be 
certified. 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 Complete EHRs and EHR Modules to be tested and 
certified in accordance with the certification criteria adopted by the 
Secretary. That is, we focus on the technological development and 
preparation costs necessary for a Complete EHR or EHR Module already 
certified to the 2011 Edition EHR certification criteria to upgrade to 
the proposed 2014 Edition EHR certification criteria and for developing 
a new Complete EHR or EHR Module to meet the 2014 Edition EHR 
certification criteria. The estimated costs for having EHR technology 
actually tested and certified were discussed in the permanent 
certification program final rule (76 FR 1318-23). Last, we estimate the 
costs for ONC-ACBs to develop and report to ONC hyperlinks to the test 
results used to certify EHR technology.
i. Development and Preparation Costs for 2014 Edition EHR Certification 
Criteria
    The development costs we estimate are categorized based on the type 
of certification criteria discussed in this proposed rule (i.e., new, 
revised, and unchanged). The numbers of Complete EHRs and EHR Modules 
that we estimate would be tested and certified to each certification 
criteria are based on the statistics we obtained from the CHPL on 
September 11, 2011. We attempted to identify the total number of unique 
Complete EHRs and EHR Modules that had been certified to the 2011 
Edition EHR certification criteria as of September 11th. By this we 
mean that we attempted to discern how many Complete EHRs and EHR 
Modules were certified that would not constitute a newer version of the 
same EHR technology. Using this number, we have adjusted it based on 
additional considerations such as our proposals related to optional 
certification criteria, to the Base EHR certification criteria, and to 
our revised definition of CEHRT. The proposed revised CEHRT definition 
would only require 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. Using the final estimate of Complete EHRs and EHR Modules 
that we believe will be certified to each certification criterion, we 
have then created an estimated range of 10% less and 10% more EHR 
technologies being developed to each 2014 Edition EHR certification 
criterion. We believe this will account for potential new entrants to 
the market, as well as for those EHR technologies tested and certified 
to the 2011 Edition EHR certification criteria that may not be tested 
and certified to the 2014 Edition EHR certification criteria because of 
such factors and company mergers or acquisitions and the loss of market 
share for some Complete EHRs and EHR Modules. For unchanged 
certification criteria, we have only calculated development and 
preparation costs for a potential 10% increase in new EHR technologies 
being developed and prepared to meet the certification criteria since 
there would not be any costs associated with upgrading EHR technologies 
previously certified to the 2011 Edition EHR certification criteria.

[[Page 13875]]

    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 2011 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 2014 Edition EHR certification criteria. 
Therefore, we have relied upon our own research to estimate the effort 
required to develop and prepare EHR technology to meet the requirements 
of the 2014 Edition EHR certification criteria. We have identified 3 
levels of effort that we believe can be associated with the development 
and preparation of EHR technology to meet the requirements of the 2014 
Edition EHR certification criteria. 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 2014 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 
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.
    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 $43.47.\48\ We have also calculated the costs of an 
employee's benefits. We have calculated these costs 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 $60 per hour.
---------------------------------------------------------------------------

    \48\ 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 7 through Table 13), dollar amounts are expressed in 2012 
dollars.
New Certification Criteria

                      Table 7--2014 Edition New EHR Certification Criteria: Level 1 Effort
----------------------------------------------------------------------------------------------------------------
                                                                     Estimated        Average development and
                                                                   <greek-i> of          preparation costs
                                                                        EHR      -------------------------------
                                          Title of regulation      technologies
          Regulation section                   paragraph               to be
                                                                  developed with     Low ($M)        High ($M)
                                                                       this
                                                                    capability
----------------------------------------------------------------------------------------------------------------
170.314(a)(9)........................  Electronic notes.........         420-514            1.01            3.08
170.314(a)(13).......................  Family health history....         420-514            1.01            3.08
170.314(b)(3)........................  Electronic prescribing            101-123             .24             .74
                                        (inpatient).
170.314(f)(7)........................  Cancer case information..         320-392             .77            2.35
170.314(g)(3)........................  Non-percentage-based              567-693            1.36            4.16
                                        measure use report.
                                      --------------------------------------------------------------------------
    Total............................  .........................  ..............            4.39           13.41
----------------------------------------------------------------------------------------------------------------


                      Table 8--2014 Edition New EHR Certification Criteria: Level 2 Effort
----------------------------------------------------------------------------------------------------------------
                                                                     Estimated        Average development and
                                                                   <greek-i> of          preparation costs
                                                                        EHR      -------------------------------
                                          Title of regulation      technologies
          Regulation section                   paragraph               to be
                                                                  developed with     Low  ($M)      High  ($M)
                                                                       this
                                                                    capability
----------------------------------------------------------------------------------------------------------------
170.314(a)(12).......................  Imaging..................         420-514            2.52            9.25
170.314(b)(6)........................  Transmission of                   146-178             .88            3.20
                                        electronic laboratory
                                        tests and values/results
                                        to ambulatory providers.
170.314(d)(4)........................  Amendments...............         566-691            3.40           12.44
170.314(e)(3)........................  Secure messaging.........         320-392            1.92            7.06
170.314(f)(8)........................  Transmission to cancer            320-392            1.92            7.06
                                        registries.
170.314(g)(1)........................  Automated numerator               398-486            2.39            8.75
                                        recording.
                                                                 -----------------------------------------------
    Total............................  .........................  ..............           13.03           47.76
----------------------------------------------------------------------------------------------------------------


[[Page 13876]]


                      Table 9--2014 Edition New EHR Certification Criteria: Level 3 Effort
----------------------------------------------------------------------------------------------------------------
                                                                     Estimated        Average development and
                                                                   <greek-i> of          preparation costs
                                                                        EHR      -------------------------------
                                          Title of regulation      technologies
          Regulation section                   paragraph               to be
                                                                  developed with     Low  ($M)      High  ($M)
                                                                       this
                                                                    capability
----------------------------------------------------------------------------------------------------------------
170.314(a)(17).......................  Electronic medication             101-123            1.82            2.95
                                        administration record.
170.314(e)(1)........................  View, download, and               567-693           10.21           16.63
                                        transmit to 3rd party.
170.314(g)(4)........................  Safety-enhanced design...         567-693           10.21           16.63
                                                                 -----------------------------------------------
    Total............................  .........................  ..............           22.24           36.21
----------------------------------------------------------------------------------------------------------------

Revised Certification Criteria

                    Table 10--2014 Edition Revised EHR Certification Criteria: Level 1 Effort
----------------------------------------------------------------------------------------------------------------
                                                                     Estimated        Average development and
                                                                   <greek-i> of          preparation costs
                                                                        EHR      -------------------------------
                                          Title of regulation      technologies
          Regulation section                   paragraph               to be
                                                                  developed with     Low  ($M)      High  ($M)
                                                                       this
                                                                    capability
----------------------------------------------------------------------------------------------------------------
170.314(a)(2)........................  Drug-drug, drug-allergy           420-514            1.01            3.08
                                        interaction checks.
170.314(a)(3)........................  Demographics.............         460-562            1.10            3.37
170.314(a)(5)........................  Problem list.............         438-536            1.05            3.22
170.314(a)(16).......................  Patient-specific                  421-515            1.01            3.09
                                        education resources.
170.314(b)(3)........................  Electronic prescribing            328-400             .79            2.40
                                        (ambulatory).
170.314(b)(5)........................  Incorporate laboratory            277-339             .66            2.03
                                        tests and values/results
                                        (ambulatory setting).
170.314(c)(2)........................  Clinical quality                  379-463             .91            2.78
                                        measures--incorporate
                                        and calculate.
170.314(d)(3)........................  Audit report(s)..........         567-693            1.36            4.16
170.314(e)(2)........................  Clinical summaries.......         314-384             .75            2.30
170.314(f)(2)........................  Transmission to                   382-466             .92            2.80
                                        immunization registries.
170.314(f)(4)........................  Transmission to public            373-455             .90            2.73
                                        health agencies.
170.314(f)(6)........................  Transmission of                     63-77             .15             .46
                                        reportable laboratory
                                        tests and values/results.
                                                                 -----------------------------------------------
    Total............................  .........................  ..............           10.61           32.42
----------------------------------------------------------------------------------------------------------------


                    Table 11--2014 Edition Revised EHR Certification Criteria: Level 2 Effort
----------------------------------------------------------------------------------------------------------------
                                                                     Estimated        Average development and
                                                                   <greek-i> of          preparation costs
                                                                        EHR      -------------------------------
                                          Title of regulation      technologies
          Regulation section                   paragraph               to be
                                                                  developed with     Low  ($M)      High  ($M)
                                                                       this
                                                                    capability
----------------------------------------------------------------------------------------------------------------
170.314(b)(1)........................  Transitions of care--             381-465            2.29            8.37
                                        incorporate summary care
                                        record.
170.314(b)(4)........................  Clinical information              434-530            2.60            9.54
                                        reconciliation.
170.314(c)(3)........................  Clinical quality                  379-463            2.27            8.33
                                        measures--reporting.
170.314(d)(2)........................  Auditable events and              567-693            3.40           12.47
                                        tamper resistance.
170.314(d)(7)........................  Encryption of data at             566-691            3.40           12.44
                                        rest.
170.314(g)(2)........................  Automated measure                 396-484            2.21            8.71
                                        calculation.
                                                                 -----------------------------------------------
    Total............................  .........................  ..............           16.17           59.86
----------------------------------------------------------------------------------------------------------------


                    Table 12--2014 Edition Revised EHR Certification Criteria: Level 3 Effort
----------------------------------------------------------------------------------------------------------------
                                                                     Estimated        Average development and
                                                                   <greek-i> of          preparation costs
                                                                        EHR      -------------------------------
                                          Title of regulation      technologies
          Regulation section                   paragraph               to be
                                                                  developed with     Low  ($M)      High  ($M)
                                                                       this
                                                                    capability
----------------------------------------------------------------------------------------------------------------
170.314(a)(8)........................  Clinical decision support         409-501            7.36           12.02
170.314(b)(2)........................  Transitions of care--             381-465            6.86           11.16
                                        create and transmit.
170.314(c)(1)........................  Clinical quality                  379-463            6.82           11.11
                                        measures--capture and
                                        export.
                                                                 -----------------------------------------------
    Total............................  .........................  ..............           21.04           34.29
----------------------------------------------------------------------------------------------------------------

Unchanged Certification Criteria

[[Page 13877]]



                   Table 13--2014 Edition Unchanged EHR Certification Criteria: Level 2 Effort
----------------------------------------------------------------------------------------------------------------
                                                                     Estimated        Average development and
                                                                   <greek-i> of          preparation costs
                                                                        EHR      -------------------------------
                                          Title of regulation      technologies
          Regulation section                   paragraph               to be
                                                                  developed with     Low  ($M)      High  ($M)
                                                                       this
                                                                    capability
----------------------------------------------------------------------------------------------------------------
170.314(a)(1)........................  CPOE.....................              42             .25             .76
170.314(a)(4)........................  Vital signs, body mass                 48             .29             .86
                                        index, and growth charts.
170.314(a)(6)........................  Medication list..........              50             .30             .90
170.314(a)(7)........................  Medication allergy list..              50             .30             .90
170.314(a)(10).......................  Drug-formulary checks....              47             .28             .85
170.314(a)(11).......................  Smoking status...........              50             .30             .90
170.314(a)(14).......................  Patient lists............              46             .28             .83
170.314(a)(15).......................  Patient reminders........              36             .22             .65
170.314(a)(18).......................  Advance directives.......              11             .07             .20
170.314(b)(5)........................  Incorporate laboratory                 16             .10             .29
                                        tests and values/results
                                        (inpatient setting).
170.314(d)(1)........................  Authentication, access                 64             .38            1.15
                                        control, and
                                        authorization.
170.314(d)(5)........................  Automatic log-off........              63             .38            1.13
170.314(d)(6)........................  Emergency access.........              62             .37            1.12
170.314(d)(8)........................  Integrity................              63             .38            1.13
170.314(d)(9)........................  Accounting of disclosures              15             .09             .27
170.314(f)(1)........................  Immunization information.              42             .25             .76
170.314(f)(3)........................  Public health                          41             .25             .74
                                        surveillance.
170.314(f)(5)........................  Reportable laboratory                   7             .04             .13
                                        tests and values/results.
                                                                 -----------------------------------------------
    Total............................  .........................  ..............            4.53           13.57
----------------------------------------------------------------------------------------------------------------

ii. Overall Development and Preparation Costs Over a 3-year Period
    In total, we estimate the overall costs for a 3-year period to be 
$92.01 million to $237.52 million, with a cost mid-point of 
approximately $164.77 million. If we were to evenly distribute the 
overall costs to develop and prepare Complete EHRs and EHR Modules 
between calendar years 2012 and 2014, we believe they would likely be 
in the range of $30.67 million to $79.17 million per year with an 
annual cost mid-point of approximately $54.92 million. However, we do 
not believe that the costs will be spread evenly over these three years 
due to market pressures to have certified Complete EHRs and certified 
EHR Modules ready and available prior to when EPs, EHs, and CAHs must 
meet the proposed revised definition of CEHRT for FY/CY 2014. We assume 
this factor will cause a greater number of developers to prepare EHR 
technology for testing and certification towards the end of 2012 and 
throughout 2013, rather than in 2014. As a result, we believe as 
represented in Table 14 that the costs attributable to this proposed 
rule will be distributed as follows: 40% for 2012, 50% for 2013, and 
10% for 2014. The dollar amounts expressed in Table 14 are expressed in 
2012 dollars.

  Table 14.-- Distributed Total Preparation Costs for Complete EHR and EHR Module Developers (3 Year Period)--
                                                 Totals Rounded
----------------------------------------------------------------------------------------------------------------
                                                                                    Total high     Total average
                      Year                             Ratio      Total low cost   cost estimate   cost estimate
                                                     (percent)    estimate  ($M)       ($M)            ($M)
----------------------------------------------------------------------------------------------------------------
2012............................................              40           36.80           95.01           65.91
2013............................................              50           46.01          118.76           82.38
2014............................................              10            9.20           23.75           16.48
                                                 ---------------------------------------------------------------
3-Year Totals...................................  ..............           92.01          237.52          167.53
----------------------------------------------------------------------------------------------------------------

iii. Costs for Reporting Test Results Hyperlinks
Costs to ONC-ACBs
    Under Sec.  170.523(f)(8), ONC-ACBs will be required to provide 
ONC, no less frequently than weekly, a hyperlink with each EHR 
technology it certifies that provides the public with the ability to 
access the test results used to certify the EHR technology. As stated 
in the collection of information section, we will require the reporting 
of this information on a weekly basis and that it will take each ONC-
ACB about 20 minutes to prepare and electronically transmit an 
estimated four test results hyperlinks with the other required 
information to ONC each week.
    We believe that an employee equivalent to the Federal 
Classification of GS-9 Step 1 could report the hyperlink to ONC. We 
have utilized the corresponding employee hourly rate for the locality 
pay area of Washington, DC, as published by OPM, to calculate our cost 
estimates. We have also calculated the costs of the employee's benefits 
while completing the specified tasks. We have calculated these costs by 
assuming that an ONC-ACB 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. 
Our cost estimates are expressed in Table 15 below and are expressed in 
2012 dollars.

[[Page 13878]]



                                     Table 15--Annual Costs for an ONC-ACB To Report Test Results Hyperlinks to ONC
--------------------------------------------------------------------------------------------------------------------------------------------------------
                                                                                       Annual burden                        Employee
               Program requirement                        Employee equivalent          hours per ONC-  Employee hourly      Benefits      Total cost per
                                                                                            ACB           wage rate       Hourly Cost        ONC-ACB
--------------------------------------------------------------------------------------------------------------------------------------------------------
45 CFR 170.523(f)(8)............................  GS-9 Step 1.......................           17.16           $22.39            $8.06          $522.52
--------------------------------------------------------------------------------------------------------------------------------------------------------

    To estimate the highest possible cost, we assume that all of the 
estimated applicants (i.e., six) that we anticipate will apply under 
the permanent certification program will become ONC-ACBs. Therefore, we 
estimate the total annual development and reporting cost for under the 
permanent certification program to be $3,136 (rounded using a total of 
103 hours).
Costs to the Federal Government
    We do not believe that we will incur any additional costs to post 
test results hyperlinks than the costs we estimated for posting a list 
of all certified Complete EHRs and EHR Modules on our Web site (i.e., 
the CHPL), which was $10,784 on an annualized basis (76 FR 1323).
b. Benefits
    We believe that there will be several benefits that may arise from 
this proposed rule. Foremost, the proposed 2014 Edition EHR 
certification criteria include the capabilities that CEHRT must have to 
support EPs', EHs', and CAHs' attempts to demonstrate MU and qualify 
for incentive payments under the EHR Incentive Programs. Additionally, 
by adopting the proposed new and revised certification criteria, the 
interoperability, functionality, utility, and security of EHR 
technology will be further enhanced. The capabilities specified in the 
adopted certification criteria will help ensure that health care 
providers have the necessary information technology tools to improve 
patient care, and reduce medical errors and unnecessary tests. The 
standards adopted will aid in fostering greater interoperability. The 
proposals in this proposed rule would increase the competition and 
innovation in the HIT marketplace that was spurred by the Secretary's 
adoption of the 2011 Edition EHR certification criteria. The proposals 
to revise the definition of CEHRT, the process for approving newer 
versions of minimum standards, and the privacy and security 
certification of EHR Modules will reduce the regulatory burden and add 
flexibility for EHR technology developers, EPs, EHs, and CAHs. Further, 
the proposed splitting of certification criteria into multiple 
certification criteria should increase the opportunity and flexibility 
for EHR technology developers to have more EHR technology eligible for 
certification. Last, we believe the proposals in this proposed rule 
will be supportive of other initiatives, such as the Partnership for 
Patients.
2. Regulatory Flexibility Act
    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 Complete 
EHRs and EHR Module developers 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 \49\ which ``indicates the maximum allowed for a 
concern and its affiliates to be considered small entities.''
---------------------------------------------------------------------------

    \49\ 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/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 Complete EHR or EHR Module. 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 Complete EHR and EHR Module developers 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 the Complete EHR 
and EHR Module developers to correlate to the SBA size standard. 
However, although not correlated to the size standard for NAICS code 
541511, we do have information indicating that over 60% of EHR 
technology developers that have had Complete EHRs and/or EHR Modules 
certified to the 2011 Edition EHR certification criteria have less than 
51 employees.
    We estimate that this proposed rule would have effects on Complete 
EHR and EHR Module developers, 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. In order for a Complete EHR or EHR 
Module to provide the capabilities that an EP, EH, or CAH would be 
required to use under the EHR Incentive Programs Stage 2 final rule, it 
will need to comply with the applicable certification criteria adopted 
by the Secretary. Moreover, we note that this proposed rule does not 
impose the costs cited in the regulatory impact analysis as compliance 
costs, but rather as investments which Complete EHR and EHR Module 
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. The Secretary certifies that this proposed rule will 
not have a significant impact on a substantial number of small 
entities. We do, however, 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.
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

[[Page 13879]]

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 1 year of $100 million in 
1995 dollars, updated annually for inflation. The current inflation-
adjusted statutory threshold is approximately $136 million. This final 
rule will not impose an unfunded mandate on State, local, and tribal 
governments or on the private sector that will reach the threshold 
level.
    The Office of Management and Budget 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 recordkeeping requirements, Public 
health, Security.

    For the reasons set forth in the preamble, 45 CFR subtitle A, 
subchapter D, part 170, proposes to amend as follows:

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

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

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

    2. Amend Sec.  170.102 by adding in alphanumeric order the 
definitions ``2011 Edition EHR certification criteria,'' ``2014 Edition 
EHR certification criteria,'' and ``Base EHR'' and revising the 
definitions of ``Certified EHR Technology'' and ``Complete EHR'' to 
read as follows:


Sec.  170.102  Definitions.

* * * * *
    2011 Edition EHR certification criteria means the certification 
criteria at Sec. Sec.  170.302, 170.304, and 170.306.
    2014 Edition EHR certification criteria means the certification 
criteria at Sec.  170.314.
    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) Meets the certification criteria adopted by the Secretary at: 
Sec.  170.314(a)(1) through (8); (b)(1) and (2); (c)(1) and (2); (d)(1) 
through (8); and (e)(1).
* * * * *
    Certified EHR Technology means:
    (1) For any Federal fiscal year (FY) or calendar year (CY) up to 
and including 2013:
    (i) A Complete EHR that meets the requirements included in the 
definition of a Qualified EHR and has been tested and certified in 
accordance with the certification program established by the National 
Coordinator as having met all applicable certification criteria adopted 
by the Secretary for the 2011 Edition EHR certification criteria or the 
equivalent 2014 Edition EHR certification criteria; or
    (ii) A combination of EHR Modules in which each constituent EHR 
Module of the combination has been tested and certified in accordance 
with the certification program established by the National Coordinator 
as having met all applicable certification criteria adopted by the 
Secretary for the 2011 Edition EHR certification criteria or the 
equivalent 2014 Edition EHR certification criteria, and the resultant 
combination also meets the requirements included in the definition of a 
Qualified EHR.
    (2) For FY and CY 2014 and subsequent years, the following: EHR 
technology certified under the ONC HIT Certification Program to the 
2014 Edition EHR certification criteria that has:
    (i) The capabilities required to meet the definition of a Base EHR; 
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.
    Complete EHR means EHR technology that has been developed to meet, 
at a minimum, all mandatory certification criteria of an edition of 
certification criteria adopted by the Secretary for either an 
ambulatory setting or inpatient setting.
* * * * *
    3. Add Sec.  170.202 to read as follows:


Sec.  170.202  Transport standards.

    The Secretary adopts the following transport standards:
    (a) Directed exchange. (1) Standard. Applicability Statement for 
Secure Health Transport (incorporated by reference in Sec.  170.299).
    (2) Standard. External Data Representation and Cross-Enterprise 
Document Media Interchange for Direct Messaging (incorporated by 
reference in Sec.  170.299).
    (3) Standard. Simple Object Access Protocol (SOAP)-Based Secure 
Transport Requirements Traceability Matrix (RTM) version 1.0 
(incorporated by reference in Sec.  170.299).
    (b) [Reserved]
    4. Add Sec.  170.204 to read as follows:


Sec.  170.204  Functional standards.

    The Secretary adopts the following functional standards:
    (a) Accessibility. Standard. Web Content Accessibility Guidelines 
(WCAG) 2.0, Level AA Conformance (incorporated by reference in Sec.  
170.299).
    (b) Reference source. Standard. Health Level Seven Context-Aware 
Knowledge Retrieval (Infobutton), International Normative Edition 2010 
(incorporated by reference in Sec.  170.299).
    (c) Clinical quality measure data capture and export. Standard. 
National Quality Forum (NQF) Quality Data Model, Version 2011 
(incorporated by reference in Sec.  170.299).
    5. In Sec.  170.205, republish the introductory text and add 
paragraphs (a)(3), (d)(3), (e)(3), and (g) through (k) to 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

[[Page 13880]]

associated implementation specifications:
    (a) * * *
    (3) Standard. HL7 Implementation Guide for Clinical Document 
Architecture, Release 2.0 (Consolidated CDA) (US Realm), Draft, 
September 2011 (incorporated by reference in Sec.  170.299).
* * * * *
    (d) * * *
    (3) Standard. HL7 2.5.1 (incorporated by reference in Sec.  
170.299). Implementation specifications. PHIN Messaging Guide for 
Syndromic Surveillance: Emergency Department and Urgent Care Data HL7 
Version 2.5.1 (incorporated by reference in Sec.  170.299).
    (e) * * *
    (3) 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.3 (incorporated by reference in 
Sec.  170.299).
* * * * *
    (g) Electronic transmission of lab results to public health 
agencies. 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 (US Realm) with errata (incorporated by reference in Sec.  
170.299).
    (h) [Reserved]
    (i) Cancer information. Standard. HL7 Clinical Document 
Architecture (CDA), Release 2 (incorporated by reference in Sec.  
170.299). Implementation specifications. Implementation Guide for 
Healthcare Provider Reporting to Central Cancer Registries, Draft, 
February 2012 (incorporated by reference in Sec.  170.299).
    (j) Imaging. Digital Imaging and Communications in Medicine (DICOM) 
PS 3--2011.
    (k) Electronic incorporation and transmission of lab results. 
Standard. HL7 2.5.1 (incorporated by reference in Sec.  170.299). 
Implementation specifications. HL7 Version 2.5.1 Implementation Guide: 
Standards and Interoperability Framework Lab Results Interface, Release 
1 (US Realm) (incorporation by reference in Sec.  170.299).
    6. In Sec.  170.207, republish the introductory text, revise 
paragraph (f), and add paragraphs (a)(3), (b)(3), and (g) through (m) 
to 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) * * *
    (3) Standard. International Health Terminology Standards 
Development Organization (IHTSDO) Systematized Nomenclature of Medicine 
Clinical Terms (SNOMED CT[supreg]) International Release January 2012 
(incorporated by reference in Sec.  170.299).
    (b) * * *
    (3) Standard. The code set specified at 45 CFR 162.1002(c)(3).
* * * * *
    (f) Race and Ethnicity. Standard. The Office of Management and 
Budget Standards for Maintaining, Collecting, and Presenting Federal 
Data on Race and Ethnicity, Statistical Policy Directive No. 15, as 
revised, October 30, 1997 (see ``Revisions to the Standards for the 
Classification of Federal Data on Race and Ethnicity,'' available at 
http://www.whitehouse.gov/omb/fedreg_1997standards).
    (g) Laboratory tests. Standard. Logical Observation Identifiers 
Names and Codes (LOINC[supreg]) version 2.38 (incorporated by reference 
in Sec.  170.299).
    (h) Medications. Standard. RxNorm, a standardized nomenclature for 
clinical drugs produced by the United States National Library of 
Medicine, February 6, 2012 Release (incorporated by reference in Sec.  
170.299).
    (i) Immunizations. Standard. HL7 Standard Code Set CVX--Vaccines 
Administered, August 15, 2011 version (incorporated by reference in 
Sec.  170.299).
    (j) Preferred language. Standard. ISO 639-1:2002 (incorporated by 
reference in Sec.  170.299).
    (k) Preliminary determination of cause of death. Standard. The code 
set specified at 45 CFR 162.1002(c)(2) for the indicated conditions.
    (l) Smoking status. Standard. Smoking status types must include: 
Current every day smoker; current some day smoker; former smoker; never 
smoker; smoker, current status unknown; and unknown if ever smoked.
    (m) Encounter diagnoses. Standard. The code set specified at 45 CFR 
162.1002(c)(2) for the indicated conditions.
    7. In Sec.  170.210 republish the introductory text and add 
paragraphs (e), (f), and (g) to read as follows:


Sec.  170.210  Standards for health information technology to protect 
electronic health information created, maintained, and exchanged.

    The Secretary adopts the following standards to protect electronic 
health information created, maintained, and exchanged:
* * * * *
    (e) Record actions related to electronic health information, audit 
log status, and encryption of end-user devices. (1) When EHR technology 
is used to create, change, access, or delete electronic health 
information, the following information must be recorded:
    (i) The electronic health information affected by the action(s);
    (ii) The date and time each action occurs in accordance with the 
standard specified at Sec.  170.210(g);
    (iii) The action(s) that occurred;
    (iv) Patient identification; and
    (v) User identification.
    (2) When the audit log is enabled or disabled, the following must 
be recorded:
    (i) The date and time each action occurs in accordance with the 
standard specified at Sec.  170.210(g); and
    (ii) User identification.
    (3) As applicable, when encryption of electronic health information 
managed by EHR technology on end-user devices is enabled or disabled, 
the following must be recorded:
    (i) The date and time each action occurs in accordance with the 
standard specified at Sec.  170.210(g); and
    (ii) User identification.
    (f) Encryption and hashing of electronic health information. Any 
encryption and hashing algorithm identified by the National Institute 
of Standards and Technology (NIST) as an approved security function in 
Annex A of the Federal Information Processing Standards (FIPS) 
Publication 140-2 (incorporated by reference in Sec.  170.299).
    (g) Synchronized clocks. The date and time recorded utilize a 
system clock that has been synchronized following Request for Comments 
(RFC) 1305 Network Time Protocol (NTP) v3 (incorporated by reference in 
Sec.  170.299) or RFC 5905 NTPv4 (incorporated by reference in Sec.  
170.299).
    8. In Sec.  170.300, republish paragraphs (a) and (b), revise 
paragraph (c) and add paragraph (d) to read as follows:


Sec.  170.300  Applicability.

    (a) The certification criteria adopted in this subpart apply to the 
testing and certification of Complete EHRs and EHR Modules.
    (b) When a certification criterion refers to two or more standards 
as alternatives, the use of at least one of the alternative standards 
will be considered compliant.
    (c) Complete EHRs and EHR Modules are not required to be compliant 
with certification criteria or capabilities specified within a 
certification criterion that are designated as optional.
    (d) In Sec.  170.314, all certification criteria and all 
capabilities specified

[[Page 13881]]

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.
    9. Add Sec.  170.314 to subpart C to read as follows:


Sec.  170.314  2014 Edition electronic health record certification 
criteria.

    The Secretary adopts the following certification criteria for 
Complete EHRs or EHR Modules. Complete EHRs or EHR Modules 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. Enable a user to 
electronically record, change, and access the following order types, at 
a minimum:
    (i) Medications;
    (ii) Laboratory; and
    (iii) Radiology/imaging.
    (2) Drug-drug, drug-allergy interaction checks.
    (i) Interventions. Before a medication order is placed during 
computerized provider order entry (CPOE), interventions must 
automatically and electronically indicate to a user at the point of 
care of drug-drug and drug-allergy contraindications based on 
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.
    (3) Demographics.
    (i) Enable a user to electronically record, change, and access 
patient demographic data including preferred language, gender, 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(j) and whether a patient declines 
to specify a preferred language.
    (ii) Inpatient setting only. Enable a user to electronically 
record, change, and access preliminary cause of death in the event of a 
mortality in accordance with the standard specified in Sec.  
170.207(k).
    (4) Vital signs, body mass index, and growth charts.
    (i) Vital signs. Enable a user to electronically record and change, 
and access recordings of a patient's vital signs including, at a 
minimum, height/length, weight, and blood pressure.
    (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.
    (5) Problem list. Enable a user to electronically record, change, 
and access a patient's problem list for longitudinal care in accordance 
with, at a minimum, the version of the standard specified in Sec.  
170.207(a)(3).
    (6) Medication list. Enable a user to electronically record, 
change, and access a patient's active medication list as well as 
medication history for longitudinal care.
    (7) 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 for longitudinal care.
    (8) Clinical decision support.
    (i) Evidence-based decision support interventions. Enable a user to 
select (or activate) one or more electronic clinical decision support 
interventions (in addition to drug-drug and drug-allergy 
contraindication checking) based on the data elements included in each 
one or any combination of the following:
    (A) Problem list;
    (B) Medication list;
    (C) Medication allergy list;
    (D) Demographics;
    (E) Laboratory tests and values/results; and
    (F) Vital signs.
    (ii) Linked referential clinical decision support.
    (A) Enable a user to retrieve diagnostic or therapeutic reference 
information in accordance with the standard specified at Sec.  
170.204(b)(1).
    (B) Enable a user to access the reference information specified in 
paragraph (a)(8)(ii)(A) of this section relevant to patient context 
based on the data elements included in each one or any combination of 
the following:
    (1) Problem list;
    (2) Medication list;
    (3) Medication allergy list;
    (4) Demographics;
    (5) Laboratory tests and values/results; and
    (6) Vital signs.
    (iii) Configure clinical decision support.
    (A) Enable interventions and reference resources specified in 
paragraphs (a)(8)(i) and (ii) of this section to be configured by an 
identified set of users (e.g., system administrator) based on each one 
of the following:
    (1) A user's role;
    (2) Clinical setting; and
    (3) Identified points in the clinical workflow.
    (B) Enable interventions to be triggered, based on the data 
elements specified in paragraph (a)(8)(i) of this section, when a 
summary care record is incorporated pursuant to Sec.  170.314(b)(1).
    (iv) Automatically and electronically interact. Interventions 
selected and configured in accordance with paragraphs (a)(8)(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 for 
each intervention or reference source for all clinical decision support 
resources including:
    (A) Bibliographic citation (clinical research/guideline) including 
publication;
    (B) Developer of the intervention (translation from clinical 
research/guideline);
    (C) Funding source of intervention development technical 
implementation; and
    (D) Release and, if applicable, revision date of the intervention.
    (9) Electronic notes. Enable a user to electronically record, 
change, access, and search electronic notes.
    (10) Drug-formulary checks. Enable a user to electronically check 
if drugs are in a formulary or preferred drug list.
    (11) 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(l).
    (12) Imaging. Electronically indicate to a user the availability of 
a patient's images and/or narrative interpretations (relating to the 
radiographic or other diagnostic test(s)) and enable immediate 
electronic access to such images and narrative interpretations.
    (13) Family health history. Enable a user to electronically record, 
change,

[[Page 13882]]

and access a patient's family health history.
    (14) Patient lists. Enable a user to electronically select, sort, 
access, and create lists of patients according to, at a minimum, the 
data elements included in:
    (i) Problem list;
    (ii) Medication list;
    (iii) Demographics; and
    (iv) Laboratory tests and values/results.
    (15) Ambulatory setting only--patient reminders. Enable a user to 
electronically create a patient reminder list for preventive or follow-
up care according to patient preferences based on, at a minimum, the 
data elements included in:
    (i) Problem list;
    (ii) Medication list;
    (iii) Medication allergy list;
    (iv) Demographics; and
    (v) Laboratory tests and values/results.
    (16) Patient-specific education resources. Enable a user to 
electronically identify and provide patient-specific education 
resources according to:
    (i) At a minimum, each one of the data elements included in the 
patient's: problem list; medication list; and laboratory tests and 
values/results; and
    (ii) The standard specified at Sec.  170.204(b)(1).
    (17) 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)(17)(i)(A) through (D) 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.
    (ii) Right time. Electronically record the time and date in 
accordance with the standard specified in Sec.  170.210(g), and user 
identification when a medication is administered.
    (18) Inpatient setting only--advance directives. Enable a user to 
electronically record whether a patient has an advance directive.
    (b) Care coordination.
    (1) Transitions of care--incorporate summary care record. Upon 
receipt of a summary care record formatted according to the standard 
adopted at Sec.  170.205(a)(3), electronically incorporate, at a 
minimum, the following data elements: Patient name; gender; race; 
ethnicity; preferred language; date of birth; smoking status; vital 
signs; medications; medication allergies; problems; procedures; 
laboratory tests and values/results; the referring or transitioning 
provider's name and contact information; hospital admission and 
discharge dates and locations; discharge instructions; reason(s) for 
hospitalization; care plan, including goals and instructions; names of 
providers of care during hospitalizations; and names and contact 
information of any additional known care team members beyond the 
referring or transitioning provider and the receiving provider.
    (2) Transitions of care--create and transmit summary care record.
    (i) Enable a user to electronically create a summary care record 
formatted according to the standard adopted at Sec.  170.205(a)(3) and 
that includes, at a minimum, the following data elements expressed, 
where applicable, according to the specified standard(s):
    (A) Patient name; gender; date of birth; medication allergies; 
vital signs; laboratory tests and values/results; the referring or 
transitioning provider's name and contact information; names and 
contact information of any additional care team members beyond the 
referring or transitioning provider and the receiving provider; care 
plan, including goals and instructions;
    (B) Race and ethnicity. The standard specified in Sec.  170.207(f);
    (C) Preferred language. The standard specified in Sec.  170.207(j);
    (D) Smoking status. The standard specified in Sec.  170.207(1);
    (E) Problems. At a minimum, the version of the standard specified 
in Sec.  170.207(a)(3);
    (F) Encounter diagnoses. The standard specified in Sec.  
170.207(m);
    (G) Procedures. The standard specified in Sec.  170.207(b)(2) or 
Sec.  170.207(b)(3);
    (H) Laboratory test(s). At a minimum, the version of the standard 
specified in Sec.  170.207(g);
    (I) Laboratory value(s)/result(s). The value(s)/results of the 
laboratory test(s) performed;
    (J) Medications. At a minimum, the version of the standard 
specified in Sec.  170.207(h); and
    (K) Inpatient setting only. Hospital admission and discharge dates 
and location; names of providers of care during hospitalizations; 
discharge instructions; and reason(s) for hospitalization.
    (ii) Transmit. Enable a user to electronically transmit the summary 
care record created in paragraph (b)(2)(i) of this section in 
accordance with:
    (A) The standards specified in Sec.  170.202(a)(1) and (2).
    (B) Optional. The standard specified in Sec.  170.202(a)(3).
    (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(h).
    (4) Clinical information reconciliation. Enable a user to 
electronically reconcile the data elements that represent a patient's 
active medication, problem, and medication allergy list as follows. For 
each list type:
    (i) Electronically display the data elements from two or more 
sources in a manner that allows a user to view the data elements and 
their attributes, which must include, at a minimum, the source and last 
modification date.
    (ii) Enable a user to merge and remove individual data elements.
    (iii) Enable a user to review and validate the accuracy of a final 
set of data elements and, upon a user's confirmation, automatically 
update the list.
    (5) Incorporate laboratory tests and values/results.
    (i) Receive results.
    (A) Ambulatory setting only.
    (1) Electronically receive clinical laboratory tests and values/
results in accordance with the standard (and applicable implementation 
specifications) specified in Sec.  170.205(k) and, at a minimum, the 
version of the standard specified in Sec.  170.207(g).
    (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 tests and values/results in human readable 
format.
    (ii) Display test report information. Electronically display all 
the information for a test report specified at 42 CFR 493.1291(c)(1) 
through (7).
    (iii) Incorporate tests and values/results. Electronically 
incorporate a laboratory test and value/result with a laboratory order 
or patient record.
    (6) Inpatient setting only--transmission of electronic laboratory

[[Page 13883]]

tests and values/results to ambulatory providers. Enable a user to 
electronically create laboratory tests and values/results for 
electronic transmission in accordance with:
    (i) The standard (and applicable implementation specifications) 
specified in Sec.  170.205(k); and
    (ii) At a minimum, the version of the standard specified in Sec.  
170.207(g).
    (c) Clinical quality measures.
    (1) Clinical quality measures--capture and export.
    (i) Capture. Electronically record all of the data elements that 
are represented in the standard specified in Sec.  170.204(c).
    (ii) Export. Electronically export a data file that includes all of 
the data elements that are represented in the standard specified in 
Sec.  170.204(c).
    (2) Clinical quality measures--incorporate and calculate.
    (i) Incorporate. Electronically incorporate all of the data 
elements necessary to calculate each of the clinical quality measures 
that are included in the EHR technology.
    (ii) Calculate. Electronically calculate each clinical quality 
measure that is included in the EHR technology.
    (3) Clinical quality measures--reporting. Enable a user to 
electronically create for transmission clinical quality measurement 
results in a data file defined by CMS.
    (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) Enabled by default. The capability specified in paragraph 
(d)(2)(ii) of this section must be enabled by default (i.e., turned on) 
and must only be permitted to be disabled (and re-enabled) by a limited 
set of identified users.
    (ii) Record actions. Record actions related to electronic health 
information, audit log status and, as applicable, encryption of end-
user devices in accordance with the standard specified in Sec.  
170.210(e).
    (iii) Audit log protection. Actions recorded in accordance with 
paragraph (d)(2)(ii) must not be capable of being changed, overwritten, 
or deleted.
    (iv) Detection. Detect the alteration of audit logs.
    (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 elements specified in the standard at Sec.  170.210(e).
    (4) Amendments.
    (i) Enable a user to electronically amend a patient's health record 
to:
    (A) Replace existing information in a way that preserves the 
original information; and
    (B) Append patient supplied information, in free text or scanned, 
directly to a patient's health record or by embedding an electronic 
link to the location of the content of the amendment.
    (ii) Enable a user to electronically append a response to patient 
supplied information in a patient's health record.
    (5) Automatic log-off. Terminate 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) Encryption of data at rest. Paragraph (d)(7)(i) or (ii) of this 
section must be met to satisfy this certification criterion.
    (i) If EHR technology manages electronic health information on an 
end-user device and the electronic health information remains stored on 
the device after use of the EHR technology on that device has stopped, 
the electronic health information must be encrypted in accordance with 
the standard specified in Sec.  170.210(a)(1). This capability must be 
enabled by default (i.e., turned on) and must only be permitted to be 
disabled (and re-enabled) by a limited set of identified users.
    (ii) Electronic health information managed by EHR technology never 
remains stored on end-user devices after use of the EHR technology on 
those devices has stopped.
    (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) Optional--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) Enable a user to provide patients (and their authorized 
representatives) with online access to do all of the following:
    (A) View. Electronically view in accordance with the standard 
adopted at Sec.  170.204(a), at a minimum, the following data elements:
    (1) Patient name; gender; date of birth; race; ethnicity; preferred 
language; smoking status; problem list; medication list; medication 
allergy list; procedures; vital signs; laboratory tests and values/
results; provider's name and contact information; names and contact 
information of any additional care team members beyond the referring or 
transitioning provider and the receiving provider; and care plan, 
including goals and instructions.
    (2) Inpatient setting only. Admission and discharge dates and 
locations; reason(s) for hospitalization; names of providers of care 
during hospitalization; laboratory tests and values/results (available 
at time of discharge); and discharge instructions for patient.
    (B) Download. Electronically download:
    (1) A file in human readable format that includes, at a minimum:
    (i) Ambulatory setting only. All of the data elements specified in 
paragraph (e)(1)(i)(A)(1) of this section.
    (ii) Inpatient setting only. All of the data elements specified in 
paragraphs (e)(1)(i)(A)(1) and (2) of this section.
    (2) A summary care record formatted according to the standards 
adopted at Sec.  170.205(a)(3) and that includes, at a minimum, the 
following data elements expressed, where applicable, according to the 
specified standard(s):
    (i) Patient name; gender; date of birth; medication allergies; 
vital signs; the provider's name and contact information; names and 
contact information of any additional care team members beyond the 
referring or transitioning provider and the receiving provider; care 
plan, including goals and instructions;
    (ii) Race and ethnicity. The standard specified in Sec.  
170.207(f);
    (iii) Preferred language. The standard specified in Sec.  
170.207(j);
    (iv) Smoking status. The standard specified in Sec.  170.207(l);
    (v) Problems. At a minimum, the version of the standard specified 
in Sec.  170.207(a)(3);
    (vi) Encounter diagnoses. The standard specified in Sec.  
170.207(m);
    (vii) Procedures. The standard specified in Sec.  170.207(b)(2) or 
Sec.  170.207(b)(3);
    (viii) Laboratory test(s). At a minimum, the version of the 
standard specified in Sec.  170.207(g);
    (ix) Laboratory value(s)/result(s). The value(s)/results of the 
laboratory test(s) performed;

[[Page 13884]]

    (x) Medications. At a minimum, the version of the standard 
specified in Sec.  170.207(h); and
    (xi) Inpatient setting only. The data elements specified in 
paragraph (e)(1)(i)(A)(2) of this section.
    (3) Images formatted according to the standard adopted at Sec.  
170.205(j).
    (C) Transmit to third party. Electronically transmit the summary 
care record created in paragraph (e)(1)(i)(B)(2) of this section and 
images available to download in paragraph (e)(1)(i)(B)(3) of this 
section in accordance with:
    (1) The standard specified in Sec.  170.202(a)(1); and
    (2) The standard specified in Sec.  170.202(a)(2).
    (ii) Patient accessible 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 electronic health information affected by the action(s);
    (2) The date and time each action occurs in accordance with the 
standard specified at Sec.  170.210(g);
    (3) The action(s) that occurred; and
    (4) User identification.
    (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.314(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 summaries. Enable a user to 
provide clinical summaries to patients for each office visit that 
include, at a minimum, the following data elements: Provider's name and 
office contact information; date and location of visit; reason for 
visit; patient's name; gender; race; ethnicity; date of birth; 
preferred language; smoking status; vital signs and any updates; 
problem list and any updates; medication list and any updates; 
medication allergy list and any updates; immunizations and/or 
medications administered during the visit; procedures performed during 
the visit; laboratory tests and values/results, including any tests and 
value/results pending; clinical instructions; care plan, including 
goals and instructions; recommended patient decision aids (if 
applicable to the visit); future scheduled tests; future appointments; 
and referrals to other providers. If the clinical summary is provided 
electronically, it must be:
    (i) Provided in human readable format; and
    (ii) Provided in a summary care record formatted according to the 
standard adopted at Sec.  170.205(a)(3) with the following data 
elements expressed, where applicable, according to the specified 
standard(s):
    (A) Race and ethnicity. The standard specified in Sec.  170.207(f);
    (B) Preferred language. The standard specified in Sec.  170.207(j);
    (C) Smoking status. The standard specified in Sec.  170.207(l);
    (D) Problems. At a minimum, the version of the standard specified 
in Sec.  170.207(a)(3);
    (E) Encounter diagnoses. The standard specified in Sec.  
170.207(m);
    (F) Procedures. The standard specified in Sec.  170.207(b)(2) or 
Sec.  170.207(b)(3);
    (G) Laboratory test(s). At a minimum, the version of the standard 
specified in Sec.  170.207(g);
    (H) Laboratory value(s)/result(s). The value(s)/results of the 
laboratory test(s) performed; and
    (I) Medications. At a minimum, the version of the standard 
specified in Sec.  170.207(h).
    (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 and EHR technology 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. Enable a user to 
electronically create immunization information for electronic 
transmission in accordance with:
    (i) The standard and applicable implementation specifications 
specified in Sec.  170.205(e)(3); and
    (ii) At a minimum, the version of the standard specified in Sec.  
170.207(i).
    (3) Public health surveillance. Enable a user to electronically 
record, change, and access syndrome-based public health surveillance 
information.
    (4) Transmission to public health agencies. Enable a user 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).
    (B) Optional. The standard (and applicable implementation 
specifications) specified in Sec.  170.205(d)(3).
    (ii) Inpatient setting only. The standard (and applicable 
implementation specifications) specified in Sec.  170.205(d)(3).
    (5) Inpatient setting only--reportable laboratory tests and values/
results. Enable a user to electronically record, change, and access 
reportable clinical laboratory tests and values/results.
    (6) Inpatient setting only--transmission of reportable laboratory 
tests and values/results. Enable a user 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); and
    (ii) At a minimum, the versions of the standards specified in Sec.  
170.207(a)(3) and (g).
    (7) Ambulatory setting only--cancer case information. Enable a user 
to electronically record, change, and access cancer case information.
    (8) Ambulatory setting only--transmission to cancer registries. 
Enable a user 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); and
    (ii) At a minimum, the versions of the standards specified in Sec.  
170.207(a)(3) and (g).
    (g) Utilization.
    (1) Automated numerator recording. For each meaningful use 
objective with a percentage-based measure, electronically record the 
numerator.
    (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) Non-percentage-based measure 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, electronically record the date and time in accordance 
with the standard specified at Sec.  170.210(g) when the capability was 
enabled, disabled, and/or executed.
    (ii) Enable a user to electronically create a report of the 
information

[[Page 13885]]

recorded as part of paragraph (g)(3)(i) of this section.
    (4) Safety-enhanced design. User-centered design processes must be 
applied to each capability an EHR technology includes that is specified 
in the following certification criteria: Sec.  170.314(a)(1); Sec.  
170.314(a)(2); Sec.  170.314(a)(6); Sec.  170.314(a)(7); Sec.  
170.314(a)(8); Sec.  170.314(a)(17); Sec.  170.314(b)(3); and Sec.  
170.314(b)(4).


Sec. Sec.  170.500 through 170.599  [Amended]

    10. In subpart E, consisting of Sec. Sec.  170.500 through 170.599, 
remove the phrases ``permanent certification program for HIT'' and 
``permanent certification program'' and add in their place ``ONC HIT 
Certification Program'' wherever they may occur.
    11. Amend Sec.  170.502 by revising the definition of ``providing 
or provide an updated certification'' to read as follows:


Sec.  170.502  Definitions.

* * * * *
    Providing or provide an updated certification means the action 
taken by an ONC-ACB to ensure that the developer of a previously 
certified EHR Module(s) shall update the information required by Sec.  
170.523(k)(1)(i), after the ONC-ACB has verified that the certification 
criterion or criteria to which the EHR Module(s) was previously 
certified have not been revised and that no new certification criteria 
are applicable to the EHR Module(s).
* * * * *
    12. In Sec.  170.523, republish the introductory text, add 
paragraph (f)(8), and revise paragraph (k)(1)(i) to read as follows:


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

    An ONC-ACB shall:
* * * * *
    (f) * * *
    (8) A hyperlink to the test results used to certify the Complete 
EHRs and/or EHR Modules that can be accessed by the public.
* * * * *
    (k) * * *
    (1) * * *
    (i) ``This [Complete EHR or EHR Module] is [specify Edition of EHR 
certification criteria] compliant and has been certified by an ONC-ACB 
in accordance with the applicable certification criteria adopted by the 
Secretary of Health and Human Services. This certification does not 
represent an endorsement by the U.S. Department of Health and Human 
Services.''; and
* * * * *
    13. In Sec.  170.550, revise paragraph (e), redesignate paragraph 
(f) as paragraph (g), and add a new paragraph (f) to read as follows:


Sec.  170.550  EHR Module certification.

* * * * *
    (e) Privacy and security certification. For certification to the 
2011 Edition EHR certification criteria, EHR Module(s) shall be 
certified to all privacy and security certification criteria adopted by 
the Secretary, unless the EHR Module(s) is presented for certification 
in one of the following manners:
    (1) The EHR Modules are presented for certification as a pre-
coordinated, integrated bundle of EHR Modules, which would otherwise 
meet the definition of and constitute a Complete EHR, and one or more 
of the constituent EHR Modules is demonstrably responsible for 
providing all of the privacy and security capabilities for the entire 
bundle of EHR Modules; or
    (2) An EHR Module is presented for certification, and the presenter 
can demonstrate and provide documentation to the ONC-ACB that a privacy 
and security certification criterion is inapplicable or that it would 
be technically infeasible for the EHR Module to be certified in 
accordance with such certification criterion.
    (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) if the EHR Module has capabilities 
presented for certification that would support a meaningful use 
objective with a percentage-based measure;
    (2) Section 170.314(g)(3) if the EHR Module has capabilities 
presented for certification that would support a meaningful use 
objective with a non-percentage-based measure; and
    (3) Section 170.314(g)(4) if the EHR Module is presented for 
certification to one or more listed certification criteria in Sec.  
170.314(g)(4).
* * * * *
    14. Revise Sec.  170.555 to read as follows:


Sec.  170.555  Certification to newer versions of certain standards.

    (a) ONC-ACBs may certify Complete EHRs and/or EHR Module(s) to a 
newer version of certain identified minimum standards specified at 
subpart B of this part, unless the Secretary prohibits the use of a 
newer version for certification.
    (b) Applicability of a newer version of a minimum standard. (1) 
ONC-ACBs are not required to certify Complete EHRs and/or EHR Module(s) 
according to newer versions of standards identified as minimum 
standards in subpart B of this part, unless and until the incorporation 
by reference of a standard is updated in the Federal Register with a 
newer version.
    (2) A certified Complete EHR or certified EHR Module may be 
upgraded to comply with newer versions of standards identified as 
minimum standards in subpart B of this part without adversely affecting 
its certification status, unless the Secretary prohibits the use of a 
newer version for certification.

    Dated: February 21, 2012.
Kathleen Sebelius,
Secretary.
[FR Doc. 2012-4430 Filed 2-24-12; 4:15 pm]
BILLING CODE 4150-45-P


</pre><script data-cfasync="false" src="/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js"></script></body>
</html>