Federal Register, Volume 77 Issue 45 (Wednesday, March 7, 2012)

[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

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.
Federal eRulemaking Portal: Follow the instructions for
submitting comments. Attachments should be in Microsoft Word, Microsoft
Excel, or Adobe PDF; however, we prefer Microsoft Word. http://www.regulations.gov.
Regular, Express, or Overnight Mail: Department of Health
and Human Services, Office of the National Coordinator for Health
Information Technology, Attention: 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.
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:''
The certification criterion only specifies capabilities
that have never been included in previously adopted certification
criteria; or
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.

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.

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.

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.

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.

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

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

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.

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.

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

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.

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.

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.
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:''
The certification criterion includes changes to
capabilities that were specified in the previously adopted
certification criterion;
The certification criterion has a new mandatory capability
that was not included in the previously adopted certification
criterion; or
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.

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

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.

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.

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

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

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 1 and a medication from
source 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).
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).

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

Data capture--The capability of EHR technology to record
the data that would be required in order to calculate CQMs.
Export--The capability of EHR technology to create a data
file that can be incorporated by another EHR technology to calculate
CQMs.
Calculate--The capability of EHR technology to incorporate
data (from other EHR technology where necessary) and correctly
calculate the result for CQMs.
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.
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.
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.
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.
---------------------------------------------------------------------------

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.
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 1 may be part of an EH's Base
EHR, but the EH may use certified EHR Module 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.

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

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

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

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

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.

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

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.
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:
The certification criterion includes only the same
capabilities that were specified in previously adopted certification
criteria;
The certification criterion's capabilities apply to the
same setting as they did in previously adopted certification criteria;
and
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.

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

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.

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.

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.

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

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 1 necessary to
migrate over to EHR 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 [email protected], 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
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
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
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
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
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
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
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