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, 54163-54292 [2012-20982]

Agencies

• DEPARTMENT OF HEALTH AND HUMAN SERVICES
• Office of the Secretary

[Federal Register Volume 77, Number 171 (Tuesday, September 4, 2012)]
[Rules and Regulations]
[Pages 54163-54292]
From the Federal Register Online via the Government Printing Office [www.gpo.gov]
[FR Doc No: 2012-20982]



[[Page 54163]]

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

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Office of the Secretary

45 CFR Part 170

RIN 0991-AB82


Health Information Technology: Standards, Implementation 
Specifications, and Certification Criteria for Electronic Health Record 
Technology, 2014 Edition; Revisions to the Permanent Certification 
Program for Health Information Technology

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

ACTION: Final rule.

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

SUMMARY: With this final rule, the Secretary of Health and Human 
Services adopts certification criteria that establish the technical 
capabilities and specify the related standards and implementation 
specifications that Certified Electronic Health Record (EHR) Technology 
will 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 final rule also makes changes to the permanent 
certification program for health information technology, including 
changing the program's name to the ONC HIT Certification Program.

DATES: These regulations are effective October 4, 2012. The 
incorporation by reference of certain publications listed in the rule 
is approved by the Director of the Federal Register as of October 4, 
2012.

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: This final rule is issued under section 3004 
of the Public Health Service Act.

Commonly Used Acronyms

CAH Critical Access Hospital
CDA Clinical Document Architecture
CDC Centers for Disease Control and Prevention
CDS Clinical Decision Support
CEHRT Certified EHR Technology
CFR Code of Federal Regulations
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 International Classification of Diseases, 10th Revision
ICD-10-CM International Classification of Diseases, 10th Revision, 
Clinical Modification
ICD-10-PCS International Classification of Diseases, 10th Revision, 
Procedure Coding System
IHE Integrating the Healthcare Enterprise[supreg]
LOINC[supreg] 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. Standards, Implementation Specifications, and Certification 
Criteria Rules
    2. Medicare and Medicaid EHR Incentive Programs Rules
    3. HIT Certification Programs Rules
III. Provisions of the Final Rule Affecting Standards, 
Implementation Specifications and Certification Criteria
    A. 2014 Edition EHR Certification Criteria
    1. Certification Criteria Relationship to MU
    2. Applicability
    3. Scope of a Certification Criterion for Certification
    4. Explanation and Revision of Terms Used in Certification 
Criteria
    5. Consensus-Based Standards
    6. Adopting Versions of Standards
    7. Display of Vocabulary Standards
    8. Common Data Elements in Certification Criteria
    9. New Certification Criteria
    a. Ambulatory and Inpatient Setting
    b. Ambulatory Setting
    c. Inpatient Setting
    10. Revised Certification Criteria
    a. Ambulatory and Inpatient Setting
    b. Ambulatory Setting
    c. Inpatient Setting
    11. Unchanged Certification Criteria
    a. Refinements to Unchanged Certification Criteria
    b. Unchanged Certification Criteria Without Refinements
    12. Gap Certification
    13. ``Disability'' Status
    B. Redefining Certified EHR Technology and Related Terms
    1. Certified EHR Technology (CEHRT) Definition
    2. Base EHR Definition
    3. Complete EHR Definition
    4. Certifications Issued for Complete EHRs and EHR Modules
    5. Adaptations of Certified Complete EHRs or Certified EHR 
Modules
IV. Provisions of the Final 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. Representation of Meeting the Base EHR Definition
    F. EHR Technology Price Transparency
    G. Certification and Certification Criteria for Other Health 
Care Settings
V. Collection of Information Requirements
VI. Regulatory Impact Statement
    A. Statement of Need
    B. Overall Impact
    1. Comment and Response
    2. 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 Estimated Costs Over a 
3-Year Period
    iii. Costs for Reporting Test Results Hyperlinks
    b. Benefits
    3. Regulatory Flexibility Act Analysis
    4. Executive Order 13132--Federalism
    5. 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

[[Page 54164]]

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. On March 7, 2012, the Secretary published a proposed 
rule (77 FR 13832) with 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 proposed rule solicited public comment on the standards, 
implementation specifications, and certification criteria the Secretary 
proposed for adoption.
    This final rule addresses comments received on the proposed rule 
and specifies 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 that will 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'').
    Consistent with Executive Order 13563, we have undertaken a 
retrospective review of our regulations. The final rule establishes 
multiple means for reducing regulatory burden and increasing regulatory 
flexibility for stakeholders, including changes to current regulatory 
requirements and approaches.

B. Summary of Major Provisions

1. Overview of the 2014 Edition EHR Certification Criteria
    We have adopted certification criteria that will support the 
changes to the EHR Incentive Programs, including the new and revised 
objectives and measures for Stages 1 and 2 of MU finalized by CMS. The 
adopted certification criteria also enhance care coordination, patient 
engagement, and the security, safety, and efficacy of EHR technology. 
We refer to the adopted certification criteria as the 2014 Edition EHR 
certification criteria and the certification criteria previously 
adopted through rulemaking (75 FR 2014, 75 FR 44590) as the 2011 
Edition EHR certification criteria. To permit efficient certification 
methods and reduce regulatory burden, we have identified those 
certification criteria that we have adopted as part of 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 will 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.12 of this preamble).
2. Certified EHR Technology
    Since the publication of the Standards and Certification Criteria 
final rule in July 2010, 75 FR 44590 (July 28, 2010) (the ``S&CC July 
2010 final rule''), HHS received significant feedback from stakeholders 
which suggested 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, we proposed to 
revise the CEHRT definition to offer the requested flexibility. Based 
on comments received, we have finalized a CEHRT definition that 
provides even more flexibility for EPs, EHs, and CAHs than we 
originally proposed. In order to have EHR technology that meets the 
CEHRT definition for FY and CY 2014 and subsequent years, EPs, EHs, and 
CAHs must have EHR technology certified to the 2014 Edition EHR 
certification criteria that meets the Base EHR definition (EHR 
technology that includes fundamental capabilities all providers would 
need to have) as well as the additional EHR technology certified to the 
2014 Edition EHR certification criteria necessary to meet the MU 
objectives and measures for the stage of MU that they seek to meet and 
to capture, calculate, and electronically submit clinical quality 
measures. In addition, this final rule permits EPs, EHs, and CAHs to 
adopt EHR technology that meets the FY/CY 2014 CEHRT definition and use 
it in their attempts to achieve MU prior to FY/CY 2014. We further 
discuss the new dynamic CEHRT definition, including the Base EHR 
definition in section III.B (``Redefining Certified EHR Technology and 
Related Terms'').
    We note that we continue to permit only two types of EHR 
technology, Complete EHRs and EHR Modules, to be certified to meet 
these definitions under the ``ONC HIT Certification Program.'' A 
Complete EHR requires EHR technology to meet, at a minimum, all the 
mandatory certification criteria for either the ambulatory or inpatient 
setting, while an EHR Module can be any EHR technology certified to one 
less than all the mandatory certification criteria for either the 
ambulatory or inpatient setting (as noted, it would be a Complete EHR 
if it was certified to all the mandatory certification criteria for a 
setting). A Complete EHR, by definition, would meet the Base EHR 
definition and could be used to meet the CEHRT definition, but we note 
that an EP may need EHR technology certified to the optional ``cancer 
registries'' certification criteria to support their attempt to achieve 
MU. A single EHR Module could also be developed to meet the Base EHR 
definition and CEHRT definition for an EP, EH, or CAH. Additionally, an 
EP, EH, or CAH could use multiple certified EHR Modules or a certified 
EHR Module(s) in conjunction with a certified Complete EHR to meet the 
Base EHR definition and CEHRT definition.
3. ONC HIT Certification Program
    This final rule revises the permanent certification program in ways 
that 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 final rule also 
revises the process for permitting the use of newer versions of 
``minimum standard'' code sets. The new approach is expected to reduce 
regulatory complexity and burden by providing the industry with the 
flexibility to utilize newer versions of adopted ``minimum standard'' 
code sets in a timelier manner.
    The final rule modifies the certification processes ONC-Authorized 
Certification Bodies (ONC-ACBs) will need to follow for certifying EHR 
Modules in a manner that provides clear implementation direction and 
compliance with the new certification criteria. It also reduces 
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

[[Page 54165]]

included in the Base EHR definition that every EP, EH, and CAH must 
meet as part of meeting the CEHRT definition.
    To increase clarity for purchasers in the HIT market, we have 
established methods for representing certified Complete EHRs and 
certified EHR Modules, including when Complete EHRs and EHR Modules 
meet the Base EHR definition. We also require that test results used 
for EHR technology certification be made publicly available in an 
effort to increase transparency and provide EPs, EHs, and CAHs a 
potential starting point from which to assess any implementation issues 
associated with certified Complete EHRs and certified EHR Modules. 
Finally, as another means of increasing transparency and mitigating any 
potential confusion in the market, we require that ONC-ACBs ensure that 
EHR technology developers include in their marketing materials and 
communications notification to potential purchasers any additional 
types of costs that an EP, EH, or CAH would pay to implement their 
certified Complete EHR or certified EHR Module in order to attempt to 
meet MU objectives and measures.

C. Costs and Benefits

    We determined that this final rule is not an economically 
significant rule as its overall costs will be less than $100 million in 
any one year. We have, however, estimated the costs and benefits of the 
final rule. The final rule does not account for the estimated costs 
that EPs, EHs, and CAHs will incur in adopting and implementing 
certified Complete EHRs and certified EHR Modules. Those costs are 
estimated in the CMS Medicare and Medicaid EHR Incentive Programs Stage 
2 final rule (Stage 2 final rule) published elsewhere in this issue of 
the Federal Register. 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 2014 Edition EHR 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 
revised CEHRT definition for FY/CY 2014, particularly with the option 
provided by this final rule for EPs, EHs, and CAHs to adopt EHR 
technology that meets the FY/CY 2014 CEHRT definition and use it in 
their attempts to achieve MU in FY/CY 2013. Due to these market 
pressures, we believe that most of the estimated costs for developing 
EHR technology to meet the 2014 Edition EHR certification criteria will 
be incurred during the remainder of 2012 and throughout 2013, rather 
than in 2014. As a result, as represented in Table 1, the estimated 
costs attributable to this final rule are distributed as follows: 45% 
for 2012, 45% for 2013, and 10% for 2014. The dollar amounts expressed 
in Table 1 are expressed in 2012 dollars.
    There are multiple potential benefits that stem from the 2014 
Edition EHR certification criteria. Foremost, the 2014 Edition EHR 
certification criteria 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. EHR technology certified to the 2014 Edition 
EHR certification criteria also will be capable of supporting EPs, EHs, 
and CAHs' attempts to demonstrate MU under the EHR Incentive Programs. 
The revised CEHRT definition, the availability of gap certification, 
and the revisions to the ONC HIT Certification Program, will, as noted, 
increase regulatory clarity, improve transparency, and add flexibility, 
while also reducing the regulatory burden on the HIT industry. Last, 
the provisions of this final rule are supportive of other initiatives, 
such as the Partnership for Patients, Medicare Shared Savings Program, 
and other quality measure programs administered by CMS.

Table 1--Estimated Costs of the Final Rule: Distributed Total Development and Preparation Costs for Complete EHR
                            and EHR Module Developers (3-year period)--Totals Rounded
----------------------------------------------------------------------------------------------------------------
                                                                                                   Primary mid-
                                                        Ratio     Total low cost    Total high      point total
                        Year                          (percent)    estimate ($M)   cost estimate   cost estimate
                                                                                       ($M)            ($M)
----------------------------------------------------------------------------------------------------------------
2012...............................................           45           45.85          130.02           87.93
2013...............................................           45           45.85          130.02           87.93
2014...............................................           10           10.20           28.90           19.56
                                                    ------------------------------------------------------------
    3-Year Totals..................................  ...........          101.90          288.94          195.42
----------------------------------------------------------------------------------------------------------------

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.
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. The HITPC also considers 
and provides recommendations to ONC and CMS on meaningful use (MU) 
policy under the EHR Incentive Programs. 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

[[Page 54166]]

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. Standards, Implementation Specifications, and Certification Criteria 
Rules
    The Secretary issued an interim final rule with request for 
comments titled ``Health Information Technology: Initial Set of 
Standards, Implementation Specifications, and Certification Criteria 
for Electronic Health Record Technology'' (75 FR 2014, Jan. 13, 2010) 
(the ``S&CC January 2010 interim final rule''), which adopted an 
initial set of standards, implementation specifications, and 
certification criteria. After consideration of the public comments 
received on the S&CC January 2010 interim final rule, a final rule was 
issued to complete the adoption of the initial set of standards, 
implementation specifications, and certification criteria and realign 
them with the final objectives and measures established for 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). 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 ``Stage 1 final rule'') (see 75 FR 44314 for more information 
about MU and the Stage 1 requirements).
    On March 7, 2012, ONC published a proposed rule (``the Proposed 
Rule'') (77 FR 13832) in the Federal Register that proposed new and 
revised certification criteria that would support the achievement of MU 
beginning with the EHR reporting periods in FY/CY 2014. These 
certification criteria are referred to as the 2014 Edition EHR 
certification criteria. The rule also proposed revisions to the CEHRT 
definition.
2. Medicare and Medicaid EHR Incentive Programs Rules
    On January 13, 2010, CMS published the EHR Incentive Programs Stage 
1 proposed rule (75 FR 1844). The rule proposed 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 Stage 1 final rule 
established the objectives, associated measures, and other requirements 
that EPs, EHs, and CAHs must satisfy to demonstrate MU during Stage 1.
    On March 7, 2012, CMS published a proposed rule (77 FR 13698) in 
the Federal Register for MU Stage 2 that included proposed revisions to 
MU Stage 1 beginning with the EHR reporting periods in FY/CY 2013 
(Stage 2 proposed rule).
3. HIT Certification Programs Rules
    On March 10, 2010, ONC published a proposed rule (75 FR 11328) 
titled ``Proposed Establishment of Certification Programs for Health 
Information Technology'' (the ``Certification Programs proposed 
rule''). The rule proposed both a temporary and permanent certification 
program for the purposes of testing and certifying HIT. It also 
specified the processes the National Coordinator would follow to 
authorize organizations to perform the certification of HIT. A final 
rule establishing the temporary certification program was published on 
June 24, 2010 (75 FR 36158) (the ``Temporary Certification Program 
final rule'') and a final rule establishing the permanent certification 
program was published on January 7, 2011 (76 FR 1262) (``the Permanent 
Certification Program final rule'').
    In the Proposed Rule mentioned above, ONC also proposed revisions 
to the permanent certification program, including changing the 
program's name to the ONC HIT Certification Program.

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

    To make a clear distinction between previously adopted 
certification criteria and the ones proposed for adoption in the 
Proposed Rule, we stated we would refer to and define 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

[[Page 54167]]

``2011 Edition EHR certification criteria.'' We proposed to revise 
Sec.  170.102 to add this definition.
    Comments. Commenters expressed support for ``editions'' of 
certification criteria, particularly the use of ``2011 Edition EHR 
certification criteria'' for collectively referencing Sec. Sec.  
170.302, 170.304, and 170.306.
    Response. We appreciate the expression of support and have revised 
Sec.  170.102 to include the definition of 2011 Edition EHR 
certification criteria as proposed.

A. 2014 Edition EHR Certification Criteria

    In the Proposed Rule, we proposed 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 
referred to these new, revised, and unchanged certification criteria as 
the ``2014 Edition EHR certification criteria'' and proposed to add 
this term and its definition to Sec.  170.102. Additionally, we 
proposed to include all of the 2014 Edition EHR certification criteria 
in Sec.  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.
    Comments. Commenters expressed support for ``editions'' of 
certification criteria, particularly the use of ``2014 Edition EHR 
certification criteria'' to reference the certification criteria 
adopted in Sec.  170.314. One commenter, however, did not agree with 
our approach to include all of the 2014 Edition EHR certification 
criteria in Sec.  170.314. The commenter suggested that we should 
maintain the approach used for the 2011 Edition EHR certification 
criteria (i.e., to separate general, ambulatory, and inpatient 
certification criteria into three sections of the Code of Federal 
Regulations (CFR)).
    Response. We appreciate the expression of support for our 
``editions'' approach and have revised Sec.  170.102 to include the 
definition of 2014 Edition EHR certification criteria as proposed. Use 
of ``2014 Edition EHR certification criteria'' coupled with our use of 
``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 in the 2014 Edition EHR certification criteria.
    We believe by including all the 2014 Edition EHR certification 
criteria in one section of the CFR is a better approach than our 
previous approach of separating general, ambulatory, and inpatient 
certification criteria into three sections of the CFR. As noted in the 
Proposed Rule, the inclusion of all 2014 Edition EHR certification 
criteria in one regulatory section will simplify the regulatory 
framework for stakeholders.
1. Certification Criteria Relationship to MU
    Many of the certification criteria that we proposed supported the 
MU objectives and measures proposed by CMS in the Stage 2 proposed rule 
as well as the reporting of MU objectives and measures and clinical 
quality measures (CQMs). To the extent CMS has changed (e.g., added, 
revised, or removed) the MU objectives, measures, or reporting 
requirements in its final rule, we have made appropriate changes to the 
associated certification criteria so that they continue to support the 
MU objectives, measures, and reporting requirements.
    We received many comments on the 2014 Edition EHR certification 
criteria that were not within this rulemaking's scope. These comments 
focused on the MU objectives, measures, CQM measures, and reporting 
requirements. For responses to such comments, we direct readers to the 
Stage 2 final rule published elsewhere in this issue of the Federal 
Register.
    We reiterate and emphasize for commenters to remember that 
certification is a floor not a ceiling. It does not specify an 
exhaustive set of capabilities that EHR technology must include. 
Rather, certification assesses a subset of capabilities (generally 
capabilities that support MU requirements) that may be part of the 
overall EHR technology that an EP, EH, or CAH adopts. In this regard, 
certification focuses on providing assurance to EPs, EHs, and CAHs that 
EHR technology certified to a certification criterion includes the 
specified capabilities, that those capabilities perform correctly and, 
where applicable, that those capabilities properly utilize/support 
adopted standards.
    We discuss the new, revised, and unchanged certification criteria 
that we are adopting as the 2014 Edition EHR certification criteria in 
sections A.8 through A.10 below. We include a table at the beginning of 
the discussion of each certification criterion or criteria that 
specifies the MU objective that the 2014 Edition EHR certification 
criterion or criteria support. The objective cited is either a Stage 1 
or Stage 2 objective that will be effective for the EHR reporting 
periods in FY/CY 2014. We provide this frame of reference because 
beginning in FY/CY 2014 EHR technology will need to be certified to the 
2014 Edition EHR certification criteria to meet the CEHRT definition 
and the tables clearly associate the certification criterion or 
criteria with the MU objective it supports. The tables also specify the 
CFR location for each certification criterion adopted in Sec.  170.314.
2. 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 proposed to revise Sec.  170.300 to reflect our proposed 
regulatory structure for the 2014 Edition EHR certification criteria. 
We proposed 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 proposed 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.
    Comments. Comments asked for clarification on how the optionality 
provided for capabilities within certification criteria would be 
clearly identified to purchasers of certified EHR technology.
    Response. We expect that the certifications issued to EHR 
technology will clearly indicate whether the EHR technology was 
certified to any optional capability within a certification criterion 
or, for that matter, any optional certification criterion. The 
Certified HIT Product List (CHPL) will also indicate

[[Page 54168]]

whether a certified Complete EHR or certified EHR Module was certified 
to an optional certification criterion or an optional specific 
capability within a certification criterion.
3. Scope of a Certification Criterion for Certification
    In the Proposed Rule, based on our proposal to codify all the 2014 
Edition EHR certification criteria in Sec.  170.314, we clarified that 
certification to the certification criteria at Sec.  170.314 would 
occur at the second paragraph level of the regulatory section. We noted 
that the first paragraph level in Sec.  170.314 organizes the 
certification criteria into categories. These categories include: 
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, we 
stated that a certification criterion in Sec.  170.314 is 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).
    Comments. We received no comments on this clarification.
    Response. Having adopted the 2014 Edition EHR certification 
criteria in Sec.  170.314 as we proposed, our clarification remains 
accurate. Additionally, we offer further clarity with an illustration 
of this principle using the ``demographics'' certification criterion 
adopted 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. Consequently, to meet the demographics certification 
criterion, 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.
4. Explanation and Revision of Terms Used in Certification Criteria
    In the Proposed Rule, we noted that certain terms are repeatedly 
used in the proposed 2014 Edition EHR certification criteria. We stated 
that, based on our experience and stakeholder feedback related to how 
terms in the 2011 Edition EHR certification criteria have been 
interpreted, it was necessary in certain cases to select different 
terms. Therefore, we provided the following list of terms that are 
repeatedly used in the 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 
clarified 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 proposed to replace 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.\1\ In certification 
criteria in which this term is used, we stated that 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.
---------------------------------------------------------------------------

    \1\ https://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 proposed 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 
noted 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 stated that 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 
proposed 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 proposed to replace the term ``generate'' used in the 
2011 Edition EHR certification criteria with ``create.'' We stated that 
``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.
    Comments. Commenters expressed general support for our proposed 
replacement of terms in certification criteria with the proposed terms 
described above. A few commenters, however, expressed confusion about 
our description of ``incorporate'' as we described it and used it in 
different certification criteria such as the proposed ``transitions of 
care-incorporate summary care record'' certification criterion (Sec.  
170.314(b)(1)) and the ``incorporate laboratory tests and values/
results'' certification criterion (Sec.  170.314(b)(5)).
    Response. We appreciate the support for the proposed term 
replacements and are replacing the terms as proposed, except for the 
term ``incorporate.'' We agree with commenters that our description of 
incorporate could create confusion based on the context in which we 
proposed to use it in different certification criteria. In 
consideration of comments received, we have revised our description of 
incorporation to reflect the common interpretation commenters stated 
they assigned to the term. Thus,

[[Page 54169]]

when the term incorporate is used within a certification criterion it 
is intended to mean to electronically process structured information 
from another source such that it is combined (in structured form) with 
information maintained by EHR technology and is subsequently available 
for use within the EHR technology by a user. As part of the 2014 
Edition EHR certification criteria, the ``transitions of care'' and 
``incorporate laboratory tests and values/results'' certification 
criteria at Sec.  170.314(b)(2) and (b)(5), respectively, reference 
this term in the context of a specific capability that would require 
EHR technology to be able to incorporate information.
    Comments. Commenters expressed confusion about how to interpret our 
use of the phrase ``included in one or any combination of the 
following'' in certification criteria.
    Response. To eliminate any potential confusion, we have revised the 
certification criteria containing this phrase to read ``each one and at 
least one combination of the following data.'' We use this phrase to 
mean that the capability for which certification is required must be 
able to individually address each of the data specified in the 
certification criterion and at least one combination of those data. 
``One combination'' means a combination of two or more of the data 
listed in the certification criterion. For example, in the clinical 
decision support (CDS) certification criterion six categories of data 
are listed in paragraphs Sec.  170.314 (a)(8)(i)(A) through (F). The 
certification criterion states ``enable a limited set of identified 
users to select (i.e., activate) one or more electronic clinical 
decision support interventions [hellip] based on each one and at least 
one combination of the following data.'' Thus, to meet this 
certification criterion EHR technology must be able to enable the 
selection of CDS interventions that would be separately applicable to 
the data listed in (A) through (F) and at least one combination of the 
data listed in (A) through (F), such as (A) and (D) (problems and 
demographics).
    To provide further clarity for the 2014 Edition EHR certification 
criteria, we have revised a number of certification criteria to now 
begin with ``EHR technology must be able to * * *'' rather than 
``Enable a user to * * *.'' We believe this approach more clearly 
communicates that the EHR technology must demonstrate the capability to 
be certified to the certification criterion. As one last point of 
clarification, we replaced ``data element'' references in certification 
criteria, where appropriate, with simply ``data.'' We believe this 
clarifies when we intend to mean data that includes types and elements. 
We also believe this will prevent confusion when the reference point is 
solely a ``data element.''
    Comments. Commenters asked how terms used in MU objectives and 
measures are defined for the purposes of the 2014 Edition EHR 
certification criteria, such as ``electronic notes,'' ``images,'' 
``care plan,'' and ``care team.''
    Response. We incorporate in our certification criteria the terms 
used in MU objectives and measures as they are defined or described in 
the Stage 2 final rule.
5. Consensus-Based Standards
    Comments. Commenters stated that for interoperability to be 
successful, it was essential that standards be created through 
collaborative, consensus-based processes that take into consideration 
the needs and concerns of all interested stakeholders. Response. 
Federal agencies are required under the National Technology Transfer 
and Advancement Act of 1995 (NTTAA) (15 U.S.C. Sec.  3701 et seq.) and 
OMB Circular A-119 \2\ to use, wherever practical, technical standards 
that are developed or adopted by voluntary consensus standards bodies 
to carry out policy objectives or activities, with certain exceptions. 
Both the NTTAA and OMB Circular A-119 provide for certain exceptions to 
selecting only standards developed or adopted by voluntary consensus 
standards bodies, namely when doing so would be inconsistent with 
applicable law or otherwise impractical. In this final rule, we have 
adopted or refer to voluntary consensus standards, except for the 
following government-unique standards: the Office of Management and 
Budget Standards for Maintaining, Collecting, and Presenting Federal 
Data on Race and Ethnicity; the three transport standards adopted in 
Sec.  170.202; the standard that identifies the data elements 
referenced by clinical quality measures (adopted at Sec.  170.204(c)); 
and certain standards related to the protection of electronic health 
information adopted in Sec.  170.210. We are aware of no voluntary 
consensus standards that would serve as alternatives to these standards 
for the purposes that we have identified.
---------------------------------------------------------------------------

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

    Comments. A commenter suggested that we incorporate the HL7 EHR 
System Functional Model (ISO/HL7 10781 standard) into certification. 
The commenter noted that is a long-standing international consensus 
standard for EHR System functionality and that Release 2 of this 
standard is currently in ballot by the International Standards 
Organization Technical Committee 215 on Health Informatics (ISO TC215), 
the Committee for European Normalization Technical Committee 251 (CEN 
TC251), the International Health Terminology Standards Development 
Organisation (IHTSDO), the Clinical Data Interchange Standards 
Consortium (CDISC) and Health Level Seven (HL7). The commenter 
suggested that ``linking'' the function and conformance criteria of the 
internationally-recognized ISO/HL7 10781 standard to the 2014 Edition 
EHR certification criteria for the purposes of certification would make 
EHR technology certified under the ONC HIT Certification Program more 
competitive in international markets.
    Response. It is our understanding that the HL7 EHR System 
Functional Model provides a comprehensive set of EHR system functional 
requirements that in many cases goes beyond the scope of the 
capabilities required by the 2014 Edition EHR certification criteria. 
As such, this comment is outside the scope of this current rulemaking. 
However, we strongly support methods that could be used to increase 
international interoperability and acceptance of EHR technology 
certified under the ONC HIT Certification Program. Accordingly, we 
intend to explore and request that the HITPC and HITSC consider the 
applicability and usefulness of the HL7 EHR System Functional Model as 
a basis for future recommendations on certification criteria.
6. Adopting Versions of Standards
    Comments. We received comments recommending that we adopt standards 
at a higher level of abstraction and that we should not be overly 
prescriptive about the exact version and release of vocabulary and 
messaging protocols. That is, that we should not adopt a particular 
version of a content exchange standard for which certification would be 
required, (e.g., HL7 2.x, where ``x'' could be any version within the 
version 2 family) and accompany the adopted standards with detailed 
implementation specifications or guidance outside of rulemaking.
    Response. While the commenters' recommendation may provide added 
flexibility, we are unable to accept the recommendation for multiple 
reasons. First, it has the potential to create interoperability 
challenges. Second, there are processes under the Administrative 
Procedure Act that must be followed for the adoption of substantive 
requirements. Third, in accordance with Office of the Federal Register 
regulations related to ``incorporation by reference,'' 1 CFR

[[Page 54170]]

part 51, which we follow for this final rule, the publications we 
reference are ``limited to the edition of the publication that is 
approved'' and do not include ``[f]uture amendments or revisions of the 
publication.'' Consequently, we do not include regulatory language that 
refers, for instance, to ``Version 1.X'' when ``X'' remains a variable.
    We note, however, that we have taken two steps for certain 
vocabulary standards designated as minimum standards code sets. First, 
in this final rule we have adopted updated versions of four vocabulary 
standards that we proposed for certification in the Proposed Rule. We 
proposed the use of the January 2012 International Release of SNOMED 
CT[supreg], but have adopted the July 2012 International Release of 
SNOMED CT[supreg] as well as the March 2012 U.S. Extension to SNOMED 
CT[supreg]. We proposed the use of version 2.38 of LOINC[supreg], but 
have adopted version 2.40. We proposed the use of the February 2012 
monthly version of RxNorm, but have adopted the August 2012 monthly 
version of RxNorm. We proposed the use of the August 15, 2011 version 
of CVX code sets, but have adopted the updated through July 11, 2012 
version. In all these instances, we have found that the newer versions 
improve interoperability and EHR technology implementation, support MU, 
and do not create additional substantive requirements in comparison to 
the proposed versions of these vocabulary standards. Further, the 
adoption of these versions establishes the baseline in the CFR with the 
most recent versions of these vocabulary standards that is possible. 
Second, we have also established an approach that permits the use of 
newer versions of these standards than the one adopted in the CFR. We 
refer readers to section IV.B for a discussion of ``minimum standards'' 
code sets and our new more flexible approach for their use in 
certification and upgrading certified Complete EHRs and certified EHR 
Modules. Readers should also review Sec.  170.555, which specifies the 
certification processes for ``minimum standards'' code sets.
7. Display of Vocabulary Standards
    Comments. Several commenters asked a similarly themed question with 
respect to the vocabulary standards we proposed to adopt. The question 
centered on whether EHR technology was required to display a particular 
vocabulary to a user (for the certification criteria that require 
recording certain patient information in a vocabulary standard) in 
order to be certified. Commenters explained that for the problem list 
certification criterion that SNOMED CT[supreg] codes should not be 
required for display in EHR technology and that an organization should 
be able to use whichever code set they prefer to display. Others 
provided similar rationale and said that health care providers are 
typically unfamiliar with SNOMED CT[supreg]. Commenters raised similar 
questions regarding the display of race and ethnicity as well as 
smoking status.
    Response. We agree with commenters and want to make clear that EHR 
technology does not have to display an adopted vocabulary to a user to 
be certified to the certification criterion that includes the 
vocabulary standard. For a more detailed discussion and example of our 
intent please review our responses to the problem list certification 
criterion.
8. Common Data in Certification Criteria
    Comments. Several commenters pointed out that we repeat much of the 
same data in the ``view, download, and transmit to a 3rd party,'' 
``clinical summaries,'' and both ``transitions of care'' certification 
criteria. These commenters suggested that we specify a single 
definition that included this common data and then reference that 
definition in the applicable certification criteria. They added that 
this would cut down on the repetitiveness of the certification 
criteria, make the certification criteria smaller and, thus, easier to 
read, and that this approach would be more efficient overall. 
Commenters recommended that we define a ``Summary Care Record.''
    Response. We agree with commenters' suggestions. Further, we note 
that the data we reference in these certification criteria mirror those 
specified by CMS for the objectives and measures to which these 
certification criteria correlate. Because there is a common set of MU 
data types/elements for which certification would be required across 
several certification criteria, we have created the term ``Common MU 
Data Set.'' We define this term by only the data that is common to 
(i.e., included in all five certification criteria) the ``view, 
download, and transmit to a 3rd party,'' ``clinical summary,'' 
``transitions of care--receive, display, and incorporate transition of 
care/referral summaries,'' ``transitions of care--create and transmit 
transition of care/referral summaries,'' and ``data portability'' 
certification criteria (see Table 2 below). We decline to create a 
specific definition for ``summary care record'' because the Common MU 
Data Set definition serves multiple certification criteria that 
reference different ``summary'' oriented documents. For instance, data 
referenced in the ``clinical summary'' shares the data in the Common MU 
Data Set with the ``transitions of care'' certification criteria, but 
also includes unique data that is specific to a clinical summary. The 
following data are included in the Common MU Data Set definition and 
where applicable reference the standard that would have otherwise been 
assigned if the data were individually included within the 
certification criteria.

                       Table 2--Common MU Data Set
------------------------------------------------------------------------
 
------------------------------------------------------------------------
1. Patient name                       2. Sex.
3. Date of birth                      4. Race.
5. Ethnicity                          6. Preferred language.
7. Smoking status                     8. Problems.
9. Medications                        10. Medication allergies.
11. Laboratory test(s)                12. Laboratory value(s)/result(s).
13. Vital signs (height, weight, BP,  14. Care plan field(s), including
 BMI)                                  goals and instructions.
15. Procedures                        16. Care team members.
------------------------------------------------------------------------

    We also believe that further clarity for stakeholders can be 
provided through the use of more specific descriptions for the 
different types of ``data summaries'' referenced in certification 
criteria. These specific descriptions are listed below and are used in 
the applicable certification criteria and referenced in the preamble 
discussions of the certification criteria. This revision is intended to 
make the data referenced in the final rule and the ``data summary'' to 
which it is assigned more readily apparent to readers. We note that the 
use of these specific descriptions in the certification criteria are 
for regulatory clarity purposes only and do not imply any additional 
meaning.

----------------------------------------------------------------------------------------------------------------
           Certification criterion                                      Type of summary
----------------------------------------------------------------------------------------------------------------
Data portability Sec.   170.314(b)(7)........  Export Summary.
Transitions of care--receive, display, and     Transition of care/referral summary.
 incorporate transition of care/referral
 summaries Sec.   170.314(b)(1).
Transitions of care--create and transmit
 transition of care/referral summaries Sec.
 170.314(b)(2).

[[Page 54171]]

 
View, download, and transmit to a 3rd party    Ambulatory Summary.
 Sec.   170.314(e)(1).                         Inpatient Summary.
Clinical Summary Sec.   170.314(e)(2)........  Clinical Summary.
----------------------------------------------------------------------------------------------------------------

9. New Certification Criteria
    In the Proposed Rule, we described certification criteria that we 
considered ``new.'' We noted the following 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.
    Comments. We did not receive comments questioning our description 
of new certification criteria.
    Response. We therefore continue to use this description of new 
certification criteria to categorize the following certification 
criteria we have adopted as part of the 2014 Edition EHR certification 
criteria. The adopted new certification criteria include those 
certification criteria that we explicitly proposed in the Proposed Rule 
and two additional certification criteria stemming from proposals 
related to quality management principles for EHR technology development 
and data portability for which we solicited comments. We have not 
adopted the proposed ``non-percentage-based measure use report'' 
certification criterion.
a. Ambulatory and Inpatient Setting
    We have adopted 9 new certification criteria that will be 
applicable to both the ambulatory and inpatient settings. We also 
discuss the proposed ``non-percentage-based measure use report'' 
certification criterion but, as noted above, we have not adopted it as 
part of the 2014 Edition EHR certification criteria.
     Electronic Notes

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

    We proposed a certification criterion that was similar to the one 
recommended by the HITSC to support the MU objective and measure 
recommended by the HITPC. CMS did not specifically propose the HITPC 
recommended MU objective and measure for Stage 2, but requested public 
comment on whether the objective and measure should be incorporated 
into MU Stage 2.
    We proposed to replace the terms ``modify'' and ``retrieve'' in the 
recommended criterion with ``change'' and ``access,'' respectively. We 
proposed that ``search'' in the certification criterion was intended to 
mean the ability to search free text and data fields of electronic 
notes. We further proposed that the ability to search would mean the 
ability to search the notes that any licensed health care professional 
has included within the EHR technology and the ability to search for 
information across separate notes rather than just within notes.
    Comments. Many commenters stated that we should not adopt an 
electronic notes certification criterion without CMS establishing a 
corresponding MU objective and measure. Commenters requested that we 
define a note for qualifying in the numerator and clarify who could 
create, edit, and sign a note. Commenters suggested permitting a range 
of options for capturing notes, such as templates and free text. A few 
commenters suggested that electronic notes should be recorded in 
structured data. These commenters thought this would help avoid 
illegible scanned notes or make searching more efficient and useful 
(e.g., searching be defined attributes such as physician name). One 
commenter suggested structured data fields that include: symptomatic 
(subjective); objective; assessment; and plan. The same commenter 
suggested specific note structure for patient problem lists.
    Commenters expressed general support for the search functionality. 
They stated that the ability to search notes for relevant keywords will 
reduce time spent reviewing documentation that is irrelevant to the 
patient's current medical condition(s). Commenters, however, asked for 
further clarification on the extent of the search capability EHR 
technology needed to have in order to meet this certification 
criterion. Commenters expressed concern that this certification 
criterion would require a capability to search across notes, especially 
across providers and patients' charts. Multiple commenters suggested 
that a reasonable requirement for certification would be to require the 
capability to search for a free-text string within a particular open 
note, while other search capabilities should be left as competitive 
differentiators within the marketplace. These commenters noted that 
more specific certification requirements could interrupt innovative 
ways to do effective chart search and information display. Conversely, 
other commenters suggested requiring additional search functionality, 
such as searching across notes based on date ranges or indexing of 
notes in much the same way today's common search engines create 
background indexes allowing for almost instant retrieval of documents 
(e.g., Google, Spotlight on the Mac or ``locate'' on Unix-based 
machines).
    Commenters stated that some providers will find it particularly 
challenging and burdensome to directly document their notes into EHRs. 
For example, some EPs would need to have their notes dictated or 
transcribed. Commenters stated that many hospitals scan physician paper 
notes into EHR technology, particularly in the small hospital setting 
where the EPs are not normally employed by the hospital.
    A commenter suggested that the capabilities included in this 
certification criterion be expanded to require EHR technology to be 
able to export electronic notes as CDA Level 2 documents. The commenter 
stated that this would require the electronic notes to be wrapped with 
a CDA document header and to identify the document type and section 
headings with LOINC[supreg] codes. The commenter stated that this would 
not be an onerous requirement because most commercial transcription 
services can already meet these requirements. The commenter further 
stated that this requirement would provide hundreds of millions of 
interoperable clinical documents per year and enrich the clinical 
content shared during care transitions.
    Response. We have adopted an ``electronic notes'' certification 
criterion for the 2014 Edition EHR certification criteria at Sec.  
170.314(a)(9) as proposed. After consideration of public comments, CMS 
has included an ``electronic notes'' objective and measure in the MU 
Stage 2 menu set and the adoption of this certification criterion will 
support that objective and measure. We direct commenters to the Stage 2 
final rule for further discussion of the ``electronic

[[Page 54172]]

notes'' objective and measure, including description of notes that 
qualify for the numerator and explanation of who can create, edit, and 
sign a note.
    We did not propose, nor do we believe, that there is a standard and 
industry-wide accepted format for capturing electronic notes. 
Therefore, we agree with the commenters that suggested that a range of 
options be permitted for capturing notes, including templates and free 
text. We also note that in the Stage 2 final rule scanned notes that 
are text searchable are acceptable for inclusion in the numerator. This 
requirement should address the commenters' concern about illegible 
scanned notes.
    We appreciate the support expressed for the search capability 
included in this certification criterion. After consideration of 
comments, we have concluded that the search capability that EHR 
technology must demonstrate to meet this certification criterion should 
be limited to the ability to search within a note. We believe this will 
provide EPs, EHs, and CAHs with a search capability that will be 
useful, but still permit EHR technology developers to design and 
develop search capabilities that meet specific customer needs. 
Additionally, as commenters noted, this will permit the market to 
innovate and offer various search capabilities for EPs, EHs, and CAHs.
    While we appreciate the commenter's suggestion that the 
capabilities included in this certification criterion be expanded to 
require EHR technology to be able to export electronic notes as CDA 
Level 2 documents, we decline to require EHR technology to demonstrate 
this capability as a condition of certification since such a capability 
would go beyond what we believe it is necessary to require for 
certification in support of MU.
     Image Results

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

    We proposed to adopt a new ``imaging'' certification criterion as 
part of the 2014 Edition EHR certification criteria to support an EP's, 
EH's, and CAH's performance of the proposed new MU objective and 
measure. In the Proposed Rule, we clarified that the phrase ``immediate 
electronic access'' was intended to mean that a user should be able to 
electronically access images and their narrative interpretations 
directly and without, for example, having to log in to a separate 
electronic system or repository. We stated that this access could be 
provided by multiple means, including, but not limited to, ``single 
sign-on'' and ``secure identity parameter passing.'' We also considered 
the Digital Imaging and Communications in Medicine (DICOM) standard for 
this certification criterion, but concluded that the adoption of this 
or other standards was not necessary to enable users to electronically 
access images and their narrative interpretations, as required by this 
certification criterion.
    We have categorized and responded to comments under subheadings for 
the purposes of clarity and readability.
Types of Images
    Comments. Commenters requested a clear definition of ``image'' as 
well as ``narrative interpretation.'' Commenters asked whether both 
cardiology and pathology images are included or whether images were 
limited to radiology. A few commenters specifically suggested that 
images be limited to radiology and MRIs and not include photography or 
electrocardiograms (ECGs). One commenter suggested the inclusion of 
ECGs.
    Response. It is outside the scope of this rulemaking to define the 
scope of images and narrative interpretations. We direct commenters to 
the Stage 2 final rule found elsewhere in this issue of the Federal 
Register for a discussion of the MU objective and measure and responses 
to these comments.
Internal and External and Storage of Images
    Comments. Commenters stated that the requirement to display 
diagnostic images is ideal; however, the infrastructure to display 
images from all possible modalities, along with all possible technology 
solutions within the ambulatory setting, would require huge numbers of 
costly interfaces to integrate the images into the EHR technology. 
Commenters further stated that clinical images are often large and 
stored on external PACS systems. As such, these commenters contended 
that requiring EHR technology to duplicate image storage and perform at 
the level of a PACS system would be difficult and unnecessary 
functionality for EHR technology. Some commenters stated that EHR 
systems should not be required to store images, since the use of 
reference pointers is enabled by DICOM Web Access to DICOM Persistent 
Objects (WADO) standards. Commenters stated that the incorporation of 
scanned images into EHRs is generally ineffective at improving patient 
care. These commenters stated that when images are scanned into EHRs, 
physicians cannot manipulate the data, which may prevent them from 
truly seeing the images or understanding what the images represent. A 
few other commenters stated that the storing of images by any means to 
facilitate access will be costly.
    Commenters recommended that the certification capability be limited 
to directly linking to images stored in the EHR technology or providing 
a context-sensitive link to an external application, which provides 
access to images and their associated narrative. Other commenters 
asserted that current EHR technology does not track whether a PACS link 
is ``available'' or ``clicked on'' because the user interaction happens 
largely with the Web-based PACS application. These commenters believed 
that there might be barriers to EHR technology collecting information 
about the availability of third party data accessible via a Web link 
within the EHR to sufficiently meet this requirement. A few commenters 
suggested that we limit the capability to provide narrative 
interpretations and recommended that the ability to view images within 
or through EHR technology be optional.
    Response. We have adopted a new ``image results'' certification 
criterion to support the new MU objective and measure. We clarify that 
we did not propose nor are we requiring that EHR technology has to be 
able to store images to meet this certification criterion. EHR 
technology can meet this certification criterion by demonstrating a 
capability to directly link to images stored in the EHR system or 
providing a context-sensitive link to an external application which 
provides access to images and their associated narrative. By ``context 
sensitive link'' we mean that the link to the image will ideally 
include parameters that enable access to the images themselves rather 
than access to a system--which would require login, patient search, 
image selection, and (finally) image viewing. However, we agree with 
commenters that there is insufficient penetration of single sign-on or 
services-oriented integration capabilities between EHR technology and 
PACS systems, and that the fluidity with which this access is enabled 
may not be under the CEHRT's control. We therefore do not explicitly 
require that this link provide ``immediate access'' as described below. 
Finally, we emphasize that access to both narrative and imaging data 
must available to the user.

[[Page 54173]]

In cases where there is no narrative data (for example when a 
radiographic image has not yet been interpreted by a radiologist) there 
will obviously be no narrative available. Nonetheless, the EHR 
technology must be capable of retrieving and displaying the narrative 
information in order to meet this certification criterion.
    Comments. A commenter requested clarification on whether the 
proposed certification criterion pertains only to EPs who send x-rays 
outside of their facility or whether providers that take x-rays in 
their own offices required to meet this certification criterion.
    Response. This certification criterion applies to EHR technology 
designed for both the ambulatory and inpatient setting and expresses 
the capabilities that EHR technology would need to include in order to 
be certified to this certification criterion.
Clarification of Certification Criterion Text
    Comments. A few commenters asked for clarification of ``and/or'' 
and whether it implies optionality regarding either images or the 
corresponding narratives. Alternatively, the commenters asked if it 
means that the EHR technology must be certified for both availability 
of images and narrative interpretations. Other commenters asked whether 
the intent of ``electronically indicated to a user the availability of 
a patient's images'' was to identify imaging results as available in 
order to circumvent redundant imaging tests. If that is the intent, the 
commenter recommend that we require, at minimum that information on 
when the imaging test was completed, results pending, results location 
and date of completion be provided. Similarly, a commenter requested 
clarification of whether a ``list'' of past imaging tests completed 
would helpful.
    Response. For clarity, we have removed the ``or'' from the ``and/
or'' in the regulation text. EHR technology must be capable of 
electronically indicating the availability of both images and narrative 
interpretations. Redundant imaging tests can lead to unnecessary costs. 
We believe that the capabilities included in this certification 
criterion can assist in preventing redundant testing. This 
certification criterion, however, includes those capabilities that are 
necessary to support an EP, EH, or CAH's attempt to achieve the 
associated MU objective and measure. Therefore, we decline to include 
the additional capabilities recommended by the commenters.
Immediate Electronic Access
    Comments. Some commenters expressly supported our proposal that 
users should have ``immediate electronic access'' to images and their 
narrative interpretations directly and without having to login to a 
separate electronic system. Many commenters stated that the 
requirements for ``immediacy'' go beyond the capabilities of the EHR 
system. Some commenters suggested the term ``immediate'' be removed 
from the certification criterion. Other commenters requested 
clarification of what immediate electronic access entailed. A commenter 
stated that there appeared to be two different functions coupled with 
the word ``immediate''--taking the image and getting access to the 
image. Commenters also specifically stated that the requirements for 
``immediacy'' via additional sign-on capabilities and other system 
requirements are beyond the control of the EHR system and, thus, should 
not be required for certification. One commenter suggested that, in 
order to ensure immediate access, EHR technology should provide stream-
capable hyperlinks to images that can be viewed in a typical web 
browser without the delay related to use of DICOM file transfer and 
without the requirement to install additional software beyond the 
standard web browser itself.
    Response. We agree with commenters that ``immediate'' access is 
vague and would be difficult to implement in EHR technology at this 
time, particularly with methods such as single sign-on. Therefore, we 
are removing the term ``immediate'' from the certification criterion.
Applicable Standard
    Comments. Some commenters suggested that no standard be adopted for 
this certification criterion. Conversely, some commenters recommended 
the inclusion of the DICOM standard as a requirement for EHR 
certification, as well as certification of DICOM compliance for the 
storage and transmission of images. Commenters reasoned that the DICOM 
standards and complementary implementation guides developed by 
Integrating the Healthcare Enterprise[supreg] (IHE) provide 
satisfactory methods for the formatting of medical imaging and for 
their access through EHR systems. Some commenters specifically 
recommended that DICOM Supplement 127: CT Radiation Dose Reporting 
(Dose SR) should be required for the transmission of patient radiation 
dose information.
    Some commenters suggest that we adopt the Consolidated CDA 
Diagnostic Imaging Report standard and the DICOM image standard for 
exchanging images and their interpretations. A few commenters 
recommended that we at least communicate that we intend to move towards 
requiring this standard to complement the DICOM image standard for use 
in exchanging images and their interpretations.
    Response. We appreciate commenters' recommendations regarding the 
DICOM standard, but the recommendations and information provided has 
not altered our position expressed in the Proposed Rule nor has CMS 
made revisions to the associated MU objective and measure that would 
alter our position. As stated in the Proposed Rule, we concluded that 
the adoption of the DICOM standard (or any other standards) was 
unnecessary to enable users with electronic access to images and their 
narrative interpretations, the capability required by this 
certification criterion and for MU.
     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 proposed to adopt at Sec.  170.314(a)(13) a 2014 Edition EHR 
certification criterion for family health history. The proposed 
certification criterion required that EHR technology be able to, at 
minimum, electronically record, change, and access the health history 
of a patient's first-degree relatives. The Proposed Rule also solicited 
comment on whether we should adopt 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]) terms for familial conditions. We also noted that 
the Surgeon General had 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 and sought 
comments on the maturity and breadth of adoption of this tool and its 
export format.
---------------------------------------------------------------------------

    \3\ https://www.hl7.org/implement/standards/product_brief.cfm?product_id=8.
---------------------------------------------------------------------------

    Comments. Commenters generally supported the concept of including a 
certification criterion related to family health history. A commenter 
noted that our description of the capabilities in this certification 
criterion was

[[Page 54174]]

somewhat ambiguous and thus requested confirmation that we did not mean 
to imply that this criterion requires the capability to access the 
patient's first degree relatives' records. Many commenters expressed 
that the HL7 Pedigree standard was not widely used or sufficiently 
mature to adopt at the present time. Similarly, many commenters also 
expressed that if a specific terminology is required for coding 
familial conditions, then SNOMED CT[supreg] would be an appropriate 
terminology. Commenters requested that the certification criterion 
permit unstructured/free text entry.
    Response. We appreciate commenters' general support for this 
certification criterion. Equally, CMS received a great deal of support 
and has included a family health history objective in the MU Stage 2 
menu set. Accordingly, we have finalized a certification criterion for 
family health history.
    We clarify that this certification criterion requires EHR 
technology to demonstrate that it is capable of enabling a user to 
electronically record, change, and access a patient's family health 
history. This means that EHR technology must, at minimum, be capable of 
recording information about a patient's first degree relative in the 
patient's record and permitting a user to change and access that 
information as needed. EHR technology would not need to be able to 
access the records of a patient's first degree relatives.
    In support of MU, this certification criterion requires that EHR 
technology be capable of capturing family health history in structured 
data. Therefore, the certification criterion we have adopted does not 
permit unstructured/free text for certification because such entries 
would not constitute MU of CEHRT. Similar to commenters, we believe 
that SNOMED CT[supreg] is an appropriate terminology, and perhaps the 
best intermediate step, for coding family health history in structured 
data if one was not to use the HL7 Pedigree standard. We also 
understand that some organizations have built family health history CDS 
interventions using SNOMED CT[supreg].
    The HL7 Pedigree standard was originally released in 2007. Release 
1 was recently reaffirmed by the American National Standards Institute 
(ANSI), which is a process that occurs every five years. We have 
adopted this reaffirmed version as it is the same version (Release 1) 
of the standard as the version we proposed. An implementation guide for 
this standard is scheduled to be published shortly after this final 
rule. Although EHR technology will not be required to conform to the 
implementation guide for certification, the implementation guide will 
provide important guidance for use of the HL7 Pedigree standard with 
EHR technology.
    We have finalized that EHR technology may meet this certification 
criterion by either being able to capture a patient's family health 
history in SNOMED CT[supreg] or in the HL7 Pedigree standard. Since the 
use of SNOMED CT[supreg] is required for meeting several other 
certification criteria, we do not believe that it will be a challenge 
to meet this certification criterion. We emphasize, as specified in the 
Sec.  170.300(b), when ``a certification criterion refers to two or 
more standards as alternatives, use of at least one of the alternative 
standards will be considered compliant.'' Thus, an EHR technology can 
demonstrate use of SNOMED CT[supreg] or the HL7 Pedigree standard to 
meet this certification criterion.
     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 proposed to adopt a new ``amendments'' certification criterion 
(Sec.  170.314(d)(4)) as part of the 2014 Edition EHR certification 
criteria. We made this proposal based on HITPC and HITSC 
recommendations which included that a certification criterion should be 
adopted that provides some of the basic technical tools to support 
compliance with the HIPAA Privacy Rule. We noted in the Proposed Rule 
that the proposed certification criterion does not address all of the 
requirements specified at 45 CFR 164.526 and that EHR technology 
certification is not a substitute for, or guarantee of, HIPAA Privacy 
Rule compliance. Finally, we requested comment on whether EHR 
technology should be 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.
    Comments. Many commenters recommended that the proposed 
certification criterion's reference to ``free text or scanned'' patient 
supplied information be revised. Many supported both and suggested that 
both be permitted. Others contended that the certification criterion 
was over specified and suggested that ONC not specify one or the other 
because patient-supplied information could take many forms. In general, 
commenters suggested that EHR technologies have different ways of 
appending information and that either of these methods would be 
sufficient for certification. Another commenter noted that scanning 
patient amendments could be problematic from a storage perspective. One 
commenter agreed with the certification criterion but recommended that 
ONC should have robust standards for how patient information is 
appended to EHR technology before allowing EHR technology developers to 
create multiple versions of this workflow. Yet another stated that the 
ability to append patient supplied information should be no different 
from the ability to append any other ancillary information (outside 
reports from other providers). One commenter stated that EHR technology 
developers should only need to be certified to one method of amendment 
and not all (i.e., free text, scanned information, or embedded links) 
in order to meet the certification criterion. Additionally, a commenter 
noted that amending the patient record should be allowed via the two 
methods proposed, but that scanned documents should have to adhere to a 
standard such as PDF or JPG.
    Last, a group of commenters took issue with the phrase ``electronic 
link'' in the certification criterion. They raised concerns that the 
phrase ``embedding an electronic link'' in the certification criterion 
could be interpreted in many ways, including some that would create 
security risks. Commenters suggested removing ``or by embedding an 
electronic link'' to allow different forms and ways to append patient-
supplied information. They also noted that the HIPAA Privacy Rule does 
not mention electronic links.
    Response. In consideration of the comments received, we have 
modified this proposed certification criterion to make clear the 
capabilities that EHR technology must include in order to be certified. 
As we indicated in the Proposed Rule, we proposed this certification 
criterion at the HITPC's recommendation. Along those lines, we 
reiterated our agreement with the HITPC's expectation for this 
certification criterion, that it be ``kept as simple as possible and 
evolve over time to greater complexity, including potentially greater 
standardization and automation.'' Our revisions seek to make clear this 
certification criterion's focus on supporting the instance where a 
HIPAA covered entity agrees or declines to accept a patient's request 
for an amendment. Additionally, this certification criterion is meant 
to be a

[[Page 54175]]

starting point from which more comprehensive capabilities and standards 
can be included, so we disagree with the commenter that suggested we 
wait until more comprehensive standards are available.
    In response to commenter feedback, we have revised the 
certification criterion to more closely mirror the language in the 
HIPAA Privacy Rule at 45 CFR Sec.  164.526. In doing so, we no longer 
specify a particular format (i.e., free text or scanned) and we have 
revised the language associated with ``electronic link.'' The ``link,'' 
which is an alternative to appending the patient's record must convey 
to a user or enable a user to obtain the information associated with an 
amendment's acceptance or denial. We believe this adjustment to the 
certification criterion provides EHR technology developers with more 
flexibility with which to design a capability that can accommodate the 
outcome this certification criterion expresses.
    Comment. A commenter supported this proposed certification 
criterion and stated that there should be a mechanism to identify and 
make visible the source of the information to allow evaluation by any 
recipient that the information came from a reliable and accurate 
source.
    Response. We appreciate this commenter's suggestion. However, it 
appears to be more specific than we believe necessary at this point for 
this new certification criterion. We believe that the requirements we 
have included in the final certification criterion are a sufficient 
start. We also believe that the certification criterion may, in part, 
address this commenter's suggestion in that the information appended or 
linked in the case of an accepted or denied amendment should at least 
have an indication as to the source of the information (i.e., patient 
or provider/organization).
    Comments. Several commenters sought clarification as to whether 
patient-supplied information had to be appended to specific data in the 
patient's health record or attached to a specific instance of a 
clinical note or document. Another commenter expressed concern 
regarding the feasibility of being able to append patient supplied 
information to specific data. The commenter stated that this practice 
would be inconsistent with common provider policies that require all 
amendments to documents be classified as separate documents. In this 
way such information is clearly identified and maintained in a section 
or folder of the electronic record, and then subject to clinician 
review for what may be actually incorporated into the record upon 
acceptance. They indicated that by following this approach the patient 
requested amendment has its own ``wholeness'' or integrity as a medical 
record entry. In general, other commenters echoed this statement and 
suggested that it should be acceptable to have a separate section of 
the record for patient-supplied information.
    Response. The final certification criterion does not require that 
accepted or denied amendments be appended to specific data in order for 
compliance to be demonstrated. As indicated above, this criterion is 
intended to support compliance with the HIPAA Privacy Rule's amendment 
requirements at 45 CFR 164.526. The Privacy Rule provides some 
flexibility with how accepted or denied amendments are appended to an 
individual's protected health information, recognizing that the type 
and scope of an amendment will vary based on the circumstances. For 
example, the affected record could include a link to documentation of 
an accepted or denied amendment, while still allowing, in the case of 
an accepted amendment, any necessary corrections to be incorporated 
directly into the record itself.
    Comments. A couple of commenters requested clarification regarding 
the interplay between the terms ``amend'' and ``append'' in the 
certification criterion. One commenter stated that amendments are 
documentation meant to clarify health information within a health 
record whereas addendums are new documentation used to add information 
to an existing entry, and corrections are changes to information meant 
to clarify inaccuracies after the original document has been signed or 
rendered complete. The other commenter stated that we described 
``amending'' a patient's record as allowing clinicians to correct 
errors or update the information within their record and that later we 
referred to the act of ``appending'' patient supplied information by 
using free text and/or scanned material. This commenter stated that 
``amend'' and ``append'' are distinct concepts and should not be 
combined into one certification criterion because if we intend to allow 
these functions of correcting and/or attaching information to the 
patient's record they should remain separate. The commenter reasoned 
that amending should not permit any overwriting of the existing 
documentation and should include a date, time and authentication record 
of who took the action--while appending data should accurately capture 
the date, time, and authentication of the appended information.
    Response. The terminology used in this certification criterion is 
meant to mirror the terms used in the HIPAA Privacy Rule at 45 CFR 
164.526. Put simply, those rules describe that a patient is permitted 
to request an amendment to their health information and the 
corresponding obligations a HIPAA covered entity must follow to either 
accept or deny the requested amendment. As stated in 45 CFR Sec.  
164.526(c)(1), for example, if the amendment is accepted, ``[t]he 
covered entity must make the appropriate amendment to the protected 
health information or record that is the subject of the request for 
amendment by * * * appending or otherwise providing a link to the 
location of the amendment.'' Thus, this certification criterion 
reflects some of the capabilities needed in the event of an accepted or 
denied amendment.
    Comment. A commenter stated that Sec.  170.314(d)(4)(i)(A) 
conflicts with the description of the term of ``Change'' included in 
the Proposed Rule and that this criterion needs to be consistent with 
that definition.
    Response. This comment is incorrect. The term ``change'' as 
described in the Proposed Rule was not included in this certification 
criterion. Thus, there is no conflict with respect to the clarity of 
the capabilities specified by this certification criterion and others 
that include the term ``change.''
    Comment. A commenter asked for clarification on the degree of 
information retained. They stated that too much information makes the 
data storage requirements burdensome on providers and superfluous data 
makes it difficult for auditors to detect unauthorized access.
    Response. This certification criterion seeks to specify the EHR 
technology capabilities necessary to support, in part, the requirements 
specified at 45 CFR Sec.  164.526 and it is not within its scope to 
address the degree or amount of information retained.
    Comment. A commenter recommended that the electronic amendment 
contain a date/time stamp and reflect the user who took such action 
when content is amended.
    Response. We appreciate this commenter's suggestion, however, we 
expect that this kind of event would be subject to the audit log 
requirements we have already specified (and which includes time and 
date stamp).
    Comments. One commenter asked for clarification as to whether this 
criterion makes a distinction between ``work in progress'' records and 
``signed off'' records. They stated, for example, a user may make 
several changes to the same

[[Page 54176]]

data while working within a particular screen of the EHR technology. 
They suggested that the changes should only be captured when the user 
saves their changes and signs off on the record.
    Response. No, this certification criterion does not make such a 
distinction because those distinctions are inapplicable to this 
certification criterion. We believe the commenter misinterpreted the 
purpose of this certification criterion and its focus on incrementally 
building in the capacity of EHR technology to make compliance with the 
HIPAA Privacy Rule more efficient.
    Comment. One commenter noted a concern that if this certification 
criterion is applied to EHR Modules that are not part of the Base EHR 
definition that it could result in conflicting and overlapping 
practices and result in incorrect or inconsistent information in a 
patient record. For example, the commenter noted that it was a 
downstream business associate (or business associate subcontractor) and 
an intermediary, and thus does not amend patient information. Further 
they stated that they provide notice of any requests for amendments to 
their upstream business associates and covered entities with whom they 
directly contract. They concluded by stating that requiring an 
intermediary or developers of certain EHR Modules to have the 
capability to amend information could present confusion and should be 
applicable to core functionality of the EHR technology utilized at the 
provider level.
    Response. For some of the reasons expressed by this commenter, we 
proposed to remove the requirement that EHR Modules also be certified 
to the privacy and security criteria. We clarify that this 
certification criterion is not separately applied to any EHR Modules in 
order for them to be certified. An EHR technology developer needs to 
include such capability, however, if they seek certification for EHR 
technology that would meet the Base EHR definition.
    Comments. Two commenters recommended that we remove this 
certification criterion. One agreed that HIT should support workflow 
for complying with HIPAA privacy regulations, including allowing a user 
to amend a patient record, but contended that this functionality is 
typically found in a Medical Record Management system. Thus, they 
encouraged ONC to remove the certification criterion. However, they 
stated that if it remained, we should only require scanned documents. 
The other commenter recommended that we delay this certification 
criterion's adoption to a later edition of EHR certification criteria 
because the technical and legal implications of supporting patient 
amendments to the EHR are complex and evolving.
    Response. We have not removed this proposed certification 
criterion. We agree with the HITPC that starting with a simple 
certification criterion can set us on a path to include more 
comprehensive capabilities over time. We acknowledge that the processes 
involved in supporting patient amendments can sometimes be difficult, 
which is why we explained in the Proposed Rule and reiterated in the 
above responses that this certification criterion can only help support 
(and potentially make more efficient) a HIPAA covered entity's 
compliance with the HIPAA Privacy Rule.
    Comments. Several commenters supported the proposed certification 
criterion, but requested joint confirmation from ONC and CMS that EPs, 
EHs, and CAHs do not have to demonstrate use of this capability in 
order to meet meaningful use. Other commenters urged us to acknowledge 
that this functionality has importance beyond a privacy and security 
context.
    Response. This certification criterion expresses capabilities that 
EHR technology would need to include in order to meet this 
certification criterion. Given that this certification criterion is 
included as part of the Base EHR definition, EPs, EHs, and CAHs, will 
need to have EHR technology certified to this certification criterion 
in order to have EHR technology that meets both the Base EHR and CEHRT 
definitions. We have consulted with CMS and clarify that since there is 
not a meaningful use objective expressly requiring the use of this 
capability to satisfy an associated measure that EPs, EHs, and CAHs do 
not need to demonstrate use of this capability in order to meet any 
meaningful use stage. However, we encourage EPs, EHs, and CAHs to 
consider if this capability could make compliance with the requirements 
of the HIPAA Privacy Rule, particularly, 45 CFR Sec.  164.526, more 
efficient.
     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).
------------------------------------------------------------------------

    We proposed a new criterion at Sec.  170.314(e)(1) to subsume the 
certification criteria previously adopted at Sec. Sec.  170.304(f), 
170.304(g), 170.306(d), and 170.306(e). This proposal was based on the 
HITPC issued 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 MU 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 criterion, 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).
    In addition to the view and download capabilities recommended by 
the HITSC, we proposed to include a third specific capability in this 
certification criterion--the ability to transmit an ambulatory and 
inpatient summary to a third party. Coupled with this addition, we 
proposed that EHR technology would need to be capable of transmitting 
an ambulatory and inpatient summary according to the two 
specifications--developed under the Direct Project--which we proposed 
for adoption: (1) Applicability Statement for Secure Health Transport 
\4\ and (2) Cross-Enterprise Document Reliable Interchange (XDR) and 
Cross-Enterprise Document Media Interchange (XDM) for Direct 
Messaging.\5\ We indicated that these transport standards were ideal 
for this purpose and would make it possible for patients to transmit a 
copy of their ambulatory or inpatient summary to the destination of 
their choice. Additionally, because we proposed requiring the 
capability to perform transmissions in accordance with these transport 
standards (which provide for encryption and integrity protection) in

[[Page 54177]]

this criterion and in the ``transitions of care--create and transmit 
transition of care/referral summaries'' certification criterion, we 
determined that it would not be 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 stated our belief that to include the 
2011 Edition EHR certification criterion would be redundant and that 
our proposed approach more explicitly tied security to a particular 
transmission.
---------------------------------------------------------------------------

    \4\ https://wiki.directproject.org/
Applicability+Statement+for+Secure+Health+Transport.
    \5\ https://wiki.directproject.org/
XDR+and+XDM+for+Direct+Messaging.
---------------------------------------------------------------------------

    At the recommendation of the HITSC, the proposed certification 
criterion required 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 and make that information available to the patient. We 
required this specific capability within this certification criterion 
because we believed that it was 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 
proposed to adopt at Sec.  170.314(d)(2) (due to the proposed policy 
change we specified in section IV.C.1 of the proposed rule related to 
EHR Modules and privacy and security). Thus, this explicit proposal was 
meant to guarantee 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 
noted that we did 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 
tamper resistance certification criterion. Accordingly, we provided 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, we 
clarified that 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 proposed that the ``patient accessible log'' capability 
would need to record the date and time each action occurs 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).
    We proposed to require EHR technology to be capable of enabling 
images formatted according to the Digital Imaging and Communications in 
Medicine (DICOM) standard \6\ to be downloaded and transmitted to a 
third party. We stated our belief that this specific capability has the 
potential to empower patients to play a greater role in their own care 
coordination and could help assist in reducing the amount of redundant 
and duplicative imaging-oriented tests performed.
---------------------------------------------------------------------------

    \6\ ftp://medical.nema.org/medical/dicom/2011/.
---------------------------------------------------------------------------

    Consistent with our belief that all patients should have an equal 
opportunity to access their electronic health information without 
barriers or diminished functionality or quality, we proposed that the 
viewing capability must meet Level AA conformance with the most recent 
set of the Web Content Accessibility Guidelines (WCAG). We explained 
that 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.\7\ We further explained that each guideline offers 3 levels of 
conformance: A, AA, and AAA. We proposed 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. In addition to WCAG 2.0 Level AA conformance, we requested 
public comment on whether commenters believed additional standards were 
needed for certification to ensure accessibility for the viewing 
capability, such as the User Agent Accessibility Guidelines (UAAG).\8\
---------------------------------------------------------------------------

    \7\ https://www.w3.org/TR/WCAG20/.
    \8\ https://www.w3.org/WAI/intro/uaag.php.
---------------------------------------------------------------------------

    We proposed to require that EHR technology be capable of providing 
the information that CMS proposed be required in an ambulatory or 
inpatient summary that is provided to patients or their authorized 
representatives. This proposal was based on the HITSC's recommendation 
that we move to one standard for capturing this information and our 
belief that moving to one standard would lead to increased 
interoperability and spur innovation. We explained that we believed the 
Consolidated CDA was 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 an ambulatory or inpatient summary 
that includes all of the data elements that CMS proposed be available 
to be populated in an ambulatory or inpatient summary.
    In certain instances in Sec.  170.314(e)(1), we proposed to require 
that the capability be demonstrated in accordance with the specified 
vocabulary standard--which were previously adopted or proposed for 
adoption in the Proposed Rule consistent with the recommendations of 
the HITSC. With the exception of four standards (LOINC[supreg], ICD-10-
CM, ICD-10-PCS, and CPT/HCPCS), the vocabulary standards included in 
the certification criterion were discussed elsewhere in the Proposed 
Rule 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 proposed the use of ICD-
10 (ICD-10-CM and ICD-10-PCS, respectively). We requested 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 noted our interest in whether commenters believed 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 asked 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 proposed 
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, we stated that EHR technology must be capable of 
transmitting the tests performed in LOINC[supreg] 2.38 to meet this

[[Page 54178]]

certification criterion and for all other proposed certification 
criteria that include the capability to transmit laboratory tests in 
the LOINC[supreg] 2.38 standard. We proposed 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 for procedures 
and encounter diagnoses at Sec.  170.207(b)(3) and (m), respectively.
    We received a significant amount of comments on the proposed view, 
download, and transmit to a 3rd party certification criterion. To make 
clear the policy expressed in our responses to comments, we have used 
subheadings under which specific comment themes will be discussed. In 
response to comments, we have made several revisions to the proposed 
certification criterion. Those revisions are explicitly noted in the 
applicable response.
View
    Comments. Many commenters raised questions and concerns about the 
data we specified EHR technology would need to be capable of making 
viewable to a patient or their authorized representative. Some 
contended that the data exceeded those required for this use case and 
questioned the value of such data. Others pointed out that we did not 
have a consistent list of data between the ``view'' and ``download'' 
paragraphs. Commenters specifically called out ``encounter diagnoses'' 
as being inconsistently applied and raised concerns about our proposal 
to refer to ICD-10-CM.
    With respect to the vocabularies we proposed for procedures several 
commenters disagreed with our proposal to permit EHR technology to be 
certified to represent procedures in ICD-10-PCS. Overall, commenters 
suggested in one form or another that SNOMED CT[supreg] should be the 
sole clinical vocabulary for documentation because it would help better 
meet the information objectives for MU. They further stated that SNOMED 
CT[supreg] is most appropriate when data is to be represented for 
clinical purposes and clinical accuracy. Commenters also contended that 
ICD-10-PCS was an inappropriate standard to reference for the purposes 
of clinical data exchange and was best suited for billing diagnosis and 
billing purposes. Among those comments at least one commenter stated 
that SNOMED CT[supreg] should be an alternative vocabulary standard 
included in the final rule. Another commenter stated that permitting 
the use of ICD-10-PCS to represent procedures in a Consolidated CDA 
formatted document would unnecessarily limit the usefulness of the 
Consolidated CDA document. This commenter stated that SNOMED CT[supreg] 
was the appropriate reference terminology to use to encode procedures. 
Similarly, other commenters recommended we replace ICD-10-PCS with 
SNOMED CT[supreg] because they believed that ICD-10-PCS would be 
inappropriate to use to represent procedures. They contended that 
procedures need to address counseling, education, and specific 
interventions that are not managed with a billing vocabulary. Last, one 
commenter stated that we should adopt the American Dental Association's 
Current Dental Terminology (CDT) as a vocabulary to represent 
procedures. They reasoned that CDT is a named HIPAA standard for use in 
electronic administrative transactions for dental claims and that this 
is the standard vocabulary dentists use to represent procedures.
    Response. The data that is specified in this certification 
criterion was proposed to directly mirror the data that CMS proposed 
should be available for patients to view, download, and transmit to a 
3rd party. Thus, we disagree that the data exceeds what is required for 
this use case. We have worked with CMS to align the data specified in 
this certification criterion. In that respect if there were any 
discrepancies we have corrected them. Additionally, as discussed 
earlier in this preamble we have revised this certification criterion 
to refer to the Common MU Data Set, which has significantly reduced the 
certification criterion's overall size and complexity. Further, we have 
removed ``encounter diagnoses'' from this certification criterion 
because it is no longer data that is minimally necessary to support 
what CMS has finalized for the objective and measure this certification 
criterion is designed to support. ``Encounter diagnoses'' is referenced 
by the transitions of care certification criterion (Sec.  
170.314(b)(2)) and the data portability certification criterion (Sec.  
170.314(b)(7)). Since the data portability certification criterion 
mirrors a portion of the transitions of care certification criterion, 
we have chosen to provide our response to comments on encounter 
diagnoses when we discuss the transitions of care certification 
criterion.
    In consideration of the comments we received in response to our 
questions about ICD-10-PCS, we agree with those commenters that argued 
SNOMED CT[supreg] is a more appropriate vocabulary to reference in this 
case. As commenters noted, SNOMED CT[supreg] is more appropriate for 
clinical purposes and provides greater clinical accuracy. Thus, this 
final rule requires that in order for EHR technology to be certified to 
a certification criterion that references ``procedures'' data, it must 
demonstrate compliance with the use of SNOMED CT[supreg] or CPT/HCPCS 
(the latter is already adopted as part of the 2011 Edition EHR 
certification criteria and was carried forward in the Proposed Rule). 
However, in recognition that it may be beneficial for inpatient EHR 
technology developers to demonstrate compliance with, and support for 
the use of, ICD-10-PCS to represent procedures in the various 
certification criteria that reference procedures, we have adopted ICD-
10-PCS as an ``optional'' vocabulary standard to which EHR technology 
developers can seek certification for their EHR technology.
    In consideration of the comment suggesting that we include CDT as 
an alternative vocabulary for dentists, we have done so. However, we 
have adopted this vocabulary as ``optional'' and in addition to (not in 
lieu of) one of the primary vocabularies necessary for representing 
procedures data. Therefore, in the event that an EHR technology 
developer seeks to get its EHR technology certified to CDT, it will 
have to also be certified to one of the mandatory standards we have 
adopted for representing procedures, either SNOMED CT[supreg] or CPT/
HCPCS.
    Comments. Commenters recommended that we delineate which data for 
view is optional as which data is required.
    Response. We decline to make this change. In order to be certified, 
EHR technology must be capable of permitting a patient or their 
authorized representative access to all of the data specified by the 
certification criterion. What information is actually made available by 
an EP, EH, or CAH and how it is displayed to a patient or their 
authorized representative should be determined by the EP, EH or CAH.
    Comments. Some commenters asked that we clarify that the term 
``gender'' as proposed was really intended to mean ``sex'' given the 
wide range of characteristics that could be encompassed by the term 
gender.
    Response. We agree. Both ONC and CMS have included the term ``sex'' 
in our final rules.
    Comments. A commenter advocated that the substitution of patient 
friendly terms for diagnoses should be permitted.
    Response. We agree. We clarify and have modified the regulation 
text to explicitly indicate that for view (and download) that where 
certain coded data exists, the English language

[[Page 54179]]

descriptions and not the codes should be viewable to a patient or their 
authorized representative.
    Comments. Commenters recommended that we include the additional 
flexibility of being able to import (save ``as is'') and view CCD/C32 
and CCR documents in order to provide a transition between Stages 1 and 
2. They stated that as a patient if they viewed an old CCD it should 
still count towards the MU numerator.
    Response. We did not accept this recommendation and have not 
included this type of capability in the certification criterion. In 
large part, these comments are out of scope for this rulemaking and 
focus on measurement, which is relevant to the MU objective and measure 
with which this certification criterion correlates. That being said, 
the certification criterion does not specify how data is made viewable. 
Taking this approach is not necessarily precluded by the certification 
criterion and may somehow be able to address the view capability. 
However, we are uncertain, without additional details, whether the use 
of these older standard document formats would in practicality meet the 
numerator and denominator requirements for the MU measure or the new 
data required to be made viewable.
    Comment. A commenter requested that we provide detailed 
requirements to EHR technology developers on how to address potential 
language barriers in their products (especially with regard to the use 
of the patient portal). They stated that a language barrier would 
negatively impact providers' abilities to engage patients and get them 
to use the view, download, and transmit capabilities. They contended 
that it would be inconsistent to require patient engagement through the 
use of a patient portal and not provide common standards for multi-
lingual or predominantly non-English speaking communities where 
providers might exclusively practice.
    Response. While we appreciate this commenter's suggestion and 
believe in the importance of multi-lingual accommodations, we believe 
this suggestion is a significant departure from the certification 
criterion proposed and would require additional study to determine how 
to appropriately frame it as a certification requirement for EHR 
technology. Thus, we have not changed the certification criterion in 
response to this comment.
    Comments. A commenter recommended that this certification criterion 
should include more specific capabilities than we proposed such as, 
accommodate patient generated data to ``upload'' into the EHR; include 
linkages to patient specific education materials; and be based upon a 
standing patient preference.
    Response. We did not accept this recommendation. We believe the 
certification criterion is properly scoped to support its correlated MU 
objective and measure and do not seek to introduce additional burden 
that could be value-added functionality outside the scope of 
certification that EHR technology developers can include for 
competitive purposes.
Accessibility
    Comments. Commenters generally supported the underlying rationale 
behind the proposal, with some endorsing the requirement as proposed. 
Other commenters contended that achieving WCAG Level AA compliance in 
the time available would be extremely difficult for EHR developers to 
achieve. They stated that it is very complex to achieve compliance in a 
real world scenario and that Level AA conformance imposes a burden too 
great at this point in time. Further, they stated that the requirements 
for interfacing to independent accessibility tools (also required by 
WCAG 2.0), such as those that read screen text aloud can be impossible 
to achieve for ``snappy'' and ``intelligent'' JavaScript-dependent 
applications. One commenter noted that as of April 2012, two well-known 
news sites reported 76 and 104 known problems, respectively. Some 
commenters suggested removing this requirement altogether while others 
suggested that we take a more incremental approach and start with Level 
A conformance which could set the stage for a predictable progression 
to Level AA at a later date. Commenters also requested that we clarify 
that the WCAG standard would apply only to patient viewable information 
as intended by this certification criterion.
    Response. We appreciate commenters support for this proposal. As we 
noted in the proposed rule, we believe that all patients should have an 
equal opportunity to access their electronic health information without 
barriers or diminished functionality or quality. We recognize that this 
was a new requirement proposed for the 2014 Edition EHR certification 
criteria and in considering the burden concerns identified by 
commenters and need for greater experience with WCAG generally, we have 
decided to require Level A conformance instead of Level AA. As some 
commenters noted starting at Level A will provide a baseline from an 
accessibility perspective and one on which we can build in future 
rulemakings. Accordingly, we would like to express our intention to 
propose requiring Level AA in our next rulemaking cycle and encourage 
EHR technology developers to take the steps necessary to be on a path 
towards Level AA conformance. We also clarify, as requested, that the 
WCAG standards apply to the information that is viewable to the patient 
or their authorized representative through the capabilities EHR 
technology includes that would enable them to electronically view, 
download, and transmit their health information to a 3rd party.
    Comments. Comments stated that most patients want functions and 
content provided in a more visually appealing manner than the standard 
allows. Commenters requested that we clarify for certification whether 
an EHR technology developer would need to show how the product can be 
configured for WCAG 2.0 requirements by an implementer or whether the 
EHR technology must be ``preconfigured'' to those requirements (e.g. 
preset for font, contrast, color settings, etc). They stated, for 
example, that an EHR technology developer might have a configuration 
choice for accessibility that a consumer could opt for using that would 
include setting the contrast, font, color scheme, etc. to be conformant 
to accessibility requirements but allow other users to be able to 
select other settings as a matter of choice. They suggested that for 
certification it should be sufficient for an EHR technology developer 
to show how the settings for accessibility can be configured, but not 
predefined or preset.
    Response. In order to demonstrate conformance with the 
certification criterion, EHR technology will need to meet WCAG Level A. 
So long as the EP, EH, or CAH (as the customer) can appropriately 
configure the EHR technology for the patient, then that is sufficient. 
The certification criterion does not specify that certain design 
elements be predefined or preset.
    Comment. A commenter suggested that we consider if there are third 
parties that can provide supportive independent evidence of conformance 
to the WCAG standards or if any self-attestation evidence can be 
provided for review by the NVLAP-accredited testing laboratory so that 
if a vendor has pursued such third party review, it does not have to do 
so in repetition for the sake of 2014 certification.
    Response. While we believe that such documentation could expedite 
the review by a NVLAP-accredited testing laboratory, the EHR technology 
would still need to be independently assessed by the testing laboratory 
for

[[Page 54180]]

conformance following test procedures approved by the National 
Coordinator.
    Comments. Several commenters, in response to our request for 
comment on the UAAG standard, did not support its adoption as part of 
this certification criterion because they contended that it does not 
apply to Web sites like patient portals. Rather, they stated that it 
applies only to web browsers.
    Response. We have not included or adopted the UAAG standards at 
this time and appreciate commenters' detailed feedback.
Download
    Comments. A couple of commenters stated their belief that in order 
to meet the ``human readable'' aspect of this certification criterion 
that an HTML view of the XML file for the Consolidated CDA should be 
adequate for both viewing and downloading.
    Response. As we have previously stated in the S&CC July 2010 final 
rule (75 FR 44598) in response to questions about the meaning of human 
readable, the use of a style sheet associated with a document formatted 
according to the Consolidated CDA would be permitted.
    Comments. Commenters asked that we specifically clarify that for 
the ``download and transmit'' requirements, the data itself must be 
downloaded and transmitted and not merely a link to the data is what is 
downloaded and transmitted.
    Response. Yes, the data itself must be downloaded and transmitted. 
A hyperlink to the data would not be sufficient for EHR technology to 
demonstrate compliance with this certification criterion.
    Comments. Many commenters supported the proposed adoption of the 
Consolidated CDA standard and our proposal to move to this as the 
single standard. Some opposed this proposal altogether, while others 
suggested that the previously adopted CCD standard as well as the CCR 
standard should continue to be permitted because the Consolidated CDA 
was immature.
    Several commenters requested clarification related to the aspects 
of the Consolidated CDA that are required for certification. More 
specifically, they stated that the Consolidated CDA is an 
implementation guide for nine different document types (eight 
structured and one unstructured), and that it would not only be 
inappropriate to require the use of all of these document types for all 
environments but would in fact not make sense for elements like a 
discharge summary for an EP). Many recommended that the certification 
requirement be that the EHR technology should demonstrate the ability 
to generate at least one of the available CCDA document types and that 
providers will be able to use the document type most appropriate to the 
clinical situation.
    A couple of commenters stated that we should explicitly prohibit 
the use of the unstructured document template because not doing so 
would allow EHR technology developers to bypass using structured and 
coded data.
    Last, a couple of commenters noted that each time a ``care 
summary'' is specified in the Proposed Rule that it was described 
slightly differently. They contended that these differences will cause 
unnecessary confusion and disruption throughout the care delivery 
process. Additionally, they noted that none of the data sets specified 
for the certification criteria that reference the Consolidated CDA 
precisely matched any existing document-level templates in the 
Consolidated CDA.
    Response. We appreciate commenters support for the Consolidated 
CDA, and have finalized its adoption in the final rule. We believe that 
moving to a single standard is absolutely necessary to advance 
interoperability. The Consolidated CDA represents a significant amount 
of effort by industry stakeholders and we believe it is the best 
available standard to require for certification and to meet our policy 
objectives for interoperability. As noted by some commenters and, what 
appeared to be unknown to others, the Consolidated CDA is not per se a 
competing standard with the CCD because it contains within it a 
document-template that describes how to implement a CCD according to 
new, harmonized and consolidated implementation guidance (CCD v1.1). So 
the CCD document-template represented in the Consolidated CDA is an 
update to the CCD/C32 implementation guidance. That being said, as 
precisely noted by commenters, none of the 8 specific structured 
document-level templates in the Consolidated CDA neatly support the 
data specified by this certification criterion as well as the others in 
which it is also referenced (clinical summary, transitions of care, and 
data portability). Accordingly, we clarify that, with respect to the 
Consolidated CDA, certification will not focus on a specific document-
level template because none are particularly suited to support MU's 
policy objectives and the data elements specified across the different 
certification criteria that reference the Consolidated CDA. Rather, 
certification will focus on an EHR technology's ability to properly 
implement the US Realm header and the associated section-level 
templates necessary to support each certification criterion in which 
the Consolidated CDA is referenced and for the appropriate data 
specified in each of those certification criteria. We intend for 
testing and the test data made available for these certification 
criteria to enable consistent Consolidated CDA implementations. 
Further, based on our policy decision to focus testing and 
certification on section-templates, we have performed additional 
analysis of the Consolidated CDA. Based on our analysis, we note that 
absent certain conformance requirements otherwise specified in a 
particular document-level template, our approach could result in 
implementation ambiguities. These ambiguities could exist because 
section-templates when viewed independently of a particular document-
template permit the use of narrative text, coded entries optional, or 
narrative text and required structured data, coded entries required. 
Thus, we believe it is necessary to clarify for EHR technology 
developers that in all instances where we have adopted a vocabulary 
standard in Sec.  170.207 the accompanying section-template implemented 
must be done so using the section-template with required structured 
data, coded entries required.
    We agree with the comments that suggested we prohibit the use of 
the unstructured document-template included in the Consolidated CDA. As 
referenced in the Consolidated CDA, an ``unstructured document is a 
document which is used when the patient record is captured in an 
unstructured format that is encapsulated within an image file or as 
unstructured text in an electronic file such as a word processing or 
Portable Document Format (PDF) document.'' We believe that permitting 
this document template to be used as part of the Consolidated CDA or 
leaving any ambiguity as to whether it can be used to meet this 
certification criterion would be inconsistent with our policy 
objectives. Thus, we have indicated in Sec.  170.205(a)(3) where we 
have adopted the Consolidated CDA that the use of the unstructured 
document template is not permitted.
    We also take this opportunity to identify for stakeholders a 
modification we believe must be made to this certification criterion in 
order to align our final rule with clarifications made in CMS's final 
rule and, ultimately, in order to ensure the CEHRT EHs and CAHs adopted 
can support their achievement of MU. Further, this modification is only 
applicable to the inpatient setting only and is designated in the 
certification criterion as such. In its proposed rule (77 FR, 13730) 
CMS

[[Page 54181]]

proposed that one of the information types, a patient should be able to 
download would be their ``care transition summary and plan.'' In 
response to comments, CMS clarified and has listed these two 
information types as separate kinds of information that must be able to 
be downloaded. Accordingly, we have included in this certification 
criterion that for the inpatient setting a patient would need to be 
able to electronically download transition of care/referral summaries 
that were created as a result of a transition of care/referral 
(pursuant to the capability expressed in the certification criterion 
adopted at paragraph Sec.  170.314(b)(2)). We believe this addition 
poses limited additional burden since EHR technology would just need to 
be able to make available for download any transition of care/referral 
summaries created as a result of a transition of care (so if a patient 
has had multiple hospitalizations during the EHR reporting period and 
been transitioned out of the hospital, the EHR technology would need to 
be capable of making available both inpatient summaries and transition 
of care/referral summaries that were created as a result of the 
transitions).
    We received comments on our proposal to adopt the Consolidated CDA 
where it was proposed for other certification criteria. In drafting 
this comment and response we considered those comments and included 
them in the comment summary above. Accordingly, our response here to 
the proposal to adopt the Consolidated CDA is not repeated in the other 
certification criteria where its adoption was also proposed.
    Comments. A couple of commenters stated that we mentioned in the 
Proposed Rule that there needs to be a confidentiality type included in 
the CCDA. They noted that it was unclear what that requirement meant in 
the use case where a patient downloads their information. They 
requested further clarification and guidance on the indication of this 
element within this certification criterion.
    Response. As we noted in the Proposed Rule, 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). In this 
context, we believe that ``N'' would likely be the default value.
    Comments. Several commenters stated that we should require EHR 
technology to include the capability to do a ``Blue Button'' download. 
Other commenters opposed this idea because all that would be downloaded 
would be a text file. They contended that such an outcome would be a 
step backwards from requiring the Consolidated CDA.
    Response. The view, download, and transmit capabilities required by 
this certification criterion are fully aligned with the Blue Button 
goals of empowering patients to be partners in their health care 
through access to and use of personal health information. We expect the 
Blue Button vision to evolve and expand to encompass a variety of 
technical solutions beyond the traditional download of a text file, 
including view, download, and transmit capabilities. Along those lines, 
we strongly encourage every EHR technology developer to associate this 
certification criterion's download capability related to a human 
readable file with the increasingly popular ``Blue Button'' phrase and 
logo. To be clear, we also require for certification that EHR 
technology be capable of enabling a patient or their authorized 
representative to be able to download a file formatted according to the 
Consolidated CDA.
    Comments. Commenters noted that the Consolidated CDA had been 
updated since the Proposed Rule was published and urged us to adopt the 
most recent version in the final rule.
    Response. We agree with commenters and have adopted the HL7 
Implementation Guide for CDA[supreg] Release 2: IHE Health Story 
Consolidation, Draft Standard for Trial Use (DSTU) Release 1.1 (US 
Realm) Draft Standard for Trial Use, July 2012. This version of the 
Consolidated CDA constitutes the most recent balloted version--a 
process which has been underway since the Proposed Rule was published. 
It corrects errors in the prior version, and was modified to more fully 
and closely support capturing the MU data that CMS requires for EPs, 
EHs, and CAHs to meet certain MU objectives and measures related to 
transitions of care, clinical summaries, and providing patients with 
the ability to view, download and transmit their health information. As 
noted by HL7 in its documentation, this DSTU version of the standard 
will be open for comment for 24 months and following this evaluation 
period, it will be revised as necessary and then submitted to ANSI for 
approval as an American National Standard (normative standard). 
Further, HL7 specifies that implementation of this DSTU version will be 
valid during the ANSI approval process and ``for up to six months after 
publication'' of the normative standard. Given the state at which this 
DSTU version of the standard is and the fact that this version alone is 
subject to the evaluation period, we believe that it is the best 
possible choice for this final rule, especially in place of the draft 
version we referenced in the Proposed Rule.
    Comments. A few commenters stated that this certification criterion 
did not expressly include privacy and security requirements. They 
suggested that we should require EHR technology to be able to ensure 
that a patient's online experience is secure. They recommended that we 
specify requirements for authentication such as OAuth as well as a 
specific level of assurance (NIST level 3). They also recommended that 
we require EHR technology to be certified for its ability to establish 
a secure channel for view and download.
    Response. We are convinced by commenters that it is important and 
necessary to add a more explicit requirement for security in this 
certification criterion. In that respect, we have revised our proposed 
criterion to accept commenters' suggestions in part. As suggested, we 
have included a requirement that EHR technology must be able to 
establish a secure channel through which a patient can access the 
capabilities to view, download, and transmit their electronic health 
information. We agree that certification can provide some assurance 
that EHR technology can properly establish for a secure channel through 
which health information can be viewed, downloaded, and transmitted. 
This secure channel requirement mirrors that portion of the secure 
messaging certification criterion. Thus, it is possible for an EHR 
technology to be certified to both this certification criterion and the 
secure messaging certification criterion, depending on how it is 
designed.
    We continue to decline to change the certification criterion in 
response to commenters' recommendations that we prescribe a particular 
form or ``level of assurance'' for authentication. It is not that we 
disagree that some form of authentication will be necessary when EHR 
technology certified to this certification criterion is implemented. 
Rather, as some comments suggest, there is significant innovation 
taking place with respect to authentication. Thus, we believe that 
requiring a particular form in this certification criterion would be 
overly prescriptive and have little practical effect on the eventual 
authentication approach EPs, EHs, or CAHs implement.

[[Page 54182]]

    Comment. A commenter noted that the Consolidated CDA stated that 
vital signs are an optional section which may be included in CCDs, 
while the Proposed Rule stated that this section is required. They 
contended that if such discrepancies are allowed to persist, EHR 
technology developers will inevitably make mistakes on what they choose 
to include and marked heterogeneity will persist.
    Response. We seek to make clear for this commenter (and this 
response is generally applicable to any instance where we have adopted 
certification criteria that reference standards and required data) that 
this final rule and its requirements take precedence (i.e., override) 
any ``optional'' requirements in a standard or implementation 
specification if they are deemed required as part of a certification 
criterion. For example, if sections or certain data in an 
implementation guide are designated ``optional,'' but a certification 
criterion requires compliance with such sections or data, EHR 
technology must be designed to comply or accommodate those sections or 
data in order to meet the certification criterion.
Transmit
    Comments. Many commenters asked that we clarify why a SOAP-based 
transport standard was not proposed as part of this certification 
criterion when it was for the transitions of care certification 
criterion. Commenters contended that this was an inconsistency and 
asked that ONC and CMS reconcile the two. They also referenced CMS's 
proposed rule and preamble that stated that transmission could occur 
via any means of electronic transmission according to any transport 
standards for the view, download, and transmit to a third party 
objective. Other commenters stated that other transport standards 
should be permitted for use, such as those for query and response. 
Last, commenters asked questions about workflow and how transmission 
should be implemented so that a patient's information can be 
transmitted to a 3rd party.
    Response. There was no inconsistency between the ONC and CMS 
proposed rules. The proposed transport standard(s) for each 
certification criterion were purposefully chosen and proposed to 
specify the capabilities EHR technology would need to include in order 
to demonstrate compliance with each certification criterion. Commenters 
have confused two very distinct concepts: (1) What is required for EHR 
technology to demonstrate compliance with a certification criterion; 
and (2) how EHR technology, once certified, must be used to demonstrate 
meaningful use. We seek to make this distinction clear to prevent any 
further confusion.
    The certification criteria adopted in this final rule apply to EHR 
technology and only EHR technology. The final rule specifies the 
technical capabilities that EHR technology must include and other 
requirements that must be met in order for EHR technology to be 
certified. This rule does not specify in any way how EHR technology, 
once certified, must be used in order to achieve meaningful use. That 
policy is expressed in CMS's rules and is identified for each MU 
objective and associated measure. In this scenario with the view, 
download, and transmit to a 3rd party and transitions of care 
objectives and measures, CMS purposefully proposed two different 
policies.
    For view, download, and transmit to a 3rd party CMS expressly 
indicated that other transport standards beyond those required for 
certification could be used by EPs, EHs, and CAHs. However, for 
transitions of care, CMS expressly indicated that only the transport 
standards permitted for certification would count in an EP, EH, or 
CAH's numerator for the measure. Thus, for the transitions of care 
certification criterion, we included the SOAP-based transport standard 
as an option for certification to expand the potential approaches EPs, 
EHs, and CAHs could take to also include electronically transmitted 
transition of care/referral summaries according to that standard in the 
transitions of care measure's numerator. In other words, had we not 
proposed the SOAP-based transport standard as an option in the 
transitions of care certification criterion, EPs, EHs, and CAHs would 
have been limited to meeting that MU objective and measure through only 
the use of the Applicability Statement for Secure Health Transport 
specification (the primary Direct Project specification). In the case 
of view, download, and transmit to a 3rd party, we proposed the 
adoption of the Applicability Statement for Secure Health Transport 
specification because we believe it is necessary for EHR technology 
certified to this certification criterion to include at least the 
capability to use that transport standard, even though CMS permits EPs, 
EHs, and CAHs to use alternative transport standards. We note that 
consistent with the changes we have made in the transitions of care 
certification criterion, we are requiring certification only to the 
Applicability Statement for Secure Health Transport standard and not 
also the second Direct Project specification (XDR and XDM for Direct 
Messaging). Additionally, the Applicability Statement for Secure Health 
Transport has been updated to Version 1.1 (July 10, 2012). We have 
adopted this version of the specification because it improves EHR 
technology implementation and the testing of the specification's 
requirements and, consequently, makes the version of the specification 
we proposed outdated. Version 1.1 was established by the stakeholder 
community during this final rule's drafting. Version 1.1 of the 
specification provides clearer instruction for implementation through 
additional guidance on how certificates can be discovered in a 
consistent manner. If we had adopted the proposed version, EHR 
technology developers would have encountered difficulty with 
consistently implementing EHR technology to the specification and 
testing of the specification's requirements would have been hindered. 
Last, we do not believe that it is within this rule's scope to 
specifically describe a particular workflow or how transmission should 
be implemented. Many commenters raised certification concerns related 
to the Applicability Statement for Secure Health Transport 
specification when they commented on the transitions of care 
certification criterion. Thus, we do not repeat those concerns and our 
responses and instead address them once in the transitions of care 
certification criteria comment and responses.
    Comments. Commenters stated that the reference to the Applicability 
Statement for Secure Health Transport specification was the right 
direction to take for provider-to-provider (or clinician or 
organization) transmissions but that it was unclear whether this 
specification was also appropriate for a patient-focused certification 
criterion. They requested that the ``transmit to third party'' via this 
standard should be clarified to express that the intended transmission 
was to another provider or a personal health record (PHR). They 
contended that the standard should not be required for transmission to 
other individuals who are not providers (e.g., friends, relatives, 
etc.). Additionally, they stated that in this latter case the word 
``transmission'' may not necessarily mean it was transmitted 
electronically (or in a manner that can be tracked) because the 
information could be loaded onto a USB drive, DVD, or even printed in 
being transferred to a new physician by a patient.
    Response. We expect that if the Applicability Statement for Secure 
Health Transport specification is used to complete a transmission to a 
3rd party that the receiving party would be

[[Page 54183]]

another health care-oriented entity, like a PHR company the patient is 
using and that it would not be a patient's friend or relative. 
Furthermore, for the purposes of this certification criterion, the more 
generic interpretation of the word ``transmission'' stated by the 
commenter would not be within the scope of this certification criterion 
as we do not consider transferring data to electronic media like a USB 
drive or DVD to constitute an ``electronic transmission'' for the 
purposes of certification.
    Comments. Some commenters agreed that patients should be permitted 
to transmit their health information to another entity, but stated that 
we should not burden the health care provider to be the party that 
transmits this information on their behalf. They contended that health 
care providers should not be a relaying entity on behalf of their 
patients.
    Response. For clarity, we have revised this certification criterion 
to state that EHR technology must provide patients (and their 
authorized representatives) with an online means to view, download, and 
transmit to a 3rd party the data required by the certification 
criterion. In this sense, it is the EHR technology that an EP, EH, or 
CAH has that is performing this function, not the EP, EH, or CAH. Thus, 
we believe that the burden identified by commenters is misplaced.
    Comments. A commenter recommended that we consider requiring the 
transmittal of a provider's National Provider Identification (NPI) 
number when an NPI has been assigned. They reasoned that including the 
NPI would allow receiving systems to more easily cross reference 
provider information that might already exist in the receiving system 
database.
    Response. We decline to change the certification criterion based on 
this suggestion. We note that the US Realm Header for the Consolidated 
CDA does require that at least one ``author'' be identified and further 
that the ``assigned Author'' shall contain at least one ``id'' which 
the standard recommends with a ``should'' as being the NPI.
Download and Transmission of Images
    Comments. Commenters generally supported the principle of providing 
patients with access to images, however, only a few commenters outright 
supported our proposal. One commenter that supported our proposal 
suggested that images also be included in the ``view'' part of the 
certification criterion and stated that diagnostic quality is 
unnecessary for patient viewing. They encouraged us not to suggest a 
standard for image viewing by patients. Another commenter asked if we 
intended for images to be available for viewing in a basic distribution 
viewer or if small images embedded in the report or images viewed 
without tools in a browser would meet the certification criterion's 
intent. They suggested that we require a basic distribution viewer to 
be part of the ``view'' portion of the certification criterion. One 
commenter stated that if we did not specify DICOM as a requirement for 
certification, that we should at least make available the option for 
EHR technology to be certified to the standard for the purposes of 
image downloads.
    Several commenters strongly opposed or requested that we remove the 
capability and proposed standard. These commenters stated that 
including images for download and transmission by a patient would be a 
challenging requirement. They also contended that this capability 
exceeded the requirements in CMS's proposed rule. Additionally, these 
commenters stated that images are typically stored in a system separate 
from EHR technology (i.e., a PACS system) and that this requirement 
would add significant complexity and burden to the certification 
criterion. They followed this comment by stating that the industry norm 
is for CDs with pertinent images to be given to a patient with an image 
reader that allows for viewing. A similar point was made by other 
commenters who stated that requiring DICOM for the transmission would 
force the recipient of the images to have a DICOM compliant viewer and 
to import the images into that viewer before they could be viewed. Many 
commenters noted that an image's average file size would present 
significant storage and cost challenges for online downloading and 
transmitting. The JPEG file format was recommended as a potential 
solution since patients did not necessarily need diagnostic quality 
images.
    Response. In consideration of the comments received and the 
complexity and potential burden identified by commenters, we have 
decided to remove the requirement for images to be available for 
download and transmission to a third party. We believe further industry 
dialogue needs to occur with respect to images and our policy goal of 
enabling patients to have ready, online access to their images. We 
expect to include this topic on the HITSC's agenda for the next edition 
of EHR certification criteria we would adopt through rulemaking and 
intend to propose a requirement for online image access in a future 
edition of this certification criterion.
    Comments. We received the following additional comments that did 
not fall within the general scope of the comments summarized above. One 
commenter proposed that a secure hyperlink to the image, supplied by 
the radiologist and conveyed via the Direct Project standard, become 
the method of making DICOM images and radiology reports available to 
patients and ordering providers. A commenter suggested that for image 
download a patient should be able to identify the location of a study 
to be referred to another provider as acceptable for the certification 
criterion. Last, a separate commenter asked that we specify for the 
``download and transmit'' requirements, the IHE Portable Data for 
Imaging (PDI) profile.
    Response. We appreciate commenters' feedback. Given our decision to 
remove the requirement for image downloading and transmission to a 
third party, we will take this feedback into consideration for our 
future work with the HITSC as well as our next rulemaking.
Patient Accessible Log
    Comments. Several commenters opposed this proposed specific 
capability in the certification criterion because they thought it was a 
means to implement the HHS Office for Civil Rights (OCR) HIPAA Privacy 
Rule accounting of disclosures proposal (76 FR 31426) for patients to 
be able to get an ``access report.''
    Response. These commenters are mistaken. This aspect of the 
certification criterion was not intended to implement the Department's 
proposal to give individuals a right to receive an ``access report.'' 
However, given this confusion, we have decided to change the paragraph 
heading for this part of the certification criterion to state 
``activity history log.'' The purpose of this paragraph in the 
certification criterion is to simply require that EHR technology be 
able to monitor when a patient or their authorized representative(s) 
views, downloads, or transmits their health information to a third 
party. Those are the actions to which this paragraph referred in the 
proposed certification criterion. Put simply, this activity log is 
meant to assist a patient track the history of their actions or those 
of their authorized representatives.
    Comments. Many commenters stated that the Proposed Rule did not 
clarify or offer a statement regarding how far back in time a patient 
accessible log should be able to retrieve log event data. They also 
sought clarification on who a user could be and what would be 
sufficient data to include in the log.

[[Page 54184]]

    Response. The time period for which the activity history log should 
be available is a policy determination that should be made by the 
organization who implements EHR technology certified to this 
certification criterion. Thus, we decline to specify a particular 
retention period in this certification criterion. What is necessary for 
certification is that an EHR technology can demonstrate that it can 
properly create such a log. As noted in our response directly above, we 
intend for ``user'' in this context to be the patient and any 
authorized representative(s) to whom they have provided access to view, 
download, and/or transmit their health information to a third party.
    Comments. Several commenters supported the ``credit'' we sought to 
provide if EHR technology leveraged its general auditing capabilities 
to fulfill the requirements specified by this capability. However, they 
asked that we clarify that our proposal did not imply electronic or 
immediate access to the general audit trail via either the Complete EHR 
or portal. Some commenters explicitly stated that they would oppose any 
requirement for immediate electronic access to the general EHR 
technology audit log online. They also requested confirmation that the 
access does not need to be provided online. Rather, they suggested that 
EHR technology could produce a printed document for a patient to 
review, upon request. They also requested clarification that the log 
could provide summary information, (e.g., that a patient summary was 
sent to a third party) and not be required to list all the information 
contained in the summary document that was transmitted.
    Response. This certification criterion does not require an EP, EH, 
or CAH's general EHR technology security audit log to be made available 
to patients online. However, the activity history log must be available 
online and readily accessible. We hope that the past two responses have 
helped clarify many scope-oriented points for these commenters because 
it was our proposal and our continued belief that the activity history 
log should be online and readily available for a patient (or their 
authorized representative) to review ``on demand.'' Given the 
clarifications and the limited burden we believe is associated with 
tracking when a ``view,'' ``download,'' and ``transmission'' has 
occurred and by whom and when, we do not believe that this should be a 
significantly challenging capability to include. Accordingly, we have 
finalized this portion of the proposed certification criterion by 
changing the paragraph heading and making clear that the actions that 
need to be tracked are simply ``views,'' ``downloads,'' and/or 
``transmissions'' that have occurred and by whom and when.
    Comments. Commenters expressed support for our proposed 
``synchronized clocks'' standard and our proposal to permit either 
NTPv3 or NTPv4. They noted that the use of these synchronization 
technologies is very common and supported in all major operating 
systems. Along those lines, they stated that it was unclear why this 
would be a requirement for EHR technology certification because it is 
unlikely that the EHR technology itself will be directly implementing 
this type of synchronization and more likely that it will be relying on 
the lower level systems' clock functionality (e.g., the operating 
system within which the EHR technology runs). One commenter stated that 
it is important to avoid a requirement that would make the operating 
system (that provides the standard clock) part of what is needed for 
EHR certification as this would impose artificial limits on what 
operating systems can be used without certifying multiple permutations. 
This commenter contended that because the ability to use an operating 
system clock is common, it was unnecessary for this standard to be 
required for certification. They requested that if we did include it 
for certification, that we acknowledge that: the operating system keeps 
the time, the EHR technology gets the system clock, and that a 
particular operating system is not required to be part of EHR 
technology for certification.
    Response. We thank commenters for supporting this proposal. As we 
indicated in the Proposed Rule, our responses here also apply to 
comments received on other certification criteria that also referenced 
the ``synchronized clocks'' standard. We acknowledged in the Proposed 
Rule and here again our understanding and expectation that EHR 
technology will likely obtain a system time from a system clock that 
has been synchronized following the NTPv3 or NTPv4 standard. We 
expressly worded the standard to acknowledge this likely scenario by 
stating ``[t]he date and time recorded utilize a system clock that has 
been synchronized * * *.'' (Emphasis added.) We do not intend for this 
specific capability to create a binding relationship between EHR 
technology and a particular operating system. For certification, EHR 
technology must be able to demonstrate, as the standard states, that it 
can utilize a system clock that has been synchronized following NTPv3 
or NTPv4. Accordingly, we have retained this proposal and finalized it 
for the certification criteria to which it pertains.
     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.314(g)(2), we proposed to adopt a 2014 
Edition EHR certification criterion that would apply solely to EHR 
Modules that include capabilities to support an MU objective with a 
percentage-based measure. We stated that the focus of this new 
certification criterion would be on the EHR Module's capability to 
automatically record the numerator for those measures. We proposed to 
adopt this new certification criterion at Sec.  170.314(g)(1).
    We clarified that, while a Complete EHR would need to be capable of 
meeting the ``automated measure calculation'' which requires the 
capability to accurately calculate MU denominators, we did 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. We did, however, 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.
    Comments. Many commenters supported our proposal in concept and as 
written. Some of these commenters stated that this certification 
criterion was a welcome improvement and would ease the reporting burden 
for small providers and hospitals. Other commenters contended that our 
proposal had a logical flaw and requested that we clarify how an EHR 
Module would be able to accurately capture the appropriate numerator 
because the numerator is often a subset of the patients or actions that 
qualify to be in the denominator. As such, some commenters echoed what 
we had stated in the Proposed Rule (that it may be difficult for an EHR 
Module to know the true denominator) and expressed concern that this 
requirement could not be implemented without additional burden. Some 
commenters suggested that we remove this certification criterion 
altogether, while others requested that modify this certification

[[Page 54185]]

criterion to fix the logic challenge and asked that we clarify the 
expected testing and certification process for this certification 
criterion if it were to remain in the final rule.
    Response. We appreciate commenters support for this certification 
criterion. We have adopted a revised version of the certification 
criterion. We acknowledge that this certification criterion requires 
additional explanation and clarity related to our intended outcome. We 
agree with commenters that, unless clarified, this proposed 
certification criterion could pose logic problems for EHR technology 
developers and, correspondingly, that the conditions we expected to be 
met in our proposal would be difficult to achieve. Especially in 
circumstances where the EHR Module has no basis on which to determine 
the patients or actions that would be part of the denominator specified 
for a given MU measure.
    In response, we offer the following clarifications. We proposed 
this certification criterion in order to make it easier and more 
efficient for EPs, EHs, and CAHs who pursue an EHR Module approach to 
meet the CEHRT definition to determine their EHR MU measure 
percentages. As we acknowledged in the Proposed Rule, this 
certification criterion could only help so much because of the 
potential that an EHR Module would not necessarily have the ability to 
determine the appropriate denominator for a given measure. We agree 
with commenters that this limitation can extend to the numerator in 
cases where the numerator is a subset of the denominator. To address 
this logic issue, we have modified the certification criterion to focus 
on what we believe an EHR Module will be able to determine without any 
specific dependency on an MU measure's denominator. This certification 
criterion now focuses on an EHR Module's ability to correctly identify 
the patients or actions that would meet the numerator's requirements 
generally and without the denominator's limitations applied. Thus, we 
clarify that for the purposes of testing and certification, an EHR 
Module would not need to be able to precisely identify the MU numerator 
after all of the denominator's filtering had been applied. Instead, it 
will need to be able to identify the patients or actions that would 
generally meet the numerator and the minimum denominator criteria that 
would be necessary to match the information provided by the EHR Module 
to the full denominator criteria from other data sources. We have 
revised the certification criterion to make this point clear. 
Additionally, to reflect that in order for this information to be 
useful to an EP, EH, or CAH to determine the true numerator, the EHR 
Module (similar to the automated measure calculation certification 
criterion) would need to be able to produce a file/report that 
identifies those patients or actions that would meet the numerator. We 
provide the following examples to illustrate the capability that an EHR 
Module would need to include. We note that depending on the 
certification criterion or criteria to which the EHR Module is 
presented for certification that the potential approach to determine 
the overall number of patients or actions may be different. We intend 
to provide guidance as necessary with more examples for each MU 
objective and measure that this certification criterion would need to 
support. Ultimately, we believe this information will also help EHR 
technology developers better understand the numerators and denominators 
associated with the MU measures.

     Example 1: An EHR Module presented for 
certification that includes CPOE and seeks to be certified to 
certification criterion at 170.314(a)(1). To meet the automated 
numerator calculation certification criterion, the EHR Module would 
need to be able to correctly identify a simple number, the number of 
orders created using the EHR Module. An EP, EH, or CAH would then 
need to take this output from the EHR Module and compare it to the 
total number of orders made (inclusive of those where the EHR Module 
was not used).
     Example 2: An EHR Module presented for 
certification that includes e-prescribing capabilities and seeks to 
be certified to certification criteria at 170.314(a)(10) (drug 
formulary check) and 170.314(b)(3) (electronic prescribing). To meet 
the automated numerator calculation certification criterion, the EHR 
Module would need to be able to correctly identify a slightly more 
complicated number, number of permissible prescriptions for which 
the existence of a drug formulary was queried and a prescription 
subsequently electronically transmitted. Given this overall number, 
an EP, EH, or CAH would then need to take this output from the EHR 
Module and compare it to the total number of permissible 
prescriptions written for drugs requiring a prescription, which 
would need to be obtained from somewhere else.
     Example 3: An EHR Module presented for 
certification that includes the ability to record patient 
demographics and seeks to be certified to certification criterion at 
170.314(a)(3). To meet the automated numerator calculation 
certification criterion, the EHR Module would need to be able to 
correctly generate a list of patients that identifies each and every 
patient in the EHR Module who have all of the demographic elements 
recorded as structured data (or that the patient declined or not 
collectable under state or local law). An EP, EH, or CAH would then 
need to take this output from the EHR Module and compare it to the 
data source they would use to identify unique patients seen during 
the EHR reporting period (the denominator limitations for this MU 
measure).
     Example 4: An EHR Module presented for 
certification that includes the ability to provide patients (and 
their authorized representatives) with an online means to view, 
download, and transmit to a 3rd party electronic health information 
and seeks to be certified to certification criterion at 
170.314(e)(1). To meet the automated numerator calculation 
certification criterion, the EHR Module would need to be able to 
correctly generate a slightly different list of patients that 
identifies each and every patient in the EHR Module who have taken 
one of those three actions. An EP, EH, or CAH would then need to 
take this output from the EHR Module and compare it to the data 
source they would use to identify unique patients seen during the 
EHR reporting period (the denominator limitations for this MU 
measure).

    As illustrated by these examples, many MU measures share similar 
denominators. Thus, we expect that once an EP, EH, or CAH identifies 
the source they will use as the basis for a denominator (i.e., number 
of unique patients seen during the EHR reporting period) that it should 
be relatively straight forward given the information an EHR Module 
would be required to produce for the EP, EH, or CAH to determine the 
true numerator.
    Comment. A commenter acknowledged that this proposed certification 
criterion would be applicable to EHR Modules and requested that we 
clarify whether this policy applied to EHR technology developers who 
follow an incremental EHR Module certification approach on the way to 
designing EHR technology that could satisfy the Complete EHR 
definition. They stated that if our answer was yes, that it would be 
overwork for such EHR technology developers and requested an exemption 
for this scenario.
    Response. This requirement is broadly applicable to every EHR 
Module presented for certification and we decline to provide any 
exemption. While an EHR technology developer may pursue this approach, 
we do not believe that it would be prudent to offer such an exemption 
because it is equally likely that the EHR technology developer could 
decide to stop before it could seek certification for enough EHR 
Modules that would cumulatively satisfy the Complete EHR definition. If 
that were to occur, EPs, EHs, and CAHs that had adopted these EHR 
Modules would be at a disadvantage. Given the revised CEHRT definition 
and the fact that EPs, EHs, and CAHs do not

[[Page 54186]]

necessarily need to have the same quantity of EHR technology certified 
to the 2014 Edition EHR certification criteria as they would have under 
our prior CEHRT definition, we believe that this could reduce the 
potential burden assumed by this commenter and, depending on its 
customer base, reduce the need to seek Complete EHR certification in 
the first place.
    Comment. A commenter asked that we confirm whether it would be 
permissible for an EHR Module presented for testing and certification 
get certified to the automated measure calculation certification 
criterion instead of the automated numerator certification criterion.
    Response. Yes, this approach is permitted and encouraged in 
instances where EHR technology developers have developed a sufficiently 
large EHR Module such that it could meet the automated measure 
calculation certification criterion for all of the capabilities it 
includes and that correlate to percentage-based MU measures. We clarify 
that this approach would satisfy the EHR Module certification 
requirement specified in Sec.  170.550(f)(1). Where possible, we 
encourage EHR technology developers to follow this approach in order to 
provide EPs, EHs, and CAHs with the most efficient means of identifying 
the numerators and denominators for an MU EHR reporting period. We also 
note that it is also permitted and encouraged for EHR technology 
developer to seek certification for a combination of automated 
numerator and measure calculation certification criteria where the EHR 
Module may have a reliable and known denominator that can be used as 
the basis for calculating certain percentage-based MU measures.
     Non-Percentage-Based Measure Use Report (not adopted)

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
N/A
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
N/A
------------------------------------------------------------------------

    In the Proposed Rule, we proposed to adopt a certification 
criterion at Sec.  170.314(g)(3) that would have applied to any EHR 
technology presented for certification that included capabilities 
associated with MU objectives and measures that were not percentage 
based. We noted that 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. Further, we 
stated that in consultation with CMS, we believed that EPs, EHs, and 
CAHs would benefit from this type of capability being required as a 
condition of certification and that such a capability could provide 
EPs, EHs, and CAHs with valuable evidence in the event of a MU audit. 
We proposed 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.
--------------------------------------------------------------------------------------------------------------------------------------------------------

    Comments. Several commenters opposed this proposed certification 
criterion and suggested that it was unduly burdensome. Many indicated 
that we had significantly underestimated the complexity involved with 
accurately capturing this information. Commenters cited several 
examples and noted that this proposed certification criterion required 
different analysis far beyond just ``yes/no'' settings for many of the 
certification criteria listed above. They noted that the use of eMAR is 
not an on/off step and questioned how we expected enabling ``ongoing 
submission'' for public health reporting to be recorded. Commenters 
stated that requiring this certification criterion would take away from 
the EHR technology development time necessary to address the 
certification criteria that were necessary to support MU objectives and 
associated measures. Last, commenters indicated that the fact the 
capability was active should be sufficient for MU, as well as 
attestation, because there is not a separate requirement in MU 
associated with the frequency each particular capability is used.
    Response. In response to commenters' feedback we have not included 
this proposed certification criterion in the final rule. We acknowledge 
some of the complexities raised by commenters and that additional 
aspects as well as specificity would be necessary for a more effective 
certification criterion. However, we continue to believe in the spirit 
and direction of this certification criterion so that ultimately EPs, 
EHs, and CAHs could be in a position to electronically report even the 
non-percentage based MU objectives and measures. In light of the 
questions raised by stakeholders we intend to engage the HITSC and 
HITPC on how to best reach this goal.
     Safety-Enhanced Design and Quality Management System

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

Safety-enhanced Design
    In the Proposed Rule, we provided an overview of the ISO definition 
of 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.'' \9\ We 
outlined that EHR technology certification could introduce some 
improvements in usability, which we believed would enhance both the 
safety and efficiency of CEHRT. In the Proposed Rule, we also reviewed 
the November 2011 Institute of Medicine (IOM) 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.'' The IOM 
recommended that ``[t]he Secretary of HHS should specify the quality 
and risk management process

[[Page 54187]]

requirements that health IT vendors must adopt, with a particular focus 
on human factors, safety culture, and usability.''
---------------------------------------------------------------------------

    \9\ ISO 9241-11.
---------------------------------------------------------------------------

    We proposed that a significant first step toward improving overall 
usability would be to focus on the process of user-centered design 
(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,'' \10\ we 
expressed that it would be inappropriate for ONC to seek to measure EHR 
technology in this way. Recognizing that EHR technologies exist and are 
in use today, we prioritized eight certification criteria \11\ and 
associated capabilities to which the proposed certification criterion 
would require UCD to have been applied. We chose these eight because we 
believed they pose the greatest risk for patient harm and therefore the 
greatest opportunity for error prevention. As proposed, this approach 
was designed to limit this certification criterion's potential burden.
---------------------------------------------------------------------------

    \10\ https://www.nist.gov/healthcare/usability.
    \11\ 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)(16) 
(Electronic medication administration record); Sec.  170.314(b)(3) 
(Electronic prescribing); and Sec.  170.314(b)(4) (Clinical 
information reconciliation).
---------------------------------------------------------------------------

    We proposed that 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. We proposed that it 
would be best to enable EHR technology developers to choose their UCD 
approach and not to prescribe 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. We acknowledged and expected that EHR technology developers 
who have already followed UCD in previous development efforts for the 
identified certification criteria would be performing a retrospective 
analysis. However, if UCD had not been previously applied to 
capabilities associated with the certification criteria, the EHR 
technology would ultimately need to have such UCD processes applied 
before it would be able to be certified. We proposed that testing \12\ 
to this certification criterion would entail EHR technology developers 
documenting that their UCD incorporates all of the data elements 
defined in the Customized Common Industry Format Template for EHR 
Usability Testing (NISTIR 7742). We noted that with respect to 
demonstrating compliance with this certification criterion that this 
information would need to be available to an ONC-ACB for review, but 
that the form and format for how the data would be presented for 
testing would not necessarily need to be according to NISTIR 7742 
(i.e., an EHR technology developer could capture information specified 
in NISTIR 7742 without having to use the template). Finally, we 
indicated that this documentation would become a component of the 
publicly available testing results on which a certification is based.
---------------------------------------------------------------------------

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

    Comments. A majority of commenters strongly urged ONC to include 
this proposed certification criterion in the final rule. We note, 
however, that of all of the proposed certification criteria, this one 
appeared to be the most polarizing. Provider organizations, hospitals, 
and consumer advocates supported its inclusion in certification and 
most (but not all) EHR technology developers expressed some form of 
opposition--with concern about the public availability of user-centered 
design testing results.
    Many commenters expressed support for our proposal adding, in many 
cases, arguments about the critically important role that usability 
plays in the aspect of the safety and reliability of EHR systems, 
noting that if usability is not carefully analyzed it can cause design 
induced errors. Other commenters were clear that they felt the results 
of UCD and quality systems testing should not be made publicly 
available, and that doing so would open the door for EHR developers' 
intellectual property to be misappropriated. Some commenters were 
simply opposed to this criterion, citing an unnecessary burden on the 
industry.
    Many commenters supported our proposal to not specify certain 
standards or requirements for UCD processes. Commenters also agreed 
with our proposal to require that the documentation for how UCD was 
applied in the software development process would be publicly 
available. These commenters noted that this transparency would foster 
EHR technology developer competition to make UCD a competitive 
advantage, thus spurring innovation, improving clinician adoption, and 
enhancing patient safety. These commenters also suggested that the 
proposed certification criterion would not compromise innovation nor 
require the release of intellectual property. Most commenters agreed 
with the decision not to include NISTIR 7804, and asked for 
clarification regarding the proposed CIF template (NISTIR 7742) and 
which specific elements are required. One commenter asked for 
clarification of the testing methods, and whether self-attestation 
would be sufficient for consumers and purchasers of Certified EHR 
Technology.
    Many commenters quoted an AHRQ report as follows, ``Usability 
studies are often difficult to generalize or transfer across settings, 
in part because medication management health IT (MMIT) effectiveness is 
linked strongly to the culture, institutional leadership, and other 
situation specific factors. Therefore, applicability of findings 
related to usability is problematic in MMIT applications.'' \13\ Along 
those lines, they suggested a slight alternative to what we proposed by 
suggesting that EHR technology developers attest to and document their 
current processes for incorporating UCD practices into their software 
design, as well as any UCD approaches used for currently certified 
products, but not be required to have the findings published publicly. 
These commenters also suggested that summative testing, as used in the 
referenced NIST template, can catch the most basic usability errors, 
but is unlikely to have a significant impact on patient safety relative 
to cost. These commenters advised that we broaden the criteria to 
include other, formative UCD techniques instead of just summative 
testing as valid for certification. Finally, these same commenters 
expressed strong objections to the requirement for retrospective UCD 
analysis and application. Many commenters were supportive of our 
identification of several applicable UCD standards, but requested some 
changes including the replacement of ISO 13407 with ISO 9241-11, and 
the addition of ISO/IEC 62366 and ISO 9241-210.
---------------------------------------------------------------------------

    \13\ https://www.ahrq.gov/clinic/epcsums/medmgtsum.htm.
---------------------------------------------------------------------------

    One commenter asked for clarification on what was meant by 
``retrospective analysis'' and whether it means summative testing or 
simply asserting and providing evidence that a UCD process was 
followed. Many commenters agreed that EHR technology developers should 
be able to choose the UCD approach that best supports their design 
principles and products, adding that this would help minimize the 
burden of testing and will raise

[[Page 54188]]

awareness on the importance of usability from end-users. One commenter 
noted that usability is a quality of interactive software that can be 
objectively defined and evaluated. This commenter suggested that we 
adopt the following standards for EHR technology certification: 
Standard 13407, UCD/NISTIR 7804, ISO Standard 25062, and Common 
Industry Format for Summative Usability Tests NISTIR 7742. This 
commenter noted that some EHR technology developers have published 
objections that the scope of this type of testing would be unrealistic 
for an EHR that would be used in a wide variety of conditions, but also 
noted that by limiting the scope to eight high priority certification 
criteria identified in the Proposed Rule mitigates any such concerns.
    One commenter expressed disagreement with the component of the 
proposal that would require all testing elements to be made public and 
strongly argued that this part be removed from the final rule. This 
commenter stated that this equates to the public disclosure of trade 
secrets and other proprietary information may force EHR technology 
developers that are publicly-traded to violate their obligations to 
shareholders, as defined in regulations enforced by the Securities and 
Exchange Commission (SEC) that govern the disclosure of both financial 
and non-financial information.
    One commenter expressed the opinion that UCD is subjective, while 
several others request clarification regarding this proposal and ask if 
this certification criterion will allow each EHR technology developer 
to implement the UCD approach which best suits their development 
methodology.
    Response. We thank commenters for the detailed and thoughtful 
responses. We agree with those commenters who saw this proposed 
certification criterion as an important way to improve both EHR 
technology design and safety. Therefore, we have adopted this 
certification criterion as proposed. We disagree with commenters who 
argued that this certification criterion represented an unnecessary 
burden. However, in response to those comments, we have issued several 
clarifications to better explain the certification criterion's intent 
and the requirements that are necessary to demonstrate compliance with 
this certification criterion.
    To demonstrate compliance with this certification criterion, UCD 
must have been applied to each capability of an EHR technology that is 
associated with the eight certification criteria named in this 
certification criterion. We clarify that the application of UCD is 
limited to only those eight certification criteria specified in this 
certification criterion and for which certification is sought. For 
example, if an EHR Module is presented for certification and includes 
capabilities to which this certification criterion would apply, but for 
which certification is not sought, then those other capabilities for 
which certification is not sought would not have to have had UCD 
applied because they would be beyond the scope of the EHR Module's 
certification.
    We clarify that what we meant by ``retrospective analysis'' is that 
an EHR technology developer would not necessarily have to initiate new 
UCD analysis to meet this certification criterion if they had already 
completed UCD for the capability in the past. In other words, if an EHR 
technology had never applied UCD to the capabilities to which this 
certification criterion applies then UCD would need to be completed 
before that EHR technology could be certified. However, if UCD had been 
applied to an EHR technology for the capabilities relevant to this 
certification criterion, UCD would not need to be redone and an EHR 
technology developer could provide the required information specified 
by NISTIR 7742 that reflects the UCD that they had previously 
completed. We make this clarification to acknowledge that many EHR 
technologies are designed to follow standard UCD processes and we did 
not intend to disregard that prior work. We also believe this 
clarification will help assuage commenters' concerns about the 
potential burden posed by this certification criterion.
    The method(s) that could be employed for UCD (e.g., ISO 9241-11, 
ISO 13407, ISO 16982, and NISTIR 7741) and that were listed in the 
Proposed Rule are examples of resources that EHR technology developers 
may choose to review in order to select a UCD. We agree that ISO/IEC 
62366 and ISO 9241-210 are also acceptable alternatives. Any UCD 
process selected by an EHR technology developer is appropriate, and it 
need not be listed in the examples we provided in order to be 
acceptable. We do, however, strongly advise EHR technology developers 
to select an industry standard process because compliance with this 
certification criterion requires submission of the name, description, 
and citation (URL and/or publication citation) of the process that was 
selected. In the event that an EHR technology developer selects a UCD 
process that is not an industry standard (i.e., not developed by a 
voluntary consensus standards organization (VCSO)), but is based on one 
or more industry standard processes, the developer may name the 
process(es) and provide an outline of the process in addition to a 
short description. Submission of the information specified in the 
NISTIR 7742 template will need to be submitted for each and every one 
of the applicable eight certification criteria specified in this 
certification criterion and for which certification is sought. This 
information will become part of the EHR technology's test report that 
is required to be made publicly available.
    The following information/sections in NISTIR 7742 are required for 
submission:

     Name and version of the product
     Date and location of the test
     Test environment
     Description of the intended users
     Total number of participants
     Description of participants: their experience and 
demographic characteristics
     Description of the user tasks that were tested
     List of the specific metrics captured during the testing 
for effectiveness, efficiency and satisfaction
     Data scoring
     Results of the test and data analysis
     Major test findings
     Identified area(s) of improvement(s)

    There are illustrative tables on pages 11 and 20 of the NIST 7742 
document that may not need to be populated, depending on the tasks 
tested. We clarify that all of the sections specified above must to be 
completed, including ``major findings'' and ``areas for improvement.'' 
We note that EHR technology developers can perform many iterations of 
summative user testing. Thus, the submission that is ultimately 
provided for testing and certification may be the expression of a final 
iteration in which few areas for improvement would be identified. We do 
not expect EHR technology developers to include trade secrets or 
proprietary information in these reports. We disagree that UCD is 
subjective, and have offered several examples of industry standard UCD 
processes above. Regarding one commenter's concern that the publication 
of usability testing may violate SEC regulations regarding public 
disclosure, this commenter provided no additional detail as to why this 
would pose a conflict with SEC regulations, nor did it cite a 
particular SEC regulatory provision that they believed was in conflict 
with the proposed certification criterion. We are unaware of any 
provision that would result in EHR technology developers violating any 
SEC regulations.

[[Page 54189]]

    Comments. One commenter expressed support for the certification 
criterion, but disagreed with the assumption that user interface (UI) 
validation testing must be performed by end-users. This commenter's 
experience was that UI validation tests performed by internal design 
experts are more effective than the same testing performed by end-
users. This commenter reported that engineering a UI to the needs of a 
user who is encountering that interface for the very first time, 
invariably results in an interface designed to accommodate the novice, 
at the expense of denying power and efficiency to the same user who 
will quickly gain familiarity with a well designed interface.
    Response. The NISTIR 7742 includes several sections: Executive 
Summary, Introduction, Method, Results, and Appendices. In each of 
these sections, there are required data elements--and some of these 
elements call for the expression of the number of study participants, 
their level of experience with EHR technology, and other pertinent 
details. Regarding comments about the participants of usability 
testing, many UCD processes incorporate involvement of end-users in 
formative and summative testing. The cohort of users who are selected 
as participants will of course vary with the product and its intended 
users.
    Comments. One commenter supported this criterion, but expressed 
concern that testing in a lab setting would be insufficient and would 
need to be augmented by field testing as well, advocating for 
provisional certification for this certification criterion until it had 
been implemented and tested in the field.
    Many commenters expressed support for this criterion, stating 
agreement that EHR technology developers should conduct usability 
testing. One commenter suggested that usability testing be conducted 
and mandated by a third party such as a Sharp C grant recipient, and 
strongly recommending standardization of EHR data output to make the 
transfer of data more seamless, less administratively burdensome, and 
less costly.
    One commenter suggested that ensuring usability is the key to 
successful physician adoption of EHRs, yet expressed concern that our 
proposals as drafted gave no consideration as to the clinician 
decision-making process or practice workflow.
    One commenter expressed concern that the adoption of a particular 
methodology does not guarantee that software will improve. Other 
commenters suggested that the testers would need to be selected who are 
professionals already familiar with more than one EHR technology and 
are in the same specialty as the target market of the EHR technology 
developer.
    One commenter contended that the NISTIR 7804 would be appropriate, 
and advocated for its inclusion as a certification requirement.
    Many commenters suggested that we enhance our usability testing 
requirements beyond what was described in our proposed rule such as: 
(1) Requiring the collection of data based on an EHR user (physician) 
satisfaction survey that can be included in the attestation phase of 
the MU program; (2) collecting and disseminating survey results on 
usability experiences based on practice size, specialty type, and 
geographic location, and incorporation of this feedback into future 
certification processes; (3) including usability and patient safety 
criteria into the certification process as discussed in the IOM report; 
(4) promoting innovation in EHR technology design that not only 
addresses patient safety and usability, but can be more seamlessly 
integrated into smaller practices that do not have the luxury of 
resources to completely redesign the way they work to accommodate the 
EHR; (5) seeking industry feedback--including physician feedback--on 
what constitutes an appropriate level of risk as it relates to patient 
safety; and (6) applying the principles in the NISTIR 7804 to the 
entire EHR certification process.
    Response. We thank these commenters for their thorough and 
thoughtful feedback. Although the implementation of suggestions 1 
through 5 may provide a better understanding of EHR usability today and 
chart a path toward improved usability in the future, they fall outside 
the scope of this certification criterion. We have not included NISTIR 
7804 in the 2014 Edition EHR certification criteria, but may consider 
it for future editions of certification criteria. We do believe that 
UCD will--by definition--consider the clinical decision-making process 
and disagree with the commenter that it does not. Finally, we agree 
that both formative and summative testing are valuable, and we agree 
that testing in a lab setting and testing in the field are also 
important. This certification criterion is a first step toward formal 
usability testing becoming part of the culture of EHR technology 
development. We therefore clarify that, at a minimum, only lab-based 
summative testing is necessary to be performed in order to demonstrate 
compliance with this certification criterion. Nothing precludes field-
testing and formative testing from also being performed and we 
encourage EHR technology developers to do so.
Quality Management System
    In the Proposed Rule we noted that the IOM had also recommended 
that we ``[establish] quality management principles and processes in 
health IT.'' We stated that, working with other Federal agencies, we 
intended to publish a quality management document that would be 
customized for the EHR technology development lifecycle and express 
similar principles to those included in ISO 9001, IEC 62304, ISO 13485, 
ISO 9001, and 21 CFR part 820. We anticipated that this 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 EHR 
technology development We stated that we understood that some EHR 
technology developers already have processes like these in place, but 
did not believe, especially in light of the IOM recommendation, that 
the EHR technology industry as a whole consistently follows such 
processes. We indicated our expectation to publish the quality 
management document around the same time as the Proposed Rule would be 
available for public comment. We indicated that we were considering 
including an additional certification criterion in the final rule that 
would require an EHR technology developer to document how their EHR 
technology development processes either aligned with, or deviated from, 
the quality management principles and processes that would be expressed 
in the document. We emphasized 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 the principles and processes 
specified in the document (and where they do not, what alternative 
processes they use, if any). We stated our expectation 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.
    We explained that we were considering adopting this additional 
certification criterion as part of the 2014 Edition EHR certification 
criteria for

[[Page 54190]]

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 an immediate significant burden on EHR technology 
developers. We requested public comment on this additional 
certification criterion and the feasibility of requiring EHR technology 
developers to document their current processes.
    Comments. Most comments supported our proposal to adopt a 
certification criterion for quality management practices. Several 
commenters expressed concern that the quality management systems 
document referenced in our proposal was not available for review during 
the public comment period as we had proposed. Many commenters expressed 
concern that public availability of the documentation produced for this 
certification criterion might reveal proprietary and confidential 
software information.
    Other commenters expressed support for having quality management 
systems in place and the general approach proposed of describing the 
nature of each EHR technology developer's quality processes. These 
commenters also expressed that the proposal is preferable to a specific 
requirement for EHR technology developers to adopt a particular quality 
management system.
    One commenter observed that due to the recent FDA rule for Medical 
Device Data Systems (MDDS), they are actively implementing these 
quality principles across their enterprise development projects and 
believe that the use of quality management systems will help to: 
Improve traceability of clinician requirements to EHR system features, 
keeping requirements at the forefront; improve consistency of 
development and commissioning activities and thus increase the ability 
to predict when EHR system updates will become available to the 
clinicians; and lower the overall cost of quality by minimizing a whole 
range of failure costs. This commenter also noted additional advantages 
of quality management systems including: The opportunity to clarify 
roles and responsibilities in the development organization allowing 
more precise definition of scope, schedule, and resources needed to 
develop its clinical systems; improved visibility into the development 
project progress, providing greater predictability of when resources 
assigned to projects will be available for other strategic priorities; 
highlight needs for communication and safety/risk discussions on 
critical issues; and creation of ownership of quality at all levels of 
the organization.
    One commenter did not support the requirement to provide a gap 
analysis as part of the certification, due to the fact that this 
commenter's EHR technology is comprised of many disparate self-
developed modules spanning multiple years of development and use, 
multiple teams and multiple technologies where consistent processes 
were not performed. This commenter also expressed concern that the 
publication of this analysis is irrelevant to organizations that 
develop their EHR technology and do not sell it to others. Finally, 
this commenter stated that they are already familiar with quality 
management systems and are actively tightening up their software 
development lifecycle processes and other QMS related activities to 
become compliant with the FDA MDDS rule.
    One commenter stated that they are actively implementing a quality 
management system, and that disclosing where [they] are in this process 
to an agency that currently does not have jurisdiction in this area 
would add no value. Several commenters expressed that they would not 
support any requirement that did not align with international standards 
such as ISO-62304, ISO-14971, ISO-13485, or with FDA's quality system 
regulation in 21 CFR part 820.
    Some commenters noted that the work required to meet this 
requirement will be very time consuming and costly to provide a formal 
assessment on each of the legacy development processes that have been 
employed, and that the review for certification should focus on new 
development rather than historical development. They stated that 
certification bodies could perform a spot check quality management 
systems audit on new processes instead of requiring EHR technology 
developers to retrospectively define old processes. The commenter 
expressed that this would be far less burdensome and would allow EHR 
technology developers to appropriately focus efforts on future 
development efforts, not past work.
    Several commenters agreed that it is important for EHR technology 
developers to follow rigorous quality management systems and welcomed 
the inclusion of a quality management systems certification criterion. 
These commenters suggested that optimal quality management systems for 
EHR technology should expressly permit modern ``Agile'' development 
processes, as Agile processes can efficiently yield higher quality 
software than traditional methods. A commenter also noted that some of 
the existing quality management regimes referenced (ISO 9001, IEC 
62304, ISO 13485, and 21 CFR part 820) predate the development of Agile 
software development methodologies and were written assuming an old-
fashioned stage-gate ``waterfall'' software development process. The 
commenter stated, for example, that while medical device \14\ 
manufacturers have begun to successfully embrace Agile there has been 
some confusion about whether Agile processes are even allowed under 21 
CFR part 820. This commenter argued that a modern quality management 
system for EHR technology should expressly permit Agile software 
development, and should set high-level requirements for software 
development process and work-product, without unnecessarily 
constraining the order in which particular process steps are followed. 
Comments indicated that a quality management system certification 
criterion should cover the processes associated with custom software 
development. They stated that unlike other medical devices covered by 
the quality management systems mentioned (IEC 62304, ISO 13485, and 21 
CFR part 820), EHR technology implementations often involve a 
substantial amount of custom, site-specific, software (including 
templates, interfaces, and custom code).
---------------------------------------------------------------------------

    \14\ We note for readers that we interpreted the term ``medical 
device'' used in this comment summary by commenters to refer to 
those devices that fall under the meaning of `device' in section 
201(h) of the Federal Food, Drug, and Cosmetic Act (FD&C Act), 21 
U.S.C. 321(h). Generally, speaking when the term ``device'' is used 
throughout this rule it is used in the general sense of the word and 
not limited to the meaning assigned to ``device'' in section 201(h) 
of the FD&C Act.
---------------------------------------------------------------------------

    One commenter expressed agreement with IOM that it would be useful 
to establish ``quality management principles and processes in health 
IT.'' This commenter supported the proposed gradual introduction of a 
generic quality management system certification criterion with key 
requirements called out. They suggested that a gradual introduction 
would support those EHR technology developers who already have quality

[[Page 54191]]

management systems in place without requiring them to rip and replace 
to conform to a ``standard'' quality management system that may not 
offer any significant improvement over what they already have in place. 
These commenters also stated that it is important for EHR technology 
developers who are currently following one of the existing ISO or FDA 
standard processes not be disadvantaged by new MU equivalencies.
    Response. We appreciate the very thorough and thoughtful comments 
on our proposal to adopt a quality management system (QMS) oriented 
certification criterion. We share the sentiments expressed by 
commenters that selecting and implementing an optimal quality 
management system (QMS) for EHR technology development can be complex. 
We agree that existing standards may not explicitly state support for 
agile development methodologies and that such methods may be part of an 
optimal QMS. We appreciate the detailed comments that offered guidance 
regarding the optimal components of an ideal QMS for EHR technology and 
we agree with many of these suggestions. Because we were unable to 
publish the quality management document referenced in the Proposed Rule 
we recognize that there was an insufficient opportunity to comment on 
this document and have not included an explicit requirement to use this 
document.
    We agree with the many commenters who described the advantages of 
an incremental implementation of QMS requirements for EHR technology. 
Additionally, we support the position of the commenters that stated 
this requirement should strive not to burden EHR technology developers 
with the task of documenting previous development processes. We 
disagree with the commenter who believed that this requirement was 
beyond our authority. The Secretary has the statutory authority to 
adopt standards, implementation specifications, and certification 
criteria for HIT and the National Coordinator has the statutory 
authority to establish a certification program for the certification of 
HIT to certification criteria adopted by the Secretary. Additionally, 
we disagree with the commenter with internally developed EHR technology 
that objected to our proposed gap analysis because we believe that the 
purchasers of EHR technology are not the only stakeholders who would 
take interest in the transparency provided by the submission of this 
information. Patients, employees, business partners, and shareholders 
of such organizations would be other such interested parties.
    In consideration of comments received for and against this 
proposal, we have decided to adopt a certification criterion in this 
final rule at Sec.  170.314(g)(4) that will generally focus on QMS and, 
as suggested by many commenters, is meant to be a first step that can 
be built on in an incremental fashion. All EHR technology certified to 
the 2014 Edition EHR certification criteria would need to be certified 
to this certification criterion, and we have taken steps to ensure that 
EHR Modules are certified to this certification criterion by revising 
Sec.  170.550 as discussed in more detail under section IV.C.2 of this 
preamble.
    We have adopted a certification criterion that accounts for the 
fact that we did not publish the quality management document as we had 
proposed. The certification criterion we have adopted is more general 
and provides more flexibility. The certification criterion expresses 
that for each capability an EHR technology includes and for which that 
capability's certification is sought, the use of a QMS in the 
development, testing, implementation and maintenance of that capability 
must be identified. Unlike our proposal, any QMS may be used to meet 
this certification criterion and even an indication that no QMS was 
used for particular capabilities for which certification is requested 
is permitted. The commenter who stated that they are implementing the 
FDA's Quality System (QS) regulations (for example, under the MDDS 
rule) would--by definition--be meeting this certification criterion so 
long as they cite their compliance with FDA's QS regulations for 
certification. Given this flexibility, we cannot foresee any reason why 
this certification criterion cannot be satisfied nor do we believe that 
it will be a significant burden to indicate the QMS used (or not used) 
in the development of capabilities for which certification is sought.
    We understand that some EHR technology developers have several 
teams who work on different functional components of EHR technology. In 
the case where the whole development organization uses the same QMS (or 
not at all) across all teams, then this certification criterion may be 
met with one report. Where there is variability across teams, the EHR 
technology developer will need to indicate the individual QMS' followed 
for the applicable certification criteria for which the EHR technology 
is submitted for certification.
    We encourage EHR technology developers to choose an established 
QMS, but developers are not required to do so, and may use either a 
modified version of an established QMS, or an entirely ``home grown'' 
QMS. We also clarify that we have no expectation that there will be 
detailed documentation of historical QMS or their absence. As specified 
above, we believe that the documentation of the current status of QMS 
in an EHR technology development organization is sufficient.
EHR Technology Safety Reporting
    We also considered 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,\15\ including the 
``Device or Medical/Surgical Supply, including HIT v1.1a.'' We 
requested 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.
---------------------------------------------------------------------------

    \15\ https://www.pso.ahrq.gov/formats/commonfmt.htm
---------------------------------------------------------------------------

    Comments. Many commenters requested that ONC not adopt a 
certification criterion at this time, but take the opportunity to study 
the role of EHRs in patient safety incident reporting in order to 
determine if something more reflective of EHR technology's role in such 
reporting as a future certification criterion would be appropriate. 
Many of these commenters also stated that there is insufficient 
experience with the AHRQ Common Format--especially in the ambulatory 
domain, and that extension of the Common Format would be necessary for 
it to be of value. Other commenters expressed additional concerns about 
the maturity of the Common Format, and the ability of EHR technology to 
generate the appropriate file format, and whether there would be any 
near-term value to such reports without more experience with adverse 
event reporting from EHR technology.
    Response. We agree with these concerns and have not adopted a 
certification criterion for reporting patient safety events according 
to the Common Formats in the 2014 Edition EHR certification criteria.
     Data Portability

[[Page 54192]]



------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
N/A
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
------------------------------------------------------------------------
Sec.   170.314(b)(7) (Data portability).
------------------------------------------------------------------------

    In the Proposed Rule we sought public comment on whether we should 
adopt a certification criterion to focus on the portability of data 
stored within CEHRT. We recited the scenario where a provider might 
seek to change EHR technology (and EHR technology developers). We 
stated that in such a scenario providers 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. We noted that 
in the absence of this capability, providers could be ``locked-in'' to 
their current EHR technology, which could ultimately impede innovation. 
With our belief that data portability is a key aspect of the EHR 
technology market that requires maturity, we sought public comment on 
specific questions that could inform our decision on whether to adopt a 
certification criterion focused on data portability. We asked: (1) 
Whether EHR technology is capable of electronically providing a 
sufficient amount of a patient's health history using export summaries 
formatted according to the Consolidated CDA for the scenario described 
above; (2) whether all of the data in a provider's EHR 1 is 
necessary to migrate over to EHR 2 in the event the provider 
wants to switch (We noted that potential effect of medical record 
retention laws, but sought to determine whether the loss of some data 
would be tolerable and if so, which data.); (3) considering the 
standards that have been adopted and proposed for adoption in the 
Proposed Rule, what additional standards and guidance would be 
necessary to meet market needs for data portability, including the 
portability of administrative data such as Medicare and Medicaid 
eligibility and claims; (4) whether a specific set of patient data 
could be used as a foundation for an incremental approach to improve 
data portability for the situation described above as well as other 
situations; and (5) whether the concept of a capability to batch export 
a single patient's records (or a provider's entire patient population) 
poses unintended consequences from a security perspective and what 
factors should be considered to mitigate any potential abuse of this 
capability if it existed.
    Comments. Commenters strongly supported our efforts to improve data 
portability, including in the specific provider situation we outlined 
in the Proposed Rule. Many commenters generally noted that medical 
record retention laws, as well as those governing fraud and abuse 
investigations, largely determine the amount and type of information 
that must be retained, and therefore, needs to be portable. Commenters 
also noted that there may be other reasons for retaining longitudinal 
information on patient care, such as clinical trial participation, post 
approval study requirements and other clinical reasons.
    Many commenters stated that some data loss is inevitable, with some 
commenters noting this was due to variations in clinical content and 
data schema(s) between EHR systems. Commenters gave varying responses 
on what specific data would be important to migrate to a new EHR. Some 
commenters stated the decision would be situational, best left to the 
provider, or, as previously noted, based on medical records retention 
laws and requirements. Commenters stated that demographics, problems, 
medications, medication allergies, allergies, immunizations, vital 
signs, lab results, and encounter notes would fall into the category of 
``not tolerable'' to lose in transfer. For all ``other'' data, 
commenters stated that it would be sufficient for the data to be 
accessible in a human readable form through, but not necessarily stored 
within, the EHR. A few commenters also stated that documentation 
metadata should be readily available for all databases. Some commenters 
stated that the loss of data at a granular, visit-oriented level would 
be tolerable. Other commenters stated that because administrative data 
is normally stored in practice management systems--and not in EHRs--it 
would not need to be transferred from one of these systems to another.
    One commenter suggested an incremental approach starting with 
requiring indexed and searchable documents including visit notes, 
letters, and reports. The commenter noted that this might require 
manual addition or automated generation of metadata and might need to 
include only documents generated after a given date for complete header 
information. The commenter noted that subsets of the patient's record 
(records of children must include immunizations and growth data) could 
be effective, but the commenter emphasized that the summary must be 
focused on the patient's lifetime data and not the most recent clinical 
events. Over time, the commenter stated that external standards for 
data portability would govern the internal structure of data within an 
EHR so that data can be exported and imported without data loss. The 
commenter stated that a good example is retention of laboratory results 
in LOINC[supreg] codes after import so that they can be exported in the 
future and used in a different EHR to identify data elements needed for 
clinical decision support or clinical quality measures.
    Commenters stated that the Consolidated CDA would not be capable of 
sufficiently capturing all patient information that would be needed. 
Commenters stated that the Consolidated CDA is designed to be a summary 
and would not capture longitudinal patient information, administrative 
billing data, or other necessary data (e.g., trend analysis, 
operational data, and master file data). A few commenters noted that 
the CDA does not support the inclusion of information on whether 
meaningful use measures were applicable to or addressed for patients. 
Other commenters stated that CDA document types may not be the most 
efficient means to migrate data from one EHR to another. These 
commenters further stated that it is critical that such migration 
happens as quickly as possible. Therefore, the commenters contended 
that other data transfer mechanisms would be better suited for that 
purpose, particularly when large data volumes are in play (e.g., large 
multi-provider entities migrations).
    A commenter stated that one possible solution would be to require 
EHR technology developers to tag key data elements that would typically 
be moved in an EHR transition with standardized XML. EHR technology 
developers would also need to be able to receive and process data feeds 
with this standardized XML, storing it in their native tables.
    A few commenters stated that batch migrations are one of the more 
typical migration methods used when a provider moves from one EHR to 
another. Some commenters stated that batch exports of a patient's 
record poses serious security risks, while other commenters stated that 
current safeguards exist. These commenters pointed to the use of 
business associate agreements, encryption, and the use other internal 
controls to mitigate any security concerns.
    Response. We thank commenters for the depth and breadth of their 
responses to our questions and proposals. In consideration of comments 
received, we have adopted a certification criterion for data 
portability. As discussed later in this final rule, we have also 
included this certification criterion as part of the Base EHR 
definition in order to ensure

[[Page 54193]]

that all EPs, EHs, and CAHs, have this capability as part of the EHR 
technology they use to meet the CEHRT definition. While we recognize 
that no ``silver bullet'' exists with respect to data portability, we 
strongly believe that more attention must be paid to this market 
challenge and that with the interests of EPs, EHs, and CAHs in mind, 
small steps can be taken to improve the data portability between EHR 
technologies. We intend for this certification criterion to be a 
starting point and have framed it in such a way as to leverage 
capabilities that will already be included in an EP, EH, and CAH's 
CEHRT.
    The certification criterion leverages and requires the same 
capabilities specified in the ``transitions of care--create and 
transmit transition of care/referral summaries'' certification 
criterion at Sec.  170.314(b)(2)(i). The only difference between the 
capability specified in the data portability certification criterion 
and the capability specified in the transitions of care certification 
criterion is that the data portability certification criterion 
expressly limits the scope of the data to the most current clinical 
information about each patient for which an export summary is created. 
For the purposes of certification and for all of the patients on which 
an EP's, EH's, or CAH's CEHRT maintains data, the EHR technology must 
enable a user to electronically create a set of export summaries for 
all patients in EHR technology formatted according to the Consolidated 
CDA that includes each patient's most recent clinical information. 
While this is the minimum capability required for certification, we 
encourage EHR technology developers to include patients' longitudinal 
information for laboratory test results, immunizations, and procedures, 
and intend to consider including this broader requirement in the next 
edition of this certification criterion. We believe this initial 
capability provides a strong starting point for the fluid transition 
from one EHR technology to another. Primarily, we anticipate that this 
capability will be enable transitions to be more efficient by reducing 
the need for EPs, EHs, and CAHs to manually re-enter all of their 
patients' recent data into a new EHR system.
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).
------------------------------------------------------------------------

    We proposed the 2014 Edition EHR certification criterion for secure 
messaging (at Sec.  170.314(e)(3)) to support the MU objective and 
measure recommended by the HITPC and proposed by CMS. We agreed with 
the direction provided by both HITSC recommendations and merged the two 
into a refined proposed certification criterion. We also proposed to 
include in the certification criterion a baseline standard in terms of 
the encryption and hashing algorithms that would need to be used to 
implement secure messaging. More specifically, we proposed that only 
those identified in FIPS 140-2 Annex A be permitted to be used to meet 
this criterion and proposed 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 referenced several standards and implementations 
specifications that EHR technology developers could use to implement 
various secure messaging approaches, including IETF RFC 2246 (TLS 1.0), 
SMTP/SMIME, 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.
    Comments. Several commenters conveyed that the certification and 
testing process would need to accommodate the range of messaging 
mechanisms permitted by CMS, while being certified within the proposed 
standards. One commenter asked if there were approved modes of 
electronic messaging and whether secured and encrypted email would be a 
method. Another stated that use of a secure messaging capability from 
within a portal application should be an acceptable method. One 
commenter recommended that we equally support the standards and 
specifications developed as part of the NwHIN Exchange with the intent 
to support the broadest possible adoption of health information 
exchange capabilities. Other commenters generally requested that we 
provide some examples of common access mechanisms and acceptable 
security protocols. Another commenter suggested that we consider 
particular transport methods be certified similar to the certification 
criteria discussed in the Proposed Rule that referenced the Direct 
specifications and other acceptable transport methods. One commenter 
stressed the importance of adequate privacy and security, but urged ONC 
to take a reasonable approach and not make the use of secure electronic 
messaging to communicate with patients unduly burdensome. One commenter 
stated that functionality such as a patient portal would be handled 
through normal browser HTTPS functionality and, therefore, should be 
easily managed through a visual inspection and should not require 
additional verification. One commenter supported secure messaging in 
general, but did not support secure email as the only secure messaging 
methodology. The commenter indicated that they currently send patients 
an unsecure email prompt that they have a message and that upon receipt 
the patient can securely log-in to their patient portal using an SSL-
protected session to retrieve the message and send new ones.
    Response. We share commenters' sentiment that this certification 
criterion needs to permit/accommodate a range of possible innovative 
options. To that end, we intentionally proposed this certification 
criterion to only specify the particular baseline security and 
functional capabilities we believed were necessary to require for 
certification. So long as the method included with EHR technology 
presented for certification can meet these baseline requirements it 
would be able to meet this certification criterion. Thus, secure email, 
a secure portal, even some type of mobile application could all be 
examples for secure messaging methods that could potentially meet this 
certification criterion. Along those lines, we decline to specify or 
restrict certification in this case to a particular transport standard 
because, again, we intend to permit a wide range of different secure 
messaging solutions, that will likely use different approaches and 
transport standards.
    In consideration of these comments and the ones responded to below, 
we are finalizing this certification criterion as proposed with one 
exception. The only modification we have made is to explicitly note as 
we already have in the view, download, and transmit to a 3rd party 
certification criterion that it could be the patient or their 
authorized representative that engages in secure messaging.
    Comment. A commenter stated that patients must be able to directly 
communicate with health professionals via patient portals and OAuth.
    Response. We decline to incorporate this suggestion into the 
certification criterion because it would be

[[Page 54194]]

unnecessarily limiting. Our response, however, is not meant to preclude 
this type of functionality from being used to satisfy this 
certification criterion.
    Comment. A commenter questioned how the capability to receive a 
secure message from a patient would be tested and what we intended to 
be certified. They asked whether it was a provider application that 
would be used to send and receive secure messages or a consumer 
application to do the same; or both. Further, the commenter stated that 
an EHR technology developer presenting EHR technology for certification 
may not have a patient portal or PHR technology from which to 
demonstrate the sending of a message to the EHR technology and that 
testing using a public email service is likely not to meet the FIPS 
140-2 Annex A requirement for encryption. The commenter also indicated 
that the certification criterion presumes the EHR technology developer 
has a technology to support the consumer and that the EHR technology 
developer must have both abilities (send and receive) within its span 
of control to be able to present technology for certification. 
Ultimately, the commenter suggested that either the provider 
requirement to send a message be removed or that this be split into two 
criteria. They reasoned that from a measurement perspective, only the 
``receive'' from the provider perspective is required by the Stage 2 
proposed rule for the associated objective, and the measurement 
numerator is based on a consumer perspective and the vendor having 
access to event data that may only be available in a portal or similar 
consumer application. As an alternative to certifying send and receive 
as two distinct criterion (or even as a single criterion to help EHR 
technology developers who may only automate provider or consumer 
messaging), the commenter suggested that ONC consider working with NIST 
to provide a test harness for vendors to certify with to prove messages 
are successfully sent and received.
    Response. The EHR technology that enables secure messages to be 
exchanged is what would be required to be tested and certified. Thus, 
whatever would be necessary for a patient to communicate with an EP 
(and vice versa) would need to be demonstrated for testing and 
certification. We do not believe that separating the capability for 
communication by send and receive would add any significant value or 
provide any additional benefit because it is the capability as a whole 
(to send and receive secure messages) that needs to be demonstrated for 
testing and certification in order for EPs to have assurance that EHR 
technology can enable bidirectional communication. We thank the 
commenter for the recommendation to work with NIST to develop testing 
methods that ensure messages can be successfully sent and received. We 
will take this recommendation under consideration in discussions with 
NIST and when approving a test procedure for this certification 
criterion. Finally, we note that to keep the final rule as current as 
possible at the time of publication, we have referenced the May 30, 
2012 version of Annex A. The May 30, 2012 version replaces the version 
we adopted in the S&CC July 2010 final rule and is the only readily 
accessible version available. Further, NIST has included additional 
reference guidance for the AES standard as well as updated references 
to other FIPS publications that have been updated, such as changing the 
reference to FIPS 180-3 to FIPS 180-4.
    Comments. One commenter supported the proposed certification 
criterion but requested clarification on the reference to the standard, 
which they noted is a collection of many standards in several 
categories. They asked if we could clarify which specific parts of FIPS 
Annex A are applicable to secure messaging. In addition, the commenter 
asked how the additional guidance we provided in the preamble related 
to the standard we proposed to adopt. They requested clarification as 
to whether we intended to say ``FIPS 140-2 Annex A plus TLS 1.0 and 
SMTP/SMIME and * * *.'' or whether something else was intended.
    Response. As noted in the standard proposed just the encryption and 
hashing algorithms are in scope. Random number generator standards 
would not necessarily be within scope. The other guidance we referenced 
in the Proposed Rule is just that. It was not intended to be part of 
the standard as questioned by the commenter.
    Comment. One commenter recommended that we discourage the use of or 
remove the allowance for 3DES as the encryption algorithm is on track 
to be deprecated by NIST in the near future.
    Response. We agree, please see our response to similar comments in 
the ``end-user device encryption'' certification criterion.
    Comment. One commenter recommended that we investigate evolving 
secure email and other supporting technologies to protect and verify 
transactions that include personally identifiable health information. 
They noted that current Direct Project guidance requires the use of 
organizational PKI certificates for which the FBCA does not include a 
profile in its certificate policy. They stated that certificates cited 
in the Direct project documentation also suggest that the encryption, 
digital signature and non-repudiation bits all be turned on and that 
this requirement is an unacceptable practice under the terms of RFC 
3647. They concluded by recommending that federally approved NIST LOA 
3, 2-factor credentials for patients to authenticate to secure email 
and or/or portals should be used to fulfill this requirement.
    Response. At this point, we decline to include such a specific 
requirement as part of this certification criterion. As the industry 
gains more experience with different secure messaging approaches, we 
will consider whether additional specificity such as this is necessary.
    Comments. A few commenters stated that because CMS' proposed rule 
left it to the provider to determine the ``relevance'' of information, 
the capability to assess or document relevance should not be in the 
automated measure calculation certification criterion nor be part of 
this certification criterion.
    Response. Certification does not address the relevance of the 
information that is part of a secure message. Please see CMS's 
discussion related to secure messaging in the Stage 2 final rule 
published elsewhere in this issue of the Federal Register.
     Cancer Case Information; and Transmission to Cancer 
Registries

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Capability to identify and report cancer cases to a State cancer
 registry, except where prohibited, and in accordance with applicable
 law and practice.
------------------------------------------------------------------------
2014 Edition EHR Certification Criteria
Sec.   170.314(f)(5) (Optional--ambulatory setting only--cancer case
 information).
Sec.   170.314(f)(6) (Optional--ambulatory setting only--transmission to
 cancer registries).
------------------------------------------------------------------------

    We proposed to adopt two new 2014 Edition EHR certification 
criteria to support a new proposed MU objective and measure for 
reporting cancer cases to cancer registries. One certification 
criterion focused on the capability to electronically record, change, 
and access cancer care information (data capture) and the other 
certification criterion focused on the capability to electronically 
create cancer case information for electronic transmission in 
accordance with specified standards. Following consultation with the 
Centers for Disease Control and Prevention (CDC), we proposed to adopt 
HL7 CDA,

[[Page 54195]]

Release 2 as the content exchange standard. Additionally, we proposed 
to adopt the Implementation Guide for Healthcare Provider Reporting to 
Central Cancer Registries, Draft, February 2012. We stated in the 
Proposed Rule that the CDC would consider comments received on the 
Proposed Rule in finalizing the guide. We also stated that if the CDC 
finalized the guide, we would consider adopting the final version of 
the guide in this final rule with consideration of public comment 
received on the appropriateness of the guide for certification. Last, 
we proposed to adopt SNOMED CT[supreg] International Release January 
2012 and LOINC[supreg] version 2.38 as applicable vocabulary standards.
    Comments. Commenters expressed strong support for the proposed 
certification criteria. Many of the commenters that supported the 
certification criteria stated that they believed this requirement would 
increase cancer reporting and improve it in various ways, including 
improving the timeliness, efficiency, completeness, and quality of the 
data reported as well as reducing the reporting burden on ambulatory 
providers.
    While many commenters supported the proposed certification 
criteria, many also requested that the certification criteria be 
designated ``optional'' for Complete EHR certification. The commenters 
requesting that the certification criteria be designated optional 
claimed that the certification criteria would only be relevant to a 
small number of providers who report to cancer registries. Further, 
they contended that the capability would be inappropriate for inclusion 
in EHR technologies that are not focused on meeting the needs of EPs 
who will report to cancer registries, since some of the cancer case 
information data utilizes extensive cancer-specific, specialized fields 
and vocabularies (e.g., NAACCR data standards) that are not typically 
captured in EHRs beyond those specifically marketed as oncology 
specialty products. A couple of commenters noted that few, if any, EHR 
technology developers provide this functionality, and most applications 
that are used for this purpose are not likely to meet the standard 
cited in the Proposed Rule. A few other commenters stated that this 
requirement is burdensome and should not be required.
    Response. We appreciate the support expressed by commenters. We 
also agree with commenters that it is appropriate to designate these 
certification criteria as optional. By designating the certification 
criteria as optional, EHR technology would not need to be certified to 
these certification criteria in order to satisfy the Complete EHR 
definition. The optional designation will permit EHR technology 
developers that support EPs intending to report on the associated MU 
menu objective and measure to still get certified to these 
certification criteria, but will alleviate the requirement that all 
Complete EHRs be certified to these certification criteria. Designating 
these certification criteria as optional will mitigate any perceived 
unnecessary costs and burden mentioned by commenters. To clarify for MU 
purposes, if an EP seeks to meet the associated MU objective and 
measure, they will need EHR technology certified to these certification 
criteria, including the adopted standards and implementation guide, in 
order to have EHR technology that meets the CEHRT definition.
    Comments. Many commenters supported the adoption of the proposed 
HL7 CDA, Release 2 and Implementation Guide for Healthcare Provider 
Reporting to Central Cancer Registries, Draft, February 2012 for 
registry reporting, stating that they had widespread support from the 
CDC and cancer registry community. A few of these commenters 
specifically stated that public health central cancer registries have 
been operational for many years and the cancer registry community has 
been preparing for the transition to CDA for some time. Commenters 
noted that cancer reporting in most jurisdictions requires industry and 
occupation information and stated that EHR technology certification to 
support cancer reporting by EPs would facilitate their compliance with 
applicable law and improve the quality and completeness of cancer 
reporting. One commenter recommended that cancer laboratory results 
reporting be included in addition to cancer case reporting.
    Many commenters also pointed out that the implementation guide was 
still in draft format and suggested that it should be finalized before 
being adopted. A few commenters contended that it was premature to 
adopt the proposed standard and implementation guide as a basis for 
certification, stating that the standard was not in widespread use for 
reporting cancer events to registries from EHRs. One commenter stated 
that the proposed implementation guide is not harmonized with the 
Consolidated CDA guide and that harmonization should be completed 
before we adopted the implementation guide. A commenter stated that 
centralized cancer registries receive batch reports containing large 
numbers of cases and that the cancer-related information required by 
the cancer registries is dense in its level of detail. Therefore, the 
commenter was concerned that the CDA standard may not provide the 
necessary content framework or the processing efficiency necessary to 
transmit and receive complex, bulk data.
    A commenter requested that the minimum data elements required for 
the transmission of cancer case information be explicitly and clearly 
stated. Another commenter noted concerns that the implementation guide 
has requirements for structured data capture for social history that 
may not reflect widespread current practice and, thus, represents a 
change in practice for EPs. Other commenters stated that there is 
potential for confusion in coding ``occupation'' and ``industry'' 
because there is a discrepancy between description and language in the 
implementation guide and the descriptions for the corresponding 
LOINC[supreg] codes. A commenter suggested that the implementation 
guide needed values for cancer staging variables that allow for ``not 
staged'' or ``unknown.'' The commenter stated that for every required 
field (R), the value sets should be double checked to make sure that 
there is a ``none'' or ``unknown'' option or the EP's EHR will not have 
a value all the time.
    Response. The implementation guide was jointly developed by the CDC 
and the North American Association of Central Cancer Registries 
(NAACCR). It is based on many years of harmonized cancer registry 
reporting across the country. The finalized implementation guide, 
Implementation Guide for Ambulatory Healthcare Provider Reporting to 
Central Cancer Registries, Release 1, August 2012, reflects the 
comments received on the draft and clarifies ambiguities such as 
minimum data elements required and vocabularies for occupation, stage, 
and other data elements where none/unknown should be an option. In 
particular, the use of HL7 null flavor is better described such that it 
may be used where appropriate to indicate lack of information and 
clarifications were made to the use case scenarios in response to 
questions about workflow and triggers. While this implementation guide 
is based on the CDA, the guide was revised in some aspects to harmonize 
it with the recently developed Consolidated CDA. The implementation 
guide was revised to take advantage of the document format used by the 
Consolidated CDA, including the formatting of the data element tables 
and conformance statements. The new consensus conformance verbs used in 
Consolidated

[[Page 54196]]

CDA (i.e., shall, should, may, and should not) were also adopted in the 
implementation guide to clarify the optionality of data elements. These 
improvements resolve the ambiguity on required data elements and 
vocabularies. Overall, the revisions to the draft implementation guide 
that have been incorporated into the final (Release 1) improve the 
ability to test and certify EHR technology to the implementation guide 
and make it easier for EHR technology developers to implement the 
guide's requirements based on the corrections and clarifications. 
Accordingly, we have adopted Release 1 of the implementation guide for 
the ``transmission to cancer registries'' certification criterion.
    Comments. Commenters generally supported the use of SNOMED 
CT[supreg] and LOINC[supreg]. One commenter recommended the use of ICD-
9-CM and ICD-10-CM as well since many physician practices work with and 
are familiar with these standards. Another commenter acknowledged that 
SNOMED CT[supreg] and LOINC[supreg] are valuable for much of the 
required content, but believed the context of data is not necessarily 
included in these code systems. The commenter further noted additional 
data requirements (e.g., medications) which will require RxNorm, 
allergy data (medication in RxNorm, reaction in SNOMED CT[supreg]), 
procedures performed, and patient characteristics to which other 
sections of this report refer. One commenter stated that for dental 
systems the HL7 CDA and SNODENT should be required.
    Response. We appreciate the support commenters indicated for SNOMED 
CT[supreg] and LOINC[supreg] and have adopted them as vocabulary 
standards for this certification criterion. We acknowledge that the 
implementation guide references other vocabulary standards, but believe 
that the vocabulary standards we have adopted in this final rule are 
the most important to focus on in support of cancer case reporting. We 
decline to adopt SNODENT for the ``transmission to cancer registries'' 
certification criterion for the same reasons we gave when we declined 
to adopt it for the ``problem list'' certification criterion in this 
preamble (section III.A.9.a).
    Comments. Commenters noted that both SNOMED CT[supreg] and 
LOINC[supreg] code sets are updated regularly. Therefore, for the 
purposes of certification, commenters recommended that we adopt these 
standards in regulation as ``SNOMED CT[supreg]--current international 
release'' and ``LOINC[supreg]--current release.'' Commenters also 
recommended that we simply state in regulation that EHR technology can 
be certified to the most recent version of the implementation guide, 
which would acknowledge the evolving nature of implementation 
specifications.
    Response. We have established a process for adopting certain 
vocabulary standards, including SNOMED CT[supreg] and LOINC[supreg], 
which permits the use of newer versions of those standards than the one 
adopted in regulation. We refer readers to section IV.B for a 
discussion of ``minimum standards'' code sets and our new more flexible 
approach for their use in certification and upgrading certified 
Complete EHRs and certified EHR Modules. Readers should also review 
Sec.  170.555, which specifies the certification processes for 
``minimum standards'' code sets. In response to the commenters' 
suggestion that we permit the use of the ``most recent version'' of the 
implementation guide for certification, we refer the commenters to 
section III.A.5 found earlier in this preamble. This section explains 
why we cannot take such an approach.
    Comments. A commenter recommended that CMS develop a common 
national data submission standard in order to limit the burden on 
providers and vendors operating in multiple states and therefore 
connecting to multiple registries and other public health 
organizations.
    Response. We do not believe this comment fits within the scope of 
the proposed certification criteria. We note, however, that for all 
public health reporting, CDC is co-leading (with ONC) the efforts of 
the S&I Framework Public Health Reporting Initiative to harmonize data 
elements, vocabularies, and format across public health diseases and 
conditions. The cancer registry community is an active participant in 
this initiative. For cancer reporting, CDC, NCI SEER, and NAACCR have 
worked closely with public health cancer registries to establish a 
single data submission standard, which is already reflected in the 
implementation guide.
    Comments. A couple of commenters suggested that we make clear that 
the state cancer registry, as it is used in the MU objective, may be 
operated directly by a Public Health Authority (PHA) or under contract 
or other delegation agreement with a designated entity, such as a 
university. In either case, they stated that the cancer registry is a 
part of the PHA and EPs should report to it if they choose this Menu 
objective. A few commenters recommended changing ``state cancer 
registry'' to ``public health central cancer registries'' to clearly 
distinguish from hospital[hyphen]based cancer registries which they 
asserted should not satisfy MU requirements.
    Commenters also requested clarification and guidance. A commenter 
requested clarification on what constituted an acceptable registry. 
Another commenter noted that specialized disease registries are often 
proprietary and require special consideration for use and suggested 
that we, therefore, make a distinction for the support of an open and 
public specialized disease registry. One commenter requested 
clarification as to whether the reporting institution is responsible 
for creating report events for residents outside of its respective 
state. A couple of commenters requested clarification on ``in 
accordance with applicable law'' and further explanation on ``except 
where prohibited.'' Another commenter requested clarification regarding 
whether state-specific requirements pertain to the state the provider 
is in, or to the state the patient resides in. One commenter requested 
guidance on meeting this objective due to new reporting methodology 
being created and the readiness of registries to adopt the proposed HL7 
CDA standard.
    Response. We appreciate the submission of these comments, but they 
are outside the scope of this rulemaking. This final rule does not 
create or modify any obligations or choices of EPs to report to disease 
registries or the operations of those registries. It seeks only to 
facilitate such reporting through CEHRT. We direct commenters to the 
Stage 2 final rule found elsewhere in this issue of the Federal 
Register for a discussion of the MU objective and measure and a 
response to these comments.
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)(16) (Inpatient setting only--electronic medication
 administration record).
------------------------------------------------------------------------

    We proposed to adopt a new ``eMAR'' certification criterion with 
the inclusion of the ``synchronized clocks'' standard. We made this 
proposal based on the recommendation of the HITSC for a new 2014 
Edition EHR certification criterion

[[Page 54197]]

to support the MU objective and measure to automatically track 
medications from order to administration. In our proposal, consistent 
with the intent of the HITSC and HITPC, we emphasized that EHR 
technology certified to this certification criterion must enable a user 
to electronically confirm the ``rights'' (i.e., right patient, right 
medication, right dose, right route, and right time) in relation to the 
medication(s) to be administered in combination with an assistive 
technology (e.g., bar-coding, location tracking, and radio-frequency 
identification (RFID)) which provides automated information on the 
``rights.'' We also noted that an electronic ``checklist'' through 
which a user would manually confirm the ``rights'' without any 
automated and assistive feedback from EHR technology would be 
insufficient to demonstrate compliance with this certification 
criterion.
    Comments. Commenters requested clarification on the definition of 
``assistive technology.'' One suggested that we should not define 
assistive technology as barcode scanning, RFID or any other technology 
solution. Another asked whether it could be a nurse at the bedside 
recording medication on a handheld device such as a smart phone or 
tablet; a bedside computer; or if it needed to be a barcode scanner 
that scans the patient, the medication, and automatically records the 
time. A few comments noted that if there is a future requirement to 
progress towards RFID, advance notice would be appropriate because they 
consider all technologies currently acceptable, including various bar 
code formats.
    Response. We have purposefully framed this certification criterion 
to leave open a range of different technologies that could be used to 
demonstrate compliance with the certification criterion. We do not 
intend to single out only one particular technology that would meet 
this certification criterion. We interpret ``assistive technology'' to 
be a technological solution that when paired with EHR technology 
automates the comparative aspects of the five rights that a user would 
otherwise have to manually complete.
    Comment. A commenter requested clarification on whether 
``electronically'' recording the time, date, and user ID at the time of 
administration is a function automatically performed by the system, or 
whether allowing a user to manually enter this data is sufficient.
    Response. We intend for this information to be automatically and 
simultaneously recorded with the use of the assistive technology. A 
manual entry feature for emergency/unanticipated circumstances is not 
prohibited by this certification criterion from existing, but would not 
alone allow for EHR technology to meet this certification criterion.
    Comments. A few comments indicated support for the clarification we 
issued in the Proposed Rule that ``automated'' tracking not simply be a 
presentation of an electronic ``checklist'' to an end user, but that it 
provide for electronic confirmation of the results of an automated 
tracking event such as to scan a patient wrist band or a medication bar 
code to match the right medication for the right patient. Commenters 
suggested that we offer some additional guidance to make it clear that 
the assistive technology used to automate the five rights should not be 
a substitute for clinical judgment and that automated does not mean to 
imply no user confirmatory action. They suggested that we clarify that 
medication administration would include at least a confirmatory step 
for an end user to validate the outcome of an automated check before 
proceeding. They stated that just as manual work steps can lead to 
error, automated tracking should not be relied upon absent a human 
element to confirm (and take responsibility for) the outcome. The 
commenter suggested that we strengthen the language in the 
certification criterion to highlight that ``automated'' also requires 
some type of user confirmatory action.
    A couple of commenters asked whether ``automated'' means that all 
``five rights'' are based on some automated method or if some manual 
interaction is still allowed such as patient selection, signing the 
administration event, performing witnessing if required for patient 
identification as completed and other steps that still may depend on 
user interaction to make an entry into the system. A commenter 
requested clarification on the role of the assistive technology with 
the care provider in ``providing information'' on the ``rights.''
    Several commenters requested that we clarify the meaning of 
``electronically verify'' in the certification criterion (or 
``electronically confirm'' as we stated in the Proposed Rule's 
preamble). Additionally, commenters suggested that we specifically 
state that the EHR technology is not required to provide messaging to 
the user unless one of the ``rights'' is compromised in the medication 
administration process. Additionally, they stated that current systems 
typically do not message a user when all of the five rights are in 
compliance.
    Response. We concur with commenters that the assistive technology 
used to automate the five rights should not be a substitute for 
clinical judgment. A professional clinical user is still responsible 
for his or her actions and should utilize the assistive technology to 
complement, not replace, his or her experience, training, and clinical 
judgment. Along those lines, we interpret ``electronically verify'' in 
the certification criterion to mean that upon the use of an assistive 
technology a user would be able to review and compare within the EHR 
technology the five rights information associated with the medication 
to be administered. By being able to verify this information, the user 
would be able to assess whether the five rights are correct and 
subsequently administer the medication with appropriate documentation. 
Consistent with the clarification requested by commenters, 
``electronically verify'' does not require EHR technology to provide 
some type of explicit notification to a user if all of the five rights 
are correct. However, if one or more are incorrect, the EHR technology 
must provide some indication to a user which ``right(s)'' are 
incorrect/not within compliant parameters.
    With respect to the automation expectations expressed by this 
certification criterion, yes, upon the use of an assistive technology, 
information about each of the rights would need to be automatically 
available for a user to verify. We acknowledge that there are other 
steps within the medication administration workflow for which user 
interaction with, and entries into, EHR technology may be necessary. 
This certification criterion is not meant to preclude those other steps 
nor are they within the current scope of this certification criterion.
    In considering these comments, stakeholder interactions during the 
public comment period, and our own additional research, we would like 
to call to readers attention an error in the certification criterion 
with respect to the ``fifth right'' that we specified. Instead of 
specifying ``right time'' as it is commonly understood--to refer to the 
information about when the medication is to be administered relative to 
the current time--we specified ``right time'' in the proposed 
certification criterion as what is commonly understood to mean ``right 
documentation.'' In light of this oversight, and to ensure that the 
true ``five rights'' are included in this certification criterion, we 
have added in the correct description for ``right time''

[[Page 54198]]

into the certification criterion and revised the proposed capability to 
be called ``right documentation.'' This latter concept remains 
unchanged from our proposal and would require the EHR technology to 
record the time, date, and user identification when a medication is 
administered. We have finalized the eMAR certification criterion with 
the discussed revisions in Sec.  170.314(a)(16) (the CFR paragraph was 
changed due to the combination of two other certification criteria).
    Comment. A commenter requested clarification on how automation can 
determine the ``right route.'' They contended that technology can 
determine the ordered route, and whether the medication can be 
delivered via that route, but only manual actions and manual 
documentation can provide evidence of the route administered.
    Response. The automated aspect of this certification criterion is 
the provision of information associated with the medication to be 
administered; in other words, that the dosage form of the medication is 
appropriate to the ordered route. Thus, when an assistive technology is 
used, the information about the route of medication delivery would need 
to be automatically available for a user to verify.
     Electronic Prescribing

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Generate and transmit permissible discharge prescriptions electronically
 (eRx).
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(b)(3) (Electronic prescribing).
------------------------------------------------------------------------

    We proposed to adopt for the inpatient setting the same revised 
electronic prescribing certification criterion that we proposed to 
adopt for the ambulatory setting (i.e., we proposed to adopt the 
certification criterion at Sec.  170.314(b)(3) for both settings). We 
proposed to require the use of RxNorm as the vocabulary standard and 
NCPDP SCRIPT version 10.6 as the only content exchange standard for 
this certification criterion. In our discussion of this certification 
criterion for the ambulatory setting, we proposed to not include the 
NCPDP SCRIPT version 8.1 in the 2014 Edition EHR certification 
criterion. This proposal was premised on our understanding that CMS was 
planning to propose the retirement of NCPDP SCRIPT version 8.1 for the 
Medicare Part D e-prescribing program soon after our proposed rule was 
to be published. We noted that if we received information indicating a 
change in CMS' plans prior to the issuance of our final rule, we may, 
based also on public comment, retain this standard in a final revised 
certification criterion. We stated that we were proposing to adopt this 
certification criterion for both the ambulatory and inpatient settings 
because it supports our desired policy and interoperability outcome for 
content exchange standards to be used when information is exchanged 
between different legal entities.
    Comments. Many commenters supported our proposal to require 
certification to NCPDP SCRIPT 10.6 for this certification criterion. 
Other commenters suggested that we should continue to permit 
certification to NCPDP SCRIPT 8.1 until it is officially retired from 
the Part D e-prescribing program by CMS.
    Response. We appreciate commenters support for our proposal to 
require certification to NCPDP SCRIPT 10.6 and have finalized the 
certification criterion as proposed. We are not including NCPDP SCRIPT 
8.1 in this certification criterion. CMS has recently proposed (77 FR 
45022) to retire version 8.1 and only permit version 10.6 as of 11/1/
2013. More importantly, NCPDP SCRIPT 10.6 is backwards compatible with 
version 8.1, so 10.6 users will be able to communicate with version 8.1 
users. Therefore, even in the event that CMS does not retire version 
8.1 before the FY/CY 2014 EHR reporting period, use of version 10.6 
should not have an adverse impact on stakeholders. Moreover, we 
understand that version 10.6 includes much needed improvements and 
better supports stakeholders' e-prescribing needs across a variety of 
health care settings.
    Comments. A number of commenters requested that we establish a 
deeming provision as part of our e-prescribing certification criterion 
that would make Surescripts certification for participation in its 
network an acceptable method to demonstrate compliance with this 
certification criterion. That is, in lieu of being certified by an ONC-
ACB according to the adopted certification criterion and standards, EHR 
technology could be deemed to be certified to meet this certification 
criterion if it were certified according to Surescripts certification 
requirements.
    Response. As we did not propose deeming authorities in the Proposed 
Rule, these suggestions are outside the scope of this final rule. 
Furthermore, we believe that the best way to ensure that EHR technology 
includes the capabilities specified by the certification criteria 
adopted by the Secretary is to require EHR technology to be tested and 
certified to these certification criteria under the provisions and 
procedures specified by the ONC HIT Certification Program.
    Comments. Several commenters requested that we include HL7 v2.x 
standards for discharge e-prescribing. They reasoned that discharge 
prescriptions filled by a pharmacy within the walls of a hospital 
facility frequently use HL7 v2.x prescribing messages. Some commenters 
also stated that EHR technology certified to the HL7 v2.x standards for 
discharge e-prescribing should be permitted even in cases where the 
pharmacy inside the hospital facility may be a different legal entity 
from the source of the discharge medication. Commenters asserted that 
hospitals currently use HL7 transmissions to send their prescriptions 
to an onsite pharmacy that is a separate legal entity. Another 
commenter requested clarification as to whether NCPDP SCRIPT needed to 
be used by an EH/CAH to transmit electronic prescriptions for discharge 
medications that would be filled by that EH/CAH's hospital-based 
pharmacy, including when that pharmacy is a separate legal entity. 
Other commenters supported our approach of focusing on interoperability 
between different legal entities and not on transactions within a legal 
entity.
    Response. We appreciate the support for our e-prescribing approach 
to certification. We continue to believe, as we stated in the Proposed 
Rule that it would be inappropriate and without sufficient benefit to 
require certification of EHR technology for transmissions that would be 
conducted within a single legal entity. We continue to believe, as we 
stated in the Proposed Rule (77 FR 13845), that doing so would be 
inconsistent with our approach of adopting standards for the electronic 
exchange of health information between different legal entities. We 
encourage commenters to read the Stage 2 proposed rule (77 FR 13710) 
because it discusses the various ways in which the e-prescribing MU 
objectives can be met such that it should address the concerns 
expressed by these comments. We also encourage commenters that 
indicated that HL7 transmissions were used even in situations where a 
pharmacy is considered a different legal entity to carefully read the 
Medicare Part D e-prescribing rules at 42 CFR 423.160(a)(3)(iii) 
(noting that HL7 transmissions are only permitted when the sender and 
recipient are part of the same legal entity). In light of the Part D e-
prescribing program bar on the use of HL7 between different legal 
entities, we are not considering allowing it in our certification 
criterion.

[[Page 54199]]

    Comments. A commenter requested that we clarify what the use of 
RxNorm as the sole vocabulary would entail. The commenter asked whether 
RxNorm would be a drug description or a drug qualifier and urged ONC to 
reference RxNorm as a drug qualifier, specifically via the use of 
RxNorm concept unique identifiers (RXCUIs), similar to how NDC 
identifiers are currently being used. The commenter stated that since 
most EHR technologies use proprietary commercial drug databases for 
their clinical terminology needs, that there is a critical and urgent 
need for RxNorm RXCUI mappings to proprietary drug database codes to be 
made readily available to the industry by either drug database 
companies or a third party in order to foster the adoption of RxNorm.
    Response. The use of RxNorm as the sole vocabulary standard would 
entail its use to represent medications within an electronic 
prescription formatted according to the SCRIPT 10.6 standard. We intend 
for the RxNorm concept unique identifiers (RXCUIs) to be used as drug 
qualifiers. Mappings are not something within the scope of this 
rulemaking and we decline to make any changes in response to this 
comment.
    Comments. Many commenters agreed with our proposal to adopt RxNorm, 
but requested certain clarifications. These commenters noted that not 
all medications in source vocabularies have an equivalent RxNorm code. 
Further, they suggested that the standard should state that the RxNorm 
vocabulary will be utilized when there is an equivalent concept 
mapping. Others requested clarification that the reference to RxNorm 
means that RxNorm codes must be included in transmitted messages, not 
that only RxNorm codes can be transmitted because there are some 
prescriptions that do not have corresponding RxNorm codes and will 
require other code sets. A commenter expanded on these concerns with 
the following observation: Some drug descriptions in RxNorm are over 
105 characters in length, but the NCPDP SCRIPT standard limits drug 
descriptions to 105 characters, which means that transmission of some 
e-prescriptions that include RxNorm drug descriptions would be either 
truncated or not possible. As such, they suggested that certification 
criteria for RxNorm should be limited to use of this standard for drug 
qualifiers only. They also cautioned that RxNorm is not yet a complete 
drug compendium, and that RxNorm qualifiers are not available for all 
prescriptions that are currently sent electronically (e.g., medical 
supplies). Similar to other commenters, they also suggested that we 
clarify that the transition to the certification criterion would not 
preclude use of other drug databases and qualifiers if circumstances 
require it.
    Response. We acknowledge that all medications may not yet have an 
equivalent RxNorm code. We do not believe it is necessary to modify the 
standard to explicitly state that RxNorm ``be utilized when there is an 
equivalent concept mapping'' because certification is meant to verify 
that EHR technology can properly use this standard. This certification 
criterion requires the capability to use RxNorm, specifically RXCUIs as 
noted in our prior response. Thus, where no RxNorm code exists, nothing 
prohibits another code from being used. However, where corresponding 
RxNorm codes exist, EHR technology must be able to use those codes. As 
RxNorm continues to expand, we expect that the concerns raised by 
commenters about its comprehensiveness will subside.
    Comment. Commenters noted that the same e-prescribing certification 
criterion applies to both ambulatory and inpatient settings. They 
stated that it would be important for the final rule and subsequently 
developed test procedures to identify any differences between the two 
settings.
    Response. With the exception of which test data elements might be 
required, this certification criterion applies equally to both 
settings. EHR technology certified to this certification criterion will 
need to enable a user to electronically create prescriptions and 
prescription-related information in accordance with NCPDP SCRIPT 10.6 
and RxNorm.
    Comment. A commenter stated that there needs to be a clear way to 
differentiate whether a prescription is merely sent ``in house'' 
(scenarios 1 and 2 in the Stage 2 proposed rule or ``transmitted'' 
(scenario 3)).
    Response. Given the flexibility provided by CMS, we believe this 
will need to be determined on an implementation-by-implementation basis 
and would be difficult to assess for the purpose of certification in a 
simulated testing laboratory environment.
    Comment. A commenter recommended that EHR technologies support 
integration with HIEs in support of the e-prescribing process.
    Response. This suggestion is outside the scope of our final rule. 
We appreciate the commenter's feedback and will consider whether a 
certification criterion to address this type of capability would be 
appropriate for a future rulemaking.
    Comments. A few commenters discussed the electronic prescribing of 
controlled substances. Some encouraged ONC and CMS to work to include 
controlled substances into future meaningful use measures. Others 
agreed with CMS's proposal to continue to exclude controlled substances 
from the e-prescribing objectives and asked that we make clear that the 
electronic prescribing of controlled substances (EPCS) is not required 
(and will not be tested) from a certification standpoint. They noted 
that e-prescribing of controlled substances involves many other 
workflow requirements for prescription review and acknowledgment, 
technical requirements for electronic signature and security of the 
transmitted prescription that go well beyond the scope of what was 
proposed. One commenter stated that adopting NCPDP SCRIPT version 10.6 
without also mandating e-prescribing of controlled substances is 
contradictory and will create unnecessary costs and undesirable results 
due to the lack of synchronization. They contended that NCPDP SCRIPT 
version 10.6 should not be required for certification because it will 
slow the progress being made by the industry as stakeholders are 
coupling their development efforts for NCPDP SCRIPT version 10.6 and e-
prescribing of controlled substances together. Last, a commenter 
suggested that we should require that EHR technology that includes e-
prescribing capabilities to be implemented according to the recently 
released DEA requirements for all e-prescribing.
    Response. While we intend to continue to work with CMS on the issue 
of controlled substance e-prescribing, we believe it is premature to 
include controlled substances in the 2014 edition of the certification 
requirements. We will need to carefully evaluate the practicality of 
what would amount to duplicating DEA's regulatory requirements for 
certification in our regulations and the potential unintended 
consequences of taking such a step. Furthermore if we were to adopt 
some or all of the provisions in the DEA's interim final rule in our 
program and, if DEA were to make any changes as it finalizes its 
interim final rule, our adopted certification criteria would be out of 
compliance with DEA's requirements. Further, DEA permits a 
certification option in its interim final rule and has approved at 
least one certification body's processes to perform certifications for 
EPCS. Thus, we question the value in ONC replicating these already 
established processes.

[[Page 54200]]

Finally, we do not see how the adoption of NCPDP SCRIPT 10.6 without 
mandating EPCS could be contradictory. They are both separate and 
distinct regulatory requirements and one does not necessarily depend on 
the other to succeed.
    Comment. A commenter recommended that we revise the certification 
criterion as follows, ``generate and transmit permissible discharge 
prescriptions electronically.''
    Response. We do not believe that this editorial suggestion adds any 
tangible value or clarifies the wording in the certification criterion 
in a major way. Thus, we decline to modify this certification criterion 
in response to this suggestion.
    Comment. A commenter recommended that we include a capability in 
the certification criterion that ensures a provider is actively alerted 
when an e-prescription fails.
    Response. This suggested capability is beyond the scope of the 
proposed certification criterion and we decline to modify the 
certification criterion. We will consider whether such a requirement 
would be appropriate to include in later editions of EHR certification 
criteria.
    Comment. A commenter recommended that there be a way for patients 
to review e-prescriptions and participate in medication reconciliation 
with both their doctors and pharmacists via a patient portal.
    Response. This suggested capability is beyond the scope of the 
proposed certification criterion and we decline to modify the 
certification criterion. We will consider whether such a requirement 
would be appropriate to include in later editions of EHR certification 
criteria.
    Comment. A commenter stated that they would like standards and 
testing to demonstrate using e-prescribing for refills that allows 
multiple medications to be refilled from a single screen through a 
single transaction. They explained that for some EHR technologies the 
refill process is more problematic than the initial prescription 
process and that certification should ensure this is not the case.
    Response. We do not believe that this is an issue that can be 
readily addressed through certification. Rather, this comment appears 
to focus on a particular user interface and workflow design 
shortcomings of certain EHR technology. This aspect is outside the 
scope of what is required by this certification criterion.
     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).
------------------------------------------------------------------------

    We proposed a certification criterion that was similar to the one 
recommended by the HITSC to support the MU objective and measure 
recommended by the HITPC for EHs and CAHs to send electronic laboratory 
tests and values/results to EPs. CMS did not specifically propose the 
HITPC recommended MU objective and measure for Stage 2, but requested 
public comment on whether the objective and measure should be 
incorporated into MU Stage 2.
    We proposed to include in the certification criterion the standards 
and implementation specification recommended by the HITSC and HITPC for 
the transmission of laboratory tests and values/results. In particular, 
we referenced the work of the Standards and Interoperability Framework 
Laboratory Results Interface Initiative which 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 proposed to include the HL7 2.5.1 standard 
and the HL7 Version 2.5.1 Implementation Guide: Standards and 
Interoperability Framework Laboratory Results Interface, Release 1 (US 
Realm) (S&I Framework LRI). We proposed to adopt LOINC[supreg] version 
2.38 as the vocabulary standard, at the recommendation of the HITPC and 
agreement of the HITSC. We noted that the LRI specification was 
undergoing HL7 balloting and that we would monitor its progress in 
relation to the publication of this final rule.
    With respect to testing and certification for this certification 
criterion, we stated that, among other aspects, 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 also noted that we had proposed 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 we proposed for this certification criterion.
    In proposing this certification criterion, we stated that requiring 
inpatient EHR technology to 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.
    Comments. Many commenters supported this certification criterion. 
Some commenters stated that we should not adopt this certification 
criterion without CMS establishing a corresponding MU objective and 
measure, while other commenters did not support this certification 
criterion for concerns related to implementation costs, the proposed 
standards, and the inclusion of this functionality in EHR technology.
    Response. We are adopting this certification criterion for the 2014 
Edition EHR certification criteria at Sec.  170.314(b)(6). After 
consideration of public comments, CMS has included a corresponding 
objective and measure in the MU Stage 2 menu set and the adoption of 
this certification criterion will support that objective and measure. 
We discuss our responses to the other commenters' concerns in our 
responses below.
    Comments. Commenters recommended that the transmission of 
electronic laboratory tests and values/results from inpatient EHR 
technology should follow the same standard that applies to the 
incorporation of laboratory tests and values/results in ambulatory EHR 
technology. Some of these commenters stated that this certification 
criterion should not be adopted without ambulatory EHR technology 
having the same requirements.
    Response. We agree with commenters. We proposed and have adopted in 
the ``incorporate laboratory tests and values/results'' certification 
criterion (Sec.  170.314(b)(5)) a requirement that EHR technology 
designed for the ambulatory setting must be certified to be able to 
receive and incorporate laboratory tests and values/results in 
accordance with the LRI specification. The certification criterion 
discussed here, and which is applicable to inpatient EHR technology, 
requires that such EHR technology be able to create laboratory test 
reports in the same manner.
    Comments. Many commenters supported the proposed standards and 
implementation guide. Other commenters stated that while the S&I 
Framework LRI is based on previously

[[Page 54201]]

used standards, it is not in widespread production and may not be 
sufficiently mature for nationwide use. A few commenters noted that 
pilots currently in process were using the LRI specification. One 
commenter stated that the LRI specification was developed for the types 
of tests commonly ordered in the ambulatory setting and does not 
address electronic messaging of complex test results such as molecular 
genetics, anatomic pathology, and cytology. The commenter contended 
that messaging for these test results needs further development and 
testing before they can be included in routine electronic messaging 
transmission of laboratory results from hospitals to ambulatory 
providers. Therefore, the commenter recommended postponing inclusion of 
the LRI specification until the next edition of certification criteria.
    Response. We believe that the S&I Framework LRI implementation 
guide is mature enough for adoption and inclusion in this certification 
criterion. As we noted above and in the Proposed Rule, the LRI 
implementation guide has been undergoing balloting by HL7. The LRI 
implementation guide was approved by HL7 as a Draft Standard for Trial 
Use (DSTU) in July 2012. This confirms its adoption as a consensus-
based standard ready for use. This DSTU version of the standard updates 
the version we proposed by correcting errors and clarifying 
requirements. These corrections and clarifications will assist EHR 
technology developers in implementing the standard and will improve 
testing to the standard. As noted by HL7 in its documentation, this 
DSTU version of the standard will be open for comment for 24 months and 
following this evaluation period, it will be revised as necessary and 
then submitted to ANSI for approval as an American National Standard 
(normative standard). Further, HL7 specifies that implementation of 
this DSTU version will be valid during the ANSI approval process and 
``for up to six months after publication'' of the normative standard. 
Given the state at which this DSTU version of the standard is and the 
fact that this version alone is subject to the evaluation period, we 
believe that it is the best possible choice for this final rule, 
especially in place of the draft version we referenced in the Proposed 
Rule. Accordingly, we have adopted this version of the LRI 
implementation guide for requiring the electronic creation of 
laboratory tests and values/results for electronic transmission and to 
support the associated MU objective and measure.
    As we acknowledged in a response to a comment on the revised 
``incorporate laboratory tests and values/results'' certification 
criterion (Sec.  170.314(b)(5)), we erred in referencing the HL7 2.5.1 
standard in addition to the LRI specification. Thus, we have removed 
the reference to the HL7 2.5.1 standard in this certification 
criterion. We also clarify that with the exception of the baseline 
minimum version of LOINC[supreg] that must be supported by EHR 
technology, we expect, in adopting this specification that it will be 
followed and implemented as authored.
    Comments. Some commenters agreed that this certification 
requirement could potentially lead to reduced costs for laboratory 
interfaces, while other commenters thought it was unlikely to reduce 
costs. Commenters stated that lab system vendors are not necessarily 
bound to conform to the LRI specification which would create an 
undesirable situation where EHRs would be forced to provide conforming 
and non-conforming interfaces (one set to comply with certification and 
the other to be used for communication with lab systems). Commenter 
also stated that laboratory information systems (LIS) typically produce 
the reportable results. Commenters stated that these systems are not 
normally integrated with the hospital EHR. Rather these systems send 
lab results directly to the ordering physicians based on rules defined 
by CLIA (Clinical Laboratory Improvement Amendments) and are often 
further refined by state regulation.
    Commenters noted that this certification criterion may serve to 
open up the strong possibility that laboratory information systems 
(LISs) will become certified as EHR modules on a more regular basis, 
and may motivate some vendors to seek certification on that basis both 
for this criterion as well as the public health reporting of lab 
results (which some LIS vendors have already done).
    Response. The MU objective and measure that this certification 
criterion supports is in the MU Stage 2 menu set. Based on the revised 
CEHRT definition, the final rule provides EHs and CAHs the regulatory 
flexibility to determine whether to adopt EHR technology certified to 
this certification criterion in order to meet this MU objective and 
measure. Further, as noted by some commenters, the relevant LIS 
capabilities could potentially be certified to this certification 
criterion, perhaps as an EHR Module, and used to meet the associated MU 
objective and measure. Considering these points, we do not believe this 
certification criterion creates any undue burden and, as agreed to by 
commenters, could facilitate more cost effective electronic laboratory 
results interfaces in the ambulatory setting.
    Comments. Some commenters suggested we focus on a ``standard 
receiver'' or ``universal interface'' that could accept multiple types 
of results in one interface. These commenters stated that it is cost-
prohibitive to providers to purchase different interfaces for each set 
of information received. Therefore, these commenters recommended that 
we permit the use of existing interfaces or postpone certification and/
or MU requirements related to use of the LRI, while efforts are pursued 
towards a ``universal interface.''
    Response. The adopted LRI specification for the ambulatory setting 
is intended to provide the desired interface uniformity commenters have 
noted for the receipt of laboratory test results. We believe this 
standard is appropriate and mature for the purposes of EHR technology 
certification. As we have indicated in other responses in this final 
rule certification addresses the technical capabilities that EHR 
technology must include. It does not address how it must be used, once 
certified. Therefore, we do not agree with the comment that we should 
postpone adoption of this certification criterion until a ``universal 
interface'' is developed. In the Stage 2 final rule published elsewhere 
in this edition of the Federal Register, CMS specifies the requirements 
and flexibilities related to the incorporation of laboratory test 
results.
    Comments. Commenters supported the adoption of the LOINC[supreg] 
standard for transmitting laboratory test results. Commenters stated, 
however the full LOINC[supreg] coding of all tests and analytes is 
unnecessary. Rather, the commenters stated that the subset that 
accounts for most frequent ambulatory use and alignment with quality 
measures and public health requirements should be the requirement.
    Response. To meet this certification criterion, EHR technology must 
meet the LRI specification using LOINC[supreg]. For the purposes of 
testing and certification, we expect that EHR technology will be 
evaluated based on its ability to use most commonly reported 
LOINC[supreg] codes. We expect that the test procedure developed for 
this certification criterion will leverage LOINC[supreg] materials 
published by the Regenstrief Institute and available through the 
National Library Medicine,\16\ which in this case

[[Page 54202]]

would be the ``LOINC[supreg] Top 2000+ Lab Observations and Mapper's 
Guide.'' This guide is an empirically-based list of the most common 
LOINC[supreg] result codes for laboratories, practices, researchers, 
and others who wish to map their laboratory test codes to universal 
LOINC[supreg] codes. This list contains over 2000 of the most commonly 
reported LOINC[supreg] codes that represent about 98% of the test 
volume carried by three large organizations that mapped all of their 
laboratory tests to LOINC[supreg] codes. We believe this scope for 
testing and certification will help aid EHR technology developers and 
focus development efforts toward these top 2000+ codes first.
---------------------------------------------------------------------------

    \16\ https://www.nlm.nih.gov/healthit/meaningful_use.html--click 
on helpful subsets under the LOINC heading.
---------------------------------------------------------------------------

    Comments. Commenters suggested that we simply state in regulation 
that EHR technology can be certified to the most recent versions of 
LOINC[supreg].
    Response. We have established a process for adopting certain 
vocabulary standards, including LOINC[supreg], which permits the use of 
newer versions of those standards than the one adopted in regulation. 
We refer readers to section IV.B for a discussion of ``minimum 
standards'' code sets and our new more flexible approach for their use 
in certification and upgrading certified Complete EHRs and certified 
EHR Modules. Readers should also review Sec.  170.555, which specifies 
the certification processes for ``minimum standards'' code sets.
    Comment. A commenter requested a list of CPT codes that define 
imaging studies and a listing of CPT codes that define a laboratory 
test.
    Response. The commenter did not provide any supporting rationale as 
to why a list of CPT codes would be relevant to the capabilities 
expressed by this certification criterion. Thus, we decline to provide 
any additional information.
    Comments. A commenter recommended inclusion of a date/time stamp on 
all values sent to ambulatory providers.
    Response. The LRI specification's message header includes a 
required date/time stamp and the result segment (OBX) includes a test 
performed date/time stamp that is required if it exists.
    Comments. A commenter suggested that NwHIN query-and-response 
protocol be required for use in sharing laboratory test results as part 
of this certification criterion. The commenter stated that such a 
requirement would encourage EHR technology developers to use the NwHIN 
protocol to have providers in different care settings access clinical 
information, including laboratory tests.
    Response. We appreciate the commenter's suggestion, but did not 
propose specific transport approaches to require for certification and 
intend to focus certification on the proper implementation of the LRI 
specification.
    Comments. Commenters requested clarification about to whom the 
transmission may occur, whether directly to EPs or through an HIE 
structure.
    Response. This certification criterion focuses on the proper 
implementation of the LRI specification. How or by what means the 
laboratory test report gets to an EP is not currently within the scope 
the certification criterion and, in part, is likely dictated by other 
regulatory requirements, such as the CLIA rules.
    Comments. A few commenters suggested that ONC work with CMS to 
encourage laboratories to adopt and use the S&I Framework LRI 
specification. They contended that without the ``source systems'' on 
board that requiring capabilities on receiving systems (EHR technology) 
would fall short of the intended purpose of reducing development time 
and costs and improving quality.
    Response. We appreciate these comments and will continue to work 
with our sister agencies in HHS to advance health IT policy in other 
programs and regulations that affect stakeholders that are not eligible 
to receive EHR incentive payments.
    Comment. A commenter stated that patients should also have access 
to all laboratory tests and results immediately, both inpatient and 
ambulatory, as a matter of patient safety.
    Response. We appreciate this comment, but it is not something a 
capability in EHR technology, per se, can resolve. Through the EHR 
Incentive Programs, EPs, EHs, and CAHs, will have to provide online 
access to patients to view their electronic health information. This 
should provide a means for patients to get prompt access to their 
laboratory test results. We also note that CMS and OCR have engaged in 
rulemaking to permit patients to directly access their lab test reports 
(75 FR 56712).
10. Revised Certification Criteria
    In the Proposed Rule, we described certification criteria that we 
considered ``revised.'' We noted the following 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.
    For clarity, we explained that, 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.
    Comments. We did not receive comments questioning our description 
of revised certification criteria.
    Response. Given that we received no comments, we will continue to 
use this description of revised certification criteria to categorize 
the following certification criteria we have adopted as part of the 
2014 Edition EHR certification criteria. We note that the following 
adopted revised certification criteria included certification criteria 
that were not only proposed as revised certification criteria, but also 
certification criteria that were proposed as unchanged certification 
criteria in the Proposed Rule.
a. Ambulatory and Inpatient Setting
    We propose to adopt the following revised certification criteria 
for both the ambulatory and inpatient settings.
     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).
------------------------------------------------------------------------

    We proposed the ``vital signs, body mass index, and growth charts'' 
certification criterion (Sec.  170.314(a)(4)) of the 2014 Edition EHR 
certification criteria as an unchanged certification criterion. We 
proposed to replace the terms ``modify'' and ``retrieve'' with 
``change'' and ``access,'' respectively. We also proposed to add the 
alternative term ``length'' to go with ``height'' as it

[[Page 54203]]

is the clinically appropriate term for newborns and assisted in 
clarifying the intent of the ``vital signs'' capability. The only other 
refinements that we proposed were for the plot and display growth 
charts capability. First, we proposed that this capability be 
designated ``optional'' within this certification criterion because 
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 proposed to designate growth charts as ``optional'' for 
certification. Second, we proposed to remove the age range reference 
(2-20 years old) from this capability. We noted that this proposed 
refinement was 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 a patient's age.
    Comments. Many commenters recommended that this certification 
criterion remain unchanged. A couple of commenters recommended the use 
of the LOINC[supreg] (for observations), SNOMED CT[supreg] (for 
qualitative results), and UCUM (for units of measure), as applicable, 
for the recording of the data elements specified in this certification 
criterion. One commenter recommended that requirements for specific 
data elements that would be included as part of vital signs data in MU 
Stage 2, such as ECG waveforms, be defined so that the appropriate 
device integration standards can be developed to support 
interoperability and certification standards and criteria for these 
important physiologic signals.
    A commenter stated that the capability to plot and display growth 
charts should be a required capability and should be specified in more 
detail. Another commenter requested clarification on what type of 
growth charts were applicable based on age ranges. In particular, the 
commenter pointed to the World Health Organization for growth standards 
for children 0 to 2 years old and CDC growth charts for ages 2 and 
older.\17\ Another commenter requested clarification that growth charts 
would not need to be included in a transition of care/referral summary 
formatted in accordance with the Consolidated CDA because they are not 
listed as a ``vital sign'' in the Consolidated CDA. Commenters also 
requested guidance on how the optional capability of plotting and 
displaying growth charts would be indicated in an EHR technology's 
certification and for marketing purposes.
---------------------------------------------------------------------------

    \17\ https://www.cdc.gov/growthcharts/who_charts.htm.
---------------------------------------------------------------------------

    Response. We thank commenters for generally supporting this 
certification criterion. We decline to revise this certification 
criterion in response to the comment that recommended we require EHR 
technology to natively record vital signs data in specific 
vocabularies. We did not propose this requirement and believe that the 
complexity of wholesale change to the data capture processes of 
existing EHR technologies for this purpose cannot be understated. 
Additionally, it is our understanding that many EHR technologies 
capture this information, but do not currently map it to standardized 
terminologies such as LOINC[supreg]--and there are currently many 
different workflows, templates, and forms that are used to capture this 
information. Thus, we believe that requiring vital signs data that is 
recorded to, for example, be mapped to LOINC[supreg] is too burdensome 
a requirement to impose for certification to the 2014 Edition EHR 
certification criteria. Moreover, our concern stems from the 
possibility that such a requirement could cause EHR technology 
developers to map vital signs capture to a standardized terminology in 
one workflow but perhaps not others--which would then cause providers 
to be forced to use a given workflow/form/template to achieve MU that 
is not consistent with optimal workflow/usability. We do intend, 
however, to require as part of the next edition of EHR certification 
criteria that EHR technology would need to be able to record all vital 
signs according to standardized terminologies. Further, we emphasize to 
EHR technology developers that nothing precludes you from taking this 
step for certification to the 2014 Edition EHR certification criteria.
    Nonetheless, in response to these comments we evaluated the 
specificity and clarity of the certification criterion and believe that 
it needs to be revised. First, we believe the grammar in the 
certification criterion makes it more difficult than necessary to read. 
Second, while we have declined to revise this certification criterion 
in the way commenters suggested (that we require explicit recording of 
vital signs in standardized codes), we believe that an important, but 
modest, intermediate step must be taken to improve the certification 
criterion's specificity and its ability to affect patient safety. 
Accordingly, we have revised this certification criterion to explicitly 
state that the data recorded by EHR technology for height/length, 
weight, and blood pressure must be in numeric values only (i.e., 
alphabetic characters such as ``lbs,'' ``kg,'' or ``cm'' would not be 
permitted to included as part of the value recorded). This restriction 
has significant clinical and patient safety benefits because it 
prevents the inappropriate recording of text in fields that should be 
constrained to numeric values. Additional attributes that may be used 
to document (e.g., which arm a blood pressure is taken from, whether 
the patient is sitting or standing, or a reason that the value could 
not be obtained) should be recorded in a supplemental field rather than 
the field for the value itself. We expect that a significant majority 
of EHR technologies already function this way. Thus, we anticipate that 
this revision poses little, if any, practical burden to most EHR 
technology developers. However, in cases where this revised 
certification criterion will cause EHR technology to be updated for 
certification, we believe that better patient safety outweighs the 
burden.
    With respect to the commenter's recommendation for defining and 
including data elements such as ECG waveforms as part of vital signs 
data in MU Stage 2, we note that this data element goes beyond the 
requirements of the associated MU objective and measure. Thus, we have 
not made any changes in response to this recommendation.
    We do not believe that the capability to plot and electronically 
display growth charts should be a required capability because, as we 
noted in the Proposed Rule, not all EP, EHs, and CAHs will necessarily 
need this capability. For certification to this certification 
criterion, we clarify that EHR technology is not required to 
demonstrate the capability to provide growth charts based on subsets of 
age ranges within the 0-20 age range required by the MU objective. 
However, we encourage EHR technology developers to include the 
specificity that best addresses their customers' needs. We further 
clarify that the growth chart capability included in this certification 
criterion requires EHR technology to be capable of plotting and 
electronically displaying growth charts of patients. We do not expect 
growth charts to be transmitted in a transition of care/referral 
summary formatted in accordance with the Consolidated CDA. Last, we 
expect that certifications issued to EHR technology certified to this 
certification criterion will indicate

[[Page 54204]]

whether the EHR technology is capable of plotting and electronically 
displaying growth charts and that such information would be accessible 
on the CHPL.
     Drug-Formulary Checks

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Implement drug formulary checks.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(a)(10) (Drug formulary checks).
------------------------------------------------------------------------

    We proposed the ``drug-formulary checks'' certification criterion 
(Sec.  170.314(a)(10)) of the 2014 Edition EHR certification criteria 
as an unchanged certification criterion.
    Comments. Many commenters supported this certification criterion 
remaining unchanged for the 2014 Edition EHR certification criteria. A 
few commenters suggested that EHR technology developers who had 
completed Surescripts' Eligibility and Formulary certification could be 
permitted to attest to this certification criterion. Commenters 
recommended that EPs be able to obtain drug-formulary information that 
is accurate, in real-time, and includes the necessary details for the 
prescriber's review. One commenter recommended that we specifically 
include a capability in this certification criterion to capture the 
plan name, plan identification number, group identification number, and 
pharmacy benefit management care coverage in structured data. A couple 
of commenters recommended that we adopt the NCPDP Formulary and Benefit 
Standard Implementation Guide, Version 3.0, or alternatively, at a 
minimum, the NCPDP Formulary and Benefit Standard Implementation Guide, 
Version 1.0 as the standard to enable electronic formulary checking. A 
commenter suggested that we require EHR technology to be capable of 
making available all necessary formularies, which the commenter stated 
would help address situations where there is a lack of consistent 
access to Medicaid formularies, including Medicaid Managed Care 
formularies.
    Response. We appreciate the support expressed for the certification 
criterion and the specific feedback commenters provided. In response to 
this feedback and clarifications issued by CMS in its final rule for 
the MU objectives and measures this certification criterion supports, 
we have determined that it is necessary to revise this certification 
criterion. The revised certification criterion is designed to ensure 
that a drug formulary check poses minimal burden on EPs, EHs, and CAHs. 
Further, the revision we have included specifies that EHR technology 
must perform an automated check for the existence of a drug formulary 
that is specific to a patient for the medication to be prescribed. In 
other words, an EHR technology would not satisfy this revised 
certification criterion if it provided a hyperlink to a patient's drug 
formulary that an EP, EH, or CAH then had to manually open and 
navigate. With respect to commenters' suggestions to further modify 
this certification criterion to include additional capabilities, such 
as those that would ensure real-time information, capture of specific 
information (e.g., plan name, plan identification number, etc.) in 
structured data, and making available all necessary formularies, we 
believe these suggestions exceed the baseline requirements for 
certification that we have included to support MU. Thus, we decline to 
make any further revisions to the certification criterion except those 
noted above. As discussed in the e-prescribing comment and responses 
part of this final rule, CMS has issued a proposed rule (77 FR 45022) 
that would update Medicare Part D e-prescribing standards, including a 
new version of the formulary and benefit standard. We strongly 
encourage EHR technology developers to utilize these standards, but do 
not believe that it is necessary at this time to require them as a 
condition of certification--as having current drug formularies stored 
locally in the EHR technology would also be a permitted approach. 
Further, as we discussed in the S&CC July 2010 final rule (75 FR 
44602), because some EPs, EHs, and CAHs, do not have external access to 
a drug formulary and would be able to satisfy the MU requirements by 
checking an internally managed drug formulary, we believe the 
flexibility provided by the certification criterion is still warranted. 
We intend to seek recommendations from the HITSC on further 
requirements related to this certification criterion in developing the 
next edition of our EHR certification criteria.
    Last, the ONC HIT Certification Program does not include any form 
of reciprocity for certification under other private sector 
certification programs, including Surescripts' certification program. 
The ONC HIT Certification Program will be a ``new'' certification 
program that will replace the temporary certification program upon the 
effective date of this final rule. At its onset, we believe that the 
best way to ensure that EHR technology has the capabilities included in 
the certification criteria adopted by the Secretary is to require the 
EHR technology to be tested and certified to the certification criteria 
under the provisions and procedures specified by the ONC HIT 
Certification Program.
     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).
------------------------------------------------------------------------

    The 2011 Edition EHR certification criterion for smoking status 
(Sec.  170.302(g)) specifies a list of six smoking status types that 
EHR technology must be capable of recording, modifying, and retrieving. 
For the 2014 Edition EHR certification criteria, we proposed a 
``smoking status'' certification criterion that replaced the terms 
``modify'' and ``retrieve'' with ``change'' and ``access,'' 
respectively. We also proposed to specify the six smoking status types 
included in the 2011 Edition EHR certification criterion as a standard 
at Sec.  170.207(l). We stated that this refinement would provide 
additional clarity for the certification criterion and consistency with 
the structure of similar certification criteria.
    Comments. Multiple commenters expressed agreement with this 
certification criterion as proposed. More commenters, however, 
recommended that we adopt an industry developed and accepted standard 
and pointed to SNOMED CT[supreg] as the appropriate standard. If SNOMED 
CT[supreg] was not adopted, commenters asked that we provide a 
crosswalk from the smoking status types included in the certification 
criterion to the appropriate SNOMED CT[supreg] codes.
    Commenters raised questions about the definitions/categories of the 
smoking status types. One commenter suggested that all tobacco use 
should be captured. Another commenter recommended that the smoking 
status types reflect the questions used in community health assessment 
that track smoking and tobacco use cessation interventions or medical 
assistance such as: (a) Advising smokers and tobacco users to quit 
``patient has been offered a smoking cessation program;'' (b) 
discussing smoking and tobacco use cessation medications; (c) 
discussing smoking and tobacco use cessation strategies or ``assistance 
in setting a quit date.'' A few commenters asked whether mapping to the 
smoking status types included in the certification criterion would be 
permitted for certification and, if so, for further clarification of 
potential categories that would suitably

[[Page 54205]]

map to the smoking status types included in the certification 
criterion. For example, commenters asked whether mapping would apply to 
only cigarettes or other forms of combustible tobacco use as well.
    A few commenters noted that the smoking status types adopted for 
the 2011 Edition EHR certification criteria and proposed for the 2014 
Edition EHR certification criteria do not align with those used in the 
quality measures in Stage 1 and proposed for Stage 2, such as NQF 0028 
(Preventive Care and Screening: Tobacco Use: ``Screening and Cessation 
Intervention (percentage of patients aged 18 years and older who were 
screened for tobacco use one or more times within 24 months AND who 
received cessation counseling intervention if identified as a tobacco 
user''). The commenters noted that NQF 0028 goes beyond documenting 
smoking status to encourage cessation counseling. Consequently, the 
commenters suggested that we could alleviate reporting burdens and 
workflow issues by agreeing on a single tobacco use value set for all 
meaningful use objectives and clinical quality measures.
    Response. We thank commenters for their feedback and agree with 
much of what was said. We have now provided mappings to a set of SNOMED 
CT[supreg] concepts to assist the developers and implementers of EHR 
technology in the implementation of this requirement. We have also 
expanded the number of available concepts from six to eight in order to 
better reflect the way that many EPs capture smoking status. We clarify 
that the eight smoking statuses provided here need not be the exact 
words that are displayed for a user. Rather, any appropriate concept or 
concepts that the EHR technology displays for an EP may be mapped to 
one or more compatible smoking status codes, but if an alternative 
approach is used, the EHR technology must ultimately be able to record 
the semantic representation of a patient's smoking status in at least 
one of these eight status. Further, these eight codes must be used as 
specified elsewhere in this final rule when smoking status is 
referenced, such as within the transitions of care certification 
criterion. We clarify that smoking status includes any form of tobacco 
that is smoked, but not all tobacco use. Working with CMS, we have 
added these eight value sets to NQF 0028, so that (for the portion of 
NQF 0028 that captures smoking status) an EP or EH can capture this 
data only once rather than twice.

------------------------------------------------------------------------
                  Description                      SNOMED CT[supreg] ID
------------------------------------------------------------------------
Current every day smoker.......................                449868002
Current some day smoker........................          428041000124106
Former smoker..................................                  8517006
Never smoker...................................                266919005
Smoker, current status unknown.................                 77176002
Unknown if ever smoked.........................                266927001
Heavy tobacco smoker...........................          428071000124103
Light tobacco smoker...........................          428061000124105
------------------------------------------------------------------------

    As described above, these eight smoking statuses have been provided 
in order to permit EHR technology developers to incorporate the capture 
of smoking status as part of an efficient, fluid user experience. We 
have added two smoking statuses to the standard adopted in Sec.  
170.207(h) in order to better reflect clinically relevant differences 
between smokers, and provide options that may in fact be preferable to 
many providers, while retaining the existing six codes from the 2011 
Edition certification program in order to give EHR developers the 
option of migrating to the newer codes over time. ``Light smoker'' is 
interpreted to mean fewer than 10 cigarettes per day, or an equivalent 
(but less concretely defined) quantity of cigar or pipe smoke. ``Heavy 
smoker'' is interpreted to mean greater than 10 cigarettes per day or 
an equivalent (but less concretely defined) quantity of cigar or pipe 
smoke. Since many EHR technology developers have asked questions about 
this certification criterion, we offer the following example of an 
implementation that would be acceptable: an EP user of CEHRT ABC is 
taking the social history from patient XYZ. The EP is using a template 
for facilitated data entry in the CEHRT. The template has options such 
as ``smoker'' and ``nonsmoker.'' When the EP selects ``smoker,'' 
several other options become available including ``1-9 cigarettes/day'' 
and ``\1/2\ pack/day'' and ``1 pack/day'' and ``greater than 1 pack/
day.'' The EP selects ``1 pack/day,'' and moves on to other parts of 
the discussion with the patient. The CEHRT records (and displays) ``1 
pack/day'' and maps this internally as SNOMED CT[supreg] concept 
428071000124103 (``Current Heavy Smoker''). When a transition of care/
referral summary is generated for exchange, the SNOMED CT[supreg] 
concept must be included, as well as the text description ``heavy 
smoker'' (``1 pack/day'' and any other metadata could also be included 
as appropriate). Note that ``heavy smoker'' is not the only concept 
that is appropriate here, and we leave the decision regarding which of 
the eight codes is the most accurate descriptor of clinical intent to 
the judgment of those implementing the form, template, or other EHR 
data capture interface. In the case above, the developer of the 
template chose ``heavy smoker'' rather than ``current every day 
smoker'' because this is more clinically relevant with respect to the 
patient's risk for disease and the urgency of intervention. 
Nonetheless, ``Current every day smoker'' would have been technically 
acceptable and would therefore be acceptable for certification testing.
     Patient List Creation (proposed ``Patient Lists'' and 
``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)(14) (Patient list creation).
------------------------------------------------------------------------

    We proposed the 2014 Edition EHR certification criteria for 
``patient'' lists and ``patient reminders'' as ``unchanged'' 
certification criteria (as described in section III.A.11 of this 
preamble). In our proposal for the ``patient reminders'' certification 
criterion, we clarified and emphasized 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 noted that, consistent with 
patient communication preferences, we would

[[Page 54206]]

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. Last, we stated that 
we anticipated that other modes of communication would be available and 
may be preferred by patients for sending patient reminders, such as 
regular mail.
    We also proposed the ``patient lists'' certification criterion for 
the 2014 Edition EHR certification criteria as unchanged and without 
any refinements. The proposed ``patient lists'' certification criterion 
specified that EHR technology 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.
    Comments. One commenter agreed that being able to provide 
information to patients in the manner they prefer is important, but 
expressed concern about the adoption of the ``patient reminder'' 
certification criterion for Stage 2. They stated that their comments to 
CMS indicated that non-CEHRT systems that provide the actual reminders 
should be exempt from certification criteria.
    Response. This adopted 2014 Edition EHR certification criterion 
focuses on an EHR technology's capability to electronically create a 
patient reminder list for preventive or follow-up care according to 
patient preferences based on certain data elements. It does not focus 
on the IT systems that may be used to provide the reminders.
    Comment. A commenter suggested that the proposed ``patient 
reminders'' certification criterion include the element of when 
patients were last seen so that the EHR technology user can perform 
date range searches (i.e., diabetics not seen for 6 months).
    Response. We agree with this commenter's suggestion. Although we 
proposed the ``patient reminders'' certification criterion as an 
unchanged certification criterion, we believe this commenter has 
identified a critical flaw in the way the certification criterion is 
currently expressed. We interpret the commenter's request to mean that 
as an EHR technology user they would want to be able to create a 
patient reminder list on an ad-hoc basis according to at least the 
parameters specified in the certification criterion. As we considered 
this comment and analyzed the way the certification criterion is 
specified, we realized that it does not necessarily express this 
outcome, which was our intent for this certification criterion. Rather, 
we believe that as currently worded, the certification criterion could 
permit an EHR technology developer to design and get EHR technology 
certified that could only permit a user to generate patient reminder 
lists based on a few static reports. We believe that kind of outcome is 
unacceptable and does little to support an EP's ability to engage in 
follow-up care communications--especially if the EP wants to focus on a 
patient population that should be supported by virtue of certification, 
but is not because the EP cannot dynamically (i.e., on-the-fly) and 
while interacting with the EHR technology add or subtract certain 
factors from the underlying query. Additionally, in the continued 
context of reducing redundancy and regulatory burden as well as our 
continued efforts to improve the clarity of our regulation, we compared 
this certification criterion with the ``patient lists'' certification 
criterion (proposed at Sec.  170.314(a)(14)) and have determined that 
these two certification criteria should be combined into a single 
certification criterion. At a high-level, both require EHR technology 
to be able to electronically create a list of patients. However, where 
the ``patient lists'' certification criterion includes more specific 
filtering, the ``patient reminders'' does not, but it does include two 
additional data elements (medication allergies, patient's communication 
preference).
    Accordingly, we have finalized a single certification criterion 
that merges the strengths of each certification criterion as well as 
this commenter's suggestion for a date/time component. We believe this 
single certification criterion will be clearer for EHR technology 
developers and will more clearly express the kind of capability EHR 
technology must include in order to be certified. Within the 
certification criterion, we interpret ``select'' to mean filter and 
``sort'' to mean that the user gets to provide a sequence or range 
(e.g., by hemoglobin A1C levels). For consistency purposes, we have 
included the same revisions we have made in other certification 
criteria and state ``each one and at least one combination* * *'' to 
indicate that EHR technology must be able to create a list based on 
each element separately as well as based on at least one combination of 
any of the data. Finally, we seek to indicate our expectation that for 
the next EHR certification criteria edition, we would propose that EHR 
technology be able to initiate a patient reminder based on a patient's 
identified communication preference (where it is electronically 
feasible).
    Comment. A commenter asked that we provide additional guidance as 
to what constitutes ``patient preference.''
    Response. In the Proposed Rule we indicated that patient preference 
constituted the communication method by which the patient preferred to 
be contacted. This could include but is not limited to: email, secure 
messaging, regular mail, phone, and text message. EHR technology 
designed for an ambulatory setting must support an EP, EH, or CAH's 
ability to record a patient's communication preference, which we 
believe is now explicitly clear in the revised combined certification 
criterion. We encourage EHR technology developers to include a variety 
of the most common choices patients may select.
    Comments. Many comments were not focused on the capability that EHR 
technology would need to provide a user in order to meet the 
certification criterion, but on: how a reminder needed to be provided; 
what an acceptable reminder would be; whether the purpose of the 
reminder and its clinical relevance mattered; how a reminder could be 
reported; and that exclusions to the meaningful use objective and 
measure should be established for specialists.
    Response. All of these comments go beyond the scope of capabilities 
for which EHR technology certification is required.
     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).
------------------------------------------------------------------------

    We proposed a ``drug-drug, drug-allergy interaction checks'' 
certification criterion (Sec.  170.314(a)(2)) that included the 
recommendations of the HITSC to eliminate for certification the ability 
for EHR technology to permit users to adjust drug-allergy interaction 
checks, replace the term ``real-time'' with ``before the order is 
executed,'' revise the language to specify that notifications should 
happen during CPOE, specify that the level of severity of the 
notifications is what can be adjusted, and limit the ability to make 
adjustments to an identified set of users or available as a system 
administrative function. We also expressed agreement with the HITSC 
that drug-allergy

[[Page 54207]]

contraindications should be interpreted to include adverse reaction 
contraindications. We also clarified that the phrase ``identified set 
of users'' means 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. We noted that 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).
    Comments. Of the comments received on this proposed certification 
criterion, many supported it as proposed. A set of commenters 
recommended that we change the language at the beginning of the 
certification criterion to state, ``Before an order is being completed 
and acted upon * * *'' instead of ``Before a medication order is placed 
* * *.'' They noted that this change would clearly define the 
interaction notification's ``real-time'' nature and make it clear that 
the licensed provider would need to see the interaction intervention 
and be able to act on it. Similarly, with respect to this proposed 
language, a commenter questioned how EHR technology workflow would be 
tested to know if the check is completed before the order is entered.
    Response. We appreciate this detailed feedback and agree with 
commenters' revisions. We have modified this language in the 
certification criterion to reflect the recommended text by replacing 
``placed'' with ``completed and acted upon.'' We believe that this 
revision should also address the testing timing question raised by the 
last comment. Additionally, due to this revision, we removed ``at the 
point of care'' from the certification criterion's language because we 
believe the prior clarification appropriately indicates when the drug-
drug or drug-allergy interaction needs to be indicated to a user.
    Comments. Some commenters focused on our proposal to not include in 
the 2014 Edition EHR certification criterion the capability for EHR 
technology to permit users to adjust drug-allergy interaction checks. 
One commenter stated that it was unclear in the Proposed Rule whether 
this also applied to drug-drug interactions. The commenter appeared to 
presume that we were also applying this proposal to drug-drug 
interactions because the commenter explained that such a limitation 
would not comport with the current state of interaction databases 
available in practice. Specifically, the commenter stated that current 
systems, especially those based on shared excipients (i.e., substances) 
or other components across formulations, are often strongly biased 
toward sensitivity (i.e., an alert is generated even when a low 
probability of a clinically significant interaction exists). As a 
result, the specificity of alerts, and hence their positive predictive 
value, is low. The commenter stated that the phenomenon of ``alert 
fatigue'' is well-documented and the inflexible approach promoted by 
the Proposed Rule contributes to this phenomenon. Similarly, another 
commenter expressed concern that EHR technology developers may 
interpret this section to prohibit physicians in small practices from 
tailoring alerts to fit their practice. The commenter also noted that 
alert fatigue is a well-known problem and expressed concern that our 
proposal may lead to a diminution in safety through alert fatigue 
rather than an improvement.
    One commenter stated that we should reword paragraph (ii)(B) to 
ensure that EHR technology has the capability to permit a limited set 
of users to make adjustments to the severity levels of drug-allergy 
interaction checks, in addition to drug-drug. In contrast to this 
position, another commenter expressed agreement with the proposed 
change from the 2011 Edition EHR certification criterion to the 2014 
Edition EHR certification criterion and stated that adjusting 
notifications of drug-allergy interaction checks is inconsistent with 
clinical work and confusing in the current certification process.
    One commenter contended that providers should retain the ability to 
define thresholds for any alert which they would like to receive. 
Without this capability, the commenter argued EPs are liable to 
experience ``alert fatigue'' due to high ``noise to signal''; that is, 
the presentation of a large number of alerts which are simply 
irrelevant to the care which the physician is providing.
    Response. On our proposal to remove the drug-allergy adjustment 
capability expressed in the 2011 Edition version of this certification 
criterion, we believe that the negative reaction expressed is due to 
misinterpreting our proposal. We are fully aware of the concerns 
expressed regarding alert fatigue. The certification criterion 
addresses this concern by requiring that EHR technology include the 
capability to adjust the severity level of interventions provided for 
drug-drug interaction checks. This capability should allow for EPs, 
EHs, and CAHs to find an appropriate balance with respect to the 
frequency of interventions. In regards to severity level adjustments 
for drug-allergy interactions, the proposal in question sought to 
remedy a concern raised by the HITSC and other stakeholders after the 
S&CC July 2010 Final Rule that certification focused on ensuring that 
EHR technology had the capability to adjust the severity of drug-
allergy interventions when there were few clinical reasons to do so. 
Unlike drug-drug alerts, the rationale we provided was that it is 
important for drug-allergy interventions to be indicated and continue 
to believe that this will generally be the case. Thus, we have 
finalized the ``adjustments'' paragraph (Sec.  170.314(a)(2)(ii)) as 
proposed and decline to include for the purposes of certification a 
severity adjustment requirement for drug-allergy interventions.
    Comment. A commenter requested clarification on paragraph 
(a)(2)(ii)(A). They asked whether the certification criterion would 
require that the severity level be able to be changed from what a 
pharmaceutical company's research recommended. Additionally, they asked 
if we were suggesting that a provider or person with appropriate 
administrative privileges be able to downgrade that alert level to 
moderate or minor or simply that they be able to modify the type of 
interaction that triggers a warning. They concluded by stating that a 
valid clinical use case is that many commonly prescribed combinations 
are labeled as having a potential drug-drug reaction and the provider 
wants to prevent being alerted each time.
    Response. The certification criterion does not specifically address 
a particular drug-drug intervention. Rather it is meant to ensure that 
EHR technology that meets this certification criterion includes a 
capability that permits certain users to adjust the severity level of 
interventions. So in response to the commenter's question, this 
certification criterion is meant to make it possible for a health care 
provider to reduce the frequency of/threshold for certain 
interventions.
    Comments. A commenter asked that we clarify the definition of 
``adverse reaction contraindication.'' Additionally, they asked what 
vocabulary or vocabulary subsets would be used for the input of the 
adverse reaction and whether EHR technology would need to be able to 
distinguish between alerts for allergy contraindications and alerts for 
adverse reaction contraindications. They stated that many EHR 
technologies are not configured to register other reactions that are 
not true allergies. A second commenter stated that we should recommend 
specific vocabularies/codes and referenced RxNorm for the drugs as well 
as the drugs to which the patient is allergic and SNOMED CT[supreg] for 
the type of allergy.

[[Page 54208]]

    Response. We agree that there is a clinical distinction between 
``adverse reaction'' and ``allergic reaction,'' and we hope to be able 
to support such a distinction in future rulemaking. However, for the 
purpose of this certification criterion, we do not make a clinical 
distinction between ``medication adverse reaction'' and ``allergic 
reaction.'' In many cases, the use of a medication will be 
contraindicated because a patient has a history of an adverse reaction 
to the medication. While this may be clinically distinct from an 
allergic (antibody-mediated hypersensitivity) reaction, it is a 
contraindication nonetheless. The same clinical vocabulary (e.g., 
RxNorm) that would be used for allergic reactions will be required for 
adverse reactions.
    Comment. A commenter requested that we clarify the meaning of 
``identified set of users'' with respect to the severity adjustments. 
They asked whether each facility would have the ability to define this 
for its users.
    Response. As stated in the Proposed Rule, identified set of users 
means 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. With respect to the follow-up question, EHR 
technology certified to this certification criterion would need to 
enable certain users to be assigned with the ability to adjust the 
severity levels of interventions provided for drug-drug interactions. 
How that capability is subsequently implemented and used is not within 
the scope of certification and we are unable to determine what the 
commenter had in mind when they referenced ``each facility.''
    Comment. A commenter requested that we clarify the alignment of 
drug-drug, drug-allergy alerts with CDS. Specifically, they asked us to 
confirm that the proposed adoption of the HL7 ``Infobutton'' standard 
for retrieving referential information would not apply to the drug-
drug, drug-allergy alerts certification criterion.
    Response. As with the past edition of EHR certification criteria, 
the drug-drug, drug-allergy certification criterion is a separate and 
distinct certification criterion from the CDS certification criterion. 
We did not propose the adoption of the HL7 Infobutton standard for this 
certification criterion and its use would not be necessary to 
demonstrate compliance with this certification criterion.
    Comment. A commenter agreed with the certification criterion but 
recommend that we consider expressing additional capabilities to 
support food-drug interactions (i.e., changes in how medications work 
caused by food, caffeine or alcohol).
    Response. We appreciated this comment but decline to make such 
changes at this time. EHR technology developers are encouraged and free 
to include this functionality which would be outside the scope of 
certification. We will keep this addition in mind as we work with the 
HITSC on the next edition of EHR certification criteria.
    Comment. A commenter suggested that it is important to specify in 
this certification criterion and the CDS certification criterion that 
EHR technology be able to provide timely access to FDA Drug Safety 
Alerts (Boxed Warnings, Risk Evaluation and Mitigation Strategies 
(REMS) programs and Drug Safety Alerts). Further, they stated that 
these FDA Drug Safety Alerts include drug-drug interactions, allergic 
reactions and critical safety information directly related to clinical 
decision making.
    Response. We wholeheartedly agree with this comment and encourage 
EHR technology developers to make FDA Drug Safety Alert information 
accessible to health care providers as part of their normal workflows. 
We believe this capability and the availability of such information is 
best addressed by the specific capability included in the CDS 
certification criterion related to referential CDS. Additionally, as 
part of an EHR technology's CDS we could see this capability being 
enhanced through the use of the HL7 Context-Aware Knowledge Retrieval 
(``Infobutton'') Standard so that EHR technology could gain access to 
new REMS/drug alerts on an ongoing and dynamic basis.
     Demographics

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Record the following demographics: preferred language; sex; race;
 ethnicity; date of birth; and for the inpatient setting only, date and
 preliminary cause of death in the event of mortality in the EH or CAH.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(a)(3) (Demographics).
------------------------------------------------------------------------

    We proposed to adopt the ISO 639-1 code set as the vocabulary 
standard for preferred language \18\ based on the recommendation of the 
HITSC. We also proposed to adopt ICD-10-CM for recording the 
preliminary cause of death, stating that its use will permit additional 
specificity.
---------------------------------------------------------------------------

    \18\ https://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.
---------------------------------------------------------------------------

    As for the Office of Management and Budget (OMB) standards for the 
classification of federal data on race and ethnicity, we noted 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 proposed 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 proposed to revise the certification 
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.
    We received comments that generally applied to the certification 
criterion and comments that focused on each of the specific data 
elements in the certification criterion. We have categorized and 
respond to these comments in a similar manner.
    Comments. A few commenters expressed general agreement with the 
proposed certification criterion, while a commenter recommended that 
this certification criterion should remain unchanged.
    Response. We appreciate the commenters support for the proposed 
certification criterion and our adopting it as a revised certification 
criterion for the reasons discussed below.
Preferred Language
    Comments. Some commenters expressed support for the ISO 639-1 
standard. One commenter recommended the ISO 639-3 standard as being 
more comprehensive. Another commenter suggested adopting the 2009 IOM 
recommendations on how to ask for language data. Multiple commenters 
suggested that we should use ISO 639-2. The HITSC clarified in their 
comments that their recommendation to ONC was that preferred language 
should be expressed by constraining 639-2 to those that are in ISO 639-
1, noting that 639-1 includes only active languages, while 639-2 
includes languages no longer in use. A few commenters asked for 
clarification as to whether all languages listed in the standard must 
be visible for a customer to select.
    Response. We agree with the clarification provided by the HITSC. 
Accordingly, we are adopting ISO 639-

[[Page 54209]]

2 constrained by ISO 639-1. This will constrain ISO 639-2 to only the 
active languages in ISO 639-1, but will permit the use of the alpha-3 
codes of ISO 639-2. As such it is a better approach than adopting 
solely ISO 639-2 or 639-1. We believe that ISO-639-3 exceeds the 
baseline we seek to specify for certification and have not adopted it. 
Last, in response to the commenters' request for clarification, EHR 
technology is not required to display all the languages of the standard 
to meet the certification criteria. But, it must be capable of 
recording a patient's language according to any of the languages in the 
standard.
Race and Ethnicity
    Comments. Some commenters suggested the use of other vocabulary 
standards such as CDC vocabulary standards, standards based on the 2009 
IOM recommendations, or the HHS survey standards recently adopted by 
HHS in compliance with ACA section 4302. A few commenters recommended 
that EHR technology only record the ``primary'' race and ethnicity 
value as identified by the individual and that the eligible 
professional regards as clinically significant because the commenters 
contended that most EHR technology is unable to accommodate multiple 
values for patients. Commenters also suggested that a multiple question 
approach for patients that may wish to designate multi-race or 
ethnicity be acceptable. A commenter asked for clarification as to 
whether the data elements must be stored as aggregated to the standard 
(i.e., it must be done this way), or could it be aggregated to the 
standard by a third party and not the EHR technology. Commenters also 
requested clarification as to how the OMB race and ethnicity codes must 
be used in conjunction with providing patients the option to not 
respond to questions regarding race and ethnicity.
    Response. The OMB race and ethnicity codes constitute a government-
unique standard. We have adopted this standard because it provides an 
easily understood structure and format for electronically transmitting 
the data elements identified by the associated MU objective. The 
standard is readily available, was previously adopted as part of the 
2011 Edition EHR certification criteria and, in general, provides the 
best standard to use to support our policies goals. Therefore, we 
believe this standard is more appropriate than the alternative CDC, IOM 
and HHS survey standards.
    EHR technology must be capable of meeting the standard and the 
other requirements of the certification criterion in order to be 
certified. As such, EHR technology must record race and ethnicity 
according to the OMB standard by providing the option for one or more 
racial designations to be selected in a manner consistent with the 
standard. EHR technology must also be capable of aggregating/mapping 
more granular race and/or ethnicity data to the minimum race and 
ethnicity categories in the standard if an EHR technology developer 
implements such an approach. Additionally, to meet the certification 
criterion, EHR technology must, in conjunction with complying with the 
OMB standard, be capable of recording that a patient declined to 
specify his or her race and/or ethnicity. As noted in the Proposed 
Rule, this ensures inclusion of such patients in the numerator of the 
MU percentage-based measure.
Gender/Sex
    Comments. Commenters requested clarification regarding the data 
element ``gender,'' asking whether it was intended that sex and/or 
gender be collected.
    Response. We have clarified that the certification criterion 
requires the recording of sex, which is consistent with the change made 
by CMS for its MU objectives and measures.
    Comments. Commenters recommended that gender identity and/or sexual 
orientation be recorded.
    Response. We appreciate the submission of these comments, but the 
certification criterion includes only data required to support the 
associated MU objective and measure. Therefore, we decline to include 
these additional data elements.
Preliminary Cause of Death
    Comments. A few commenters stated that ICD-10, not ICD-10-CM, was 
the appropriate standard. A commenter stated that the preliminary cause 
of death should be in the same vocabulary standard as the problem list 
(i.e., SNOMED CT[supreg]). Conversely, many commenters stated that no 
standard should be required. These commenters suggested that a text 
entry for ``preliminary cause of death'' is most appropriate. These 
commenters stated that this would avoid the need for provider education 
on the use of the standard, the difficulty in narrowing down the 
standard code list to one that might be usable for coding the 
preliminary cause of death, and workflow changes. Commenters stated 
that the significance of the preliminary cause of death being a 
codified value is not of great importance when compared to the final 
cause of death determined by a coroner through autopsy or as may be 
required for death certificate purposes. Commenters further stated that 
the information required by this capability is preliminary and by its 
very nature will not carry the same weight as a later more final 
determination. Overall, commenters questioned the cost and burden 
involved in collecting this information in accordance to a standard 
versus any perceived benefit as a means of meeting this certification 
criterion.
    Response. We agree with the commenters that the burden and costs, 
as outlined by commenters, outweigh the potential benefits of recording 
the preliminary cause of death in accordance with a standard. 
Therefore, we are not adopting a standard for this data element and 
free text entry will continue to be permitted.
    Comments. A few commenters stated that the preliminary cause of 
death should not be collected as a data element. A commenter stated 
that if EHs are not required to record a preliminary cause of death 
within a specified timeframe from the death, then the commenter 
requested confirmation that deceased patients must simply have a 
preliminary cause of death recorded in their charts in order to be 
included in the MU measure. Otherwise, the commenter stated that it was 
unclear how EHs would be expected to report on patients who died near 
the end of the reporting period and have not yet had a cause of death 
recorded. Commenters also requested clarification for the proposed 
exclusion that specified if a demographic element is prohibited to be 
captured by state law, that the EP or EH is excluded from capturing 
that demographic. Commenters asked if it was acceptable to note once in 
CEHRT the state law prohibition or if it needed to be recorded for each 
patient.
    Response. Collection of preliminary cause of death data supports 
the associated MU objective and measure and, therefore, EHR technology 
must be capable of collecting it. Comments on when the preliminary 
cause of death must be recorded and the measure exclusion are beyond 
the scope of this rulemaking. We direct commenters to the Stage 2 final 
rule for a discussion of the MU objective and measure and responses to 
these comments.
Additional Data Elements
    Comments. Commenters recommended a wide range of additional data 
elements for inclusion in the certification criterion based on the 
rationale that the capturing of the data elements could contribute to

[[Page 54210]]

identifying health disparities and potential reasons for the health 
disparities. The recommended additional data elements are: residency 
information (state, county, zip code, street address); country of 
origin; nationality; type of employment; primary place of employment; 
highest education level completed; and hobbies.
    Response. We appreciate the recommendations for inclusion of 
additional data elements, but have chosen to limit this certification 
criterion's scope to only include the data required to support the 
associated MU objective and measure. Therefore, we decline to include 
any of the recommended additional data.
     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).
------------------------------------------------------------------------

    In the Proposed Rule, we proposed to replace the terms ``modify'' 
and ``retrieve'' in the certification criterion with ``change'' and 
``access,'' respectively. Consistent with the interpretation we 
provided in the S&CC July 2010 final rule, we also reiterated and 
clarified that ``longitudinal care'' is used to mean over an extended 
period of time. For the ambulatory setting, we stated that this would 
be over multiple office visits. For the inpatient setting, we stated 
that 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. We noted that the HITSC suggested 
we consider longitudinal care to cover multiple hospitalizations, but 
we stated that 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. We stated 
that our clarification of the meaning of longitudinal care also applies 
to its use in the certification criteria for medication lists and 
medication allergy lists. We further stated that if we were to 
interpret 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 proposed to adopt the International Release January 2012 version 
of SNOMED CT[supreg].\19\ We stated that we agreed with the HITSC that 
the use of ICD-9-CM should no longer be required due to the pending 
move to ICD-10-CM, but also stated that it would be inappropriate to 
require the use of ICD-10-CM for problem lists. We stated that SNOMED 
CT[supreg] (and not ICD-10-CM) would be required for calculation of 
CQMs and proposed only SNOMED CT[supreg] as the appropriate standard 
for the recording of patient problems in a problem list. We noted that 
this proposal did not, however, preclude the use of ICD-10-CM for the 
capture and/or transmission of encounter billing diagnoses.
---------------------------------------------------------------------------

    \19\ https://www.nlm.nih.gov/research/umls/licensedcontent/snomedctfiles.html.
---------------------------------------------------------------------------

    Comments. One commenter asked why it is necessary to specify a 
vocabulary for the problem list within an EHR. The commenter agreed 
with the necessity of SNOMED CT[supreg] for exchange, but suggested 
that we permit the flexibility to either use the vocabulary internally 
or map to it when exchanging information.
    Response. We agree with this commenter that SNOMED CT[supreg] is 
the best vocabulary to use in those certification criteria that focus 
on electronic health information exchange. It is necessary that we 
specify a vocabulary for the problem list within EHR technology because 
it supports the current requirement that EPs, EHs, and CAHs need to 
meet to demonstrate MU. Since CMS's initial proposal for meaningful use 
Stage 1 (75 FR 1860), it has explicitly prioritized recording problems 
in the adopted standards. Further, at 75 FR 44337, CMS states ``[w]e 
further specify that in order to meet this objective and measure, an 
EP, eligible hospital, or CAH must use the capabilities Certified EHR 
Technology includes as specified and standards at 45 CFR 170.302(c)'' 
which is the 2011 Edition EHR certification criterion for problem list 
that requires EHR Technology be able to record problems in either ICD-9 
or SNOMED CT[supreg] in order to be certified. We also responded to 
similar questions such as this in our S&CC July 2010 final rule (75 FR 
44603).'' In the Proposed Rule, we proposed to only permit EHR 
technology to be certified to record, change, and access problems in 
SNOMED CT[supreg] because we believe that it is the best vocabulary 
standard for the representation of clinical data and should be used to 
represent problems beginning in FY/CY 2014. We clarify that this 
certification criterion does not preclude the use of interface terms, 
local terms, or other terms from being displayed to a health care 
provider in lieu of SNOMED CT[supreg] to find, select, or view a 
patient's problem list. However, if such an approach is taken, the EHR 
technology must ultimately be able to record the semantic 
representation of the problem list in SNOMED CT[supreg]. For example, 
if a user of a given EHR technology is using a set of interface terms 
or any other clinical vocabulary that has been mapped to SNOMED 
CT[supreg], this user may perform a search for a term that represents 
the patient's problem, select the appropriate term, and ``save'' that 
term to the patient's problem list, where it may be displayed. The EHR 
technology is required to record the problem in SNOMED CT[supreg] 
because this is the requirement described above for alignment with the 
EHR Incentive Programs. For information exchange, the EHR technology 
must send the problem in SNOMED CT[supreg] because this is the 
requirement of other certification criteria specified elsewhere in this 
final rule.
    Comments. Commenters expressed support for use of only SNOMED 
CT[supreg] and stated that it is the best standard for optimal clinical 
data capture and reuse of information captured in problem lists. Some 
of these commenters stated that the use of a classification system such 
as ICD-10-CM limits data analysis for clinical research, quality of 
care measurement and communication between care providers and patients. 
These commenters stated that ICD-10-CM is a classification, and it is 
still designed to capture diagnoses and reasons for encounters, not 
every ``problem.'' The commenters recommended that ICD-10 CM and PCS, 
where appropriate, should continue to be required for billing purposes. 
The commenters also recommended that EHR technology developers should 
not utilize the problem list for billing since billing practices and 
national coding guidelines require that claims only reflect those 
conditions attended to during the encounter being billed and the 
problem list includes all conditions that may or may not be active and 
may or may not have been attended to during the encounter.
    Conversely, commenters were concerned that they would face 
additional costs and burden by having to adopt and implement SNOMED 
CT[supreg] as well as ICD-10-CM or ICD-9-CM until ICD-10-CM is required 
for implemented. Commenters also stated that SNOMED CT[supreg] is not 
currently in widespread use among hospitals. For these reasons, 
commenters suggested that they be able to use ICD-10-CM for problem 
lists in lieu of adopting

[[Page 54211]]

SNOMED CT[supreg]. A few commenters suggested this same approach, but 
also recommended signaling a move to adopt only SNOMED CT[supreg] for 
the next edition of certification criteria. One commenter suggested 
that we pursue development of a national problem list and centralized 
services developed and maintained by a cooperative partnership between 
the public and private sectors.
    Response. We appreciate the comments supporting the use of only 
SNOMED CT[supreg]. We agree with commenters that SNOMED CT[supreg] 
provides much better clinical data capture than ICD-10 CM, ICD-9, and 
ICD-10 PCS, while ICD-10-CM is more appropriate for encounter billing 
purposes. With the adoption of the 2011 Edition EHR certification 
criteria we permitted the use of either ICD-9-CM or SNOMED CT[supreg] 
to demonstrate compliance with this certification criterion. In our 
response to comments in the S&CC July 2010 final rule, we stated that a 
single standard for clinical information would be desirable in the long 
term. While SNOMED CT[supreg] may not currently be used by a majority 
of EPs, EHs, and CAHs, we cannot expect its usage to dramatically 
increase without some encouragement. By requiring EHR technology to be 
certified to this standard, soon all EPs, EHs, and CAHs will have the 
capability to record patient problems with SNOMED CT[supreg]. This will 
improve the semantic interoperability of clinical systems, improve the 
accuracy of data capture, and may in fact provide a better transition 
to ICD-10-CM. With mapping tools from SNOMED CT[supreg] to ICD-10-CM, 
available from the National Library of Medicine, we anticipate that 
clinical users will be able to use a clinician-friendly terminology 
(SNOMED CT[supreg]) while administrative users can interact with ICD-
10-CM, an administrative terminology. Guidance from the HITSC and our 
own research has indicated a clear need for clinicians to interact with 
SNOMED CT[supreg] rather than ICD-10-CM, and we view this as an 
opportunity to improve the usability, accuracy, and safety of problem 
list management.
    The development of a national problem list and centralized services 
is beyond the scope of our certification program and this rule, but we 
will consider this as we look to how ONC and other Federal agencies can 
best prepare the industry for successful EHR technology development and 
implementation.
    Comment. A commenter stated that while SNOMED CT[supreg] is the 
appropriate standard for clinical use (as opposed to ICD for billing 
and epidemiological purposes), clinicians' experience with this 
standard is limited, and therefore suggest that we consider requiring 
the addition of a mapping tool within the EHR technology.
    Response. We agree with this commenter, as stated above, that 
SNOMED CT[supreg] is the appropriate standard for clinical use, and we 
agree that mapping from SNOMED CT[supreg] to appropriate administrative 
codes such as ICD-10-CM will be necessary. The National Library of 
Medicine is developing mapping tools, and such mappings are also 
available from commercial vocabulary vendors. We do not, however, 
intend to require the use of such mappings as part of this 2014 Edition 
EHR certification criterion.
    Comment. A commenter suggested that for dental systems, SNODENT, 
the dental subset of SNOMED CT[supreg], is the appropriate code set for 
the recording of dental patient problems in a problem list.
    Response. While the commenter may be correct in regards to SNODENT, 
certification to this certification criterion requires that EHR 
technology be able to record a patient problem list in accordance with 
SNOMED CT[supreg]. It is our understanding that novel SNODENT content 
produced by the American Dental Association will be incorporated into 
SNOMED CT[supreg] or the U.S. Extension to SNOMED CT[supreg]. This will 
cause all dental diagnoses to be available in SNOMED CT[supreg]. We 
believe this will be beneficial to EPs that rely more on SNODENT. We 
also encourage EHR technology developers to include SNODENT in EHR 
technology when it would be beneficial to providers.
    Comments. Commenters stated that SNOMED CT[supreg] codes should not 
be required for display in the EHR. Commenters explained that an EP, 
EH, or CAH should be able to use whichever code set they prefer for 
display.
    Response. We agree with commenters. As noted above, SNOMED 
CT[supreg] codes are not required for display in the EHR technology in 
order for it to meet this certification criterion.
    Comments. Commenters stated that the SNOMED CT[supreg] standard 
should include the U.S. Extension to SNOMED CT[supreg] (citation to 
National Library of Medicine) and apply to all uses of the standard in 
certification criteria. Commenters stated that the US extension 
includes terms important for the MU program, specifically those used in 
the US but not found in the SNOMED CT[supreg] International Release 
(e.g. for adopting pre-coordinated terms in SNOMED CT[supreg] to match 
those found in ICD-10-CM).
    Response. We agree with the commenters that, although not proposed 
for use, the U.S. Extension is necessary to support the MU program and, 
therefore, have adopted it in conjunction with SNOMED CT[supreg].
    Comments. Commenters stated that to accommodate the regular updates 
that occur to SNOMED CT[supreg] we should establish a mechanism for 
updating the minimum regulatory standards. Alternatively, a commenter 
suggested we simply adopt ``SNOMED CT[supreg]--current International 
release'' as the vocabulary standard.
    Response. We appreciate the suggestions by commenters. We have 
established a process for adopting certain vocabulary standards, 
including SNOMED CT[supreg], which permits the use of newer versions of 
those standards than the one adopted in regulation. We refer readers to 
section IV.B for a discussion of ``minimum standards'' code sets and 
our new more flexible approach for their use in certification and 
upgrading certified Complete EHRs and certified EHR Modules. Readers 
should also review Sec.  170.555, which specifies the certification 
processes for ``minimum standards'' code sets. In response to the 
commenter's suggestion that we adopt in regulation ``the current 
release of SNOMED CT[supreg]'' as the standard, we refer the commenter 
to section III.A.5 earlier in this preamble. This section explains why 
we cannot take such an approach.
Longitudinal Care
    Comments. Commenters expressed agreement with our clarification of 
the meaning of the term ``longitudinal care'' for the purposes of this 
certification criterion and the certification criteria for medication 
lists and medication allergy lists. However, commenters recommend that 
we eliminate the term ``longitudinal care'' from this certification 
criterion and the ``medication list'' and ``medication allergy list'' 
certification criteria. Commenters stated that our use of the term as 
described in the Proposed Rule was inconsistent with the common 
understanding of the term among the health care community. These 
commenters stated that ``longitudinal'' should be reserved for 
referring to care provided across care settings and across episodes or 
encounters of care. Some commenters suggested replacing the term with 
``encounter of care,'' ``episode of care,'' or ``durational care.'' A 
commenter suggested that for hospital patient problems that are 
longitudinal across encounters be acceptable given ONC's proposed 
definition of longitude for hospital inpatients of an admission. This 
commenter noted that some EHRs are designed such that problems as 
clinical data objects are distinct from

[[Page 54212]]

encounter diagnosis, and are longitudinal in concept and design.
    Response. We agree with commenters that our use of longitudinal 
care in this certification criterion and in the certification criteria 
for medication lists and medication allergy lists has the potential to 
create confusion. Accordingly, we have replaced this term in the 
certification criteria with the descriptions we provided in the 
Proposed Rule and with a terminology change recommended by commenters. 
Specifically, for the ambulatory setting, we have replaced the term 
``longitudinal care'' with ``over multiple encounters.'' We believe 
using ``encounters'' instead of ``office visits'' is a more clinically 
appropriate. We note that this revision has no substantive impact on 
current or future testing and certification processes. For the 
inpatient setting, we have replaced the term ``longitudinal care'' with 
``duration of an entire hospitalization,'' which would continue to 
include situations where the patient moves to different wards or units 
(e.g., emergency department, intensive care, and cardiology) within the 
hospital during the hospitalization and continue to maintain that it 
would not cover multiple hospitalizations for the purpose of 
certification. As we stated above and in the Proposed Rule, capturing 
patient problems over multiple hospitalizations 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.
     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).
------------------------------------------------------------------------

    We proposed to adopt a revised clinical decision support (CDS) 
certification criterion as part of the 2014 Edition EHR certification 
criteria. We noted in the Proposed Rule that we refined the HITSC's 
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 proposed 
to replace 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. We described that 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 was 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.
    We also proposed 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 proposed to require the use of CDS when a summary care 
record was incorporated. We noted that 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 proposed to adopt its 
most recent edition (International Normative Edition 2010) in order to 
enable a user to retrieve diagnostic or therapeutic reference 
information. We stated our belief that the use of standard reference 
information retrieval formats would accelerate the delivery of content 
to providers and hospitals, and would enhance the flexibility of such 
implementations because these formats reduce the need to ``hard wire'' 
the content databases to installed EHR technology. We indicated that 
this flexibility would allow EPs, EHs, and CAHs more choices and easier 
migration across content providers, encouraging innovation and 
competitiveness among these content providers.
    We asserted that it is important for CDS interventions to be 
triggered when new information is incorporated into EHR technology as a 
result of a care transition. Consistent with this belief, we proposed 
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). In 
consideration of 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 
requested 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's stated intent, for EHR technology to be 
certified to this criterion we proposed that 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. We asserted that EHR technology must also be capable of 
generating interventions automatically and electronically when a user 
is interacting with the EHR technology.
    Last, expanding on the HITSC's recommendation that the source 
attributes of suggested interventions be displayed or available for 
users, we proposed 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. We asserted that the 
availability of this information would enable the user to fully 
evaluate the intervention and enhance the transparency of all CDS 
interventions, and thus improve their utility to healthcare 
professionals and patients.
    To aid readers, we have done our best to group comments and 
corresponding responses under subheadings that align with the specific 
capabilities proposed for the CDS certification criterion.
General Comments on CDS Interventions
    Comments. There was overwhelming support for replacing the term 
``rule'' with ``intervention.'' A few commenters suggested that we 
provide an expanded list of example CDS interventions such as patient-
specific order sets, dosing guidance, documentation forms, and display 
of patient-specific relevant information.
    Response. We appreciate the support for the more expansive term, 
``CDS intervention'' and have used it in the final rule. We would like 
to note that the examples of CDS interventions in the NPRM were 
illustrative only, as our focus is not the type of intervention but the 
clinical intent of an intervention that offers guidance.

[[Page 54213]]

    Comments. Several commenters commented on the specific capability 
proposed at Sec.  170.314(a)(8)(i) ``Evidenced-based decision support 
interventions.'' They stated that they were confused by and would like 
clarification on the statement ``each one or any combination of the 
following.''
    Response. As noted in the section III.A.4 of this preamble 
(``Explanation and Revision of Terms Used in Certification Criteria''), 
in any certification criterion where we had this or similar language, 
we have revised it to clarify its intent. We refer readers to this 
section of the preamble for further clarification.
    Comments. We received many comments and questions about the 
mechanism of counting or measuring that the CDS event was enabled or 
activated. Many commenters believed that that it would be very 
difficult to track CDS interventions ``live'' in multiple locations 
within the EHR technology and within many workflows. As such, some 
commenters believed this requirement should just be met thorough 
provider attestation, while others commented that the occurrence, 
rather than the enabling, of the CDS intervention should be measured. 
Commenters expressed concern about providers needing or choosing to 
modify or replace interventions during a reporting period based on 
quality improvement or clinical needs and how that might endanger their 
ability to meet MU requirements.
    Response. The Stage 2 final rule, published elsewhere in this 
edition of the Federal Register, provides guidance regarding how an EP 
or EH would report CDS interventions, or how activation would be 
managed relative to the EHR reporting period. We thank commenters for 
their suggestions regarding other methods of tracking CDS, but we 
believe that the best method of tracking CDS interventions is to 
capture when they are enabled. So long as EHR technology is capable of 
recording such an event, then the EHR technology will be capable of 
generating a report that expresses the CDS interventions that were 
enabled across a given time-frame such as during an EHR reporting 
period. In response to these comments, we have revised the first 
specific capability of this certification criterion to clarify two 
points: 1) that we intended for an identified set of limited users to 
be able to select CDS interventions (thus, per the statements above, it 
should be apparent when these users have enabled certain 
interventions); and 2) when we used the parenthetical (or activate) we 
did not mean to imply that activate was a separate functionality from 
select. In that respect we have clarified the parenthetical to say 
(i.e., activate).
    Comments. Some commenters requested that we not limit CDS 
interventions to only those tied to CQMs so that providers, hospitals, 
and specialists could target specific areas where they feel improvement 
is needed. Other commenters asked that we permit locally defined and 
developed CDS content and references.
    Response. We appreciate both of these suggestions. We refer readers 
to the EHR Incentive Programs final rule published elsewhere in this 
edition of the Federal Register for a description of CDS objectives for 
Meaningful Use. Locally defined and developed CDS content and 
references are certainly permitted to be used with the capabilities for 
which certification is required by this certification criterion.
    Comments. Several commenters were concerned about ``hard coding'' 
CDS to CQMs in EHR technology.
    Response. We share this concern and agree that EHR technology 
presented for certification should leverage standards where possible to 
retrieve CDS content from external sources (which can be maintained and 
updated independently from the software release cycle). The Proposed 
Rule noted that 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. We noted that these tools 
are being made available through links in EHRs, offering information at 
relevant points within the clinical workflow. The Infobutton standard 
was proposed in order to enable a user to retrieve diagnostic or 
therapeutic reference information. We suggested that the use of 
standard reference information retrieval formats would accelerate the 
delivery of content to providers and hospitals, and would enhance the 
flexibility of such implementations because these formats reduced the 
need to ``hard wire'' the content databases to installed EHR 
technology. This flexibility would allow EPs, EHs, and CAHs more 
choices and easier migration across content providers, encouraging 
innovation and competitiveness among these content providers.
    Comment. One commenter requested clarification concerning proposed 
Sec.  170.314(a)(8)(i), expressing an interpretation that an EHR Module 
can be certified to this paragraph (as well as meeting other 4 
paragraphs) if it implements one or more CDS interventions, that none 
of the interventions need be drug-drug or drug-allergy related, but 
only if it uses data from the enumerated list in Sec.  
170.314(a)(8)(i)(A)-(F). This commenter noted that the EHR Module may 
address high priority health conditions not included by CMS as a 
Clinical Quality Measure, and recommended that there not be any 
inconsistency between the two rules (i.e. a CQM that does not use one 
of the enumerated data elements present in Sec.  170.314(a)(8)(i)(A)-
(F)).
    Response. This certification criterion specifies the minimum 
capabilities EHR technology needs to include in order to be certified. 
It does not preclude the incorporation of CDS interventions that 
address health conditions not included in CQMs identified in the EHR 
Incentive Programs. We expect to have tighter alignment with CDS and 
CQM in future editions of EHR certification criteria.
    Comment. One commenter noted that there would be ``mixed ability to 
meet'' several of the specific capabilities proposed in Sec.  
170.314(a)(8).
    Response. We thank the commenter for their feedback, and understand 
the concern. We have modified several of the specific capabilities 
expressed by this certification criterion as well as clarified them in 
our responses to provide better guidance and more flexibility.
HL7 Common Terminology Services
    Comments. Many commenters expressed that additional, ground-laying 
work would be necessary before the adoption of the HL7 Common 
Terminology Services could be a requirement for certification. These 
commenters noted that there would need to be a standardization of value 
sets, certification of a value set service, and mechanisms to update, 
maintain, and distribute value sets.
    Response. We thank commenters for their feedback and agree that 
there is not currently a set of publicly available resources that are 
accessible using this standard. We are coordinating efforts with other 
Federal agencies to create a value set repository that will be hosted 
by the National Library of Medicine. This repository will provide value 
sets in a manner consistent with the HL7 Common Terminology Services in 
the very near future, and we encourage EHR technology developers to use 
this valuable resource in order to capture and maintain value sets for 
CDS and CQM in the future. We intend to reconsider this for 
certification in a future edition of certification criteria.

[[Page 54214]]

Linked Referential CDS
    Comments. Many commenters expressed concern that our reference to 
the HL7 Context-Aware Knowledge Retrieval (``Infobutton'') standard was 
intended to be required for interactive CDS interventions, and 
suggested that it was an inappropriate standard for such interventions. 
Some commenters disagreed with our inclusion of linked clinical 
references in the CDS certification criterion. Several commenters 
expressed support for the ``Infobutton'' standard for referential CDS, 
while some did not because they were concerned that there was 
insufficient industry adoption for this standard to be a requirement. 
One commenter suggested that while this standard is appropriate for 
linked referential CDS, there may be other methods of providing access 
to relevant clinical references, and that we should allow for other 
methods as well.
    Response. We agree that the HL7 Infobutton standard is an 
inappropriate standard for ``interactive'' CDS interventions. As we 
described in the Proposed Rule, we intended to require this standard be 
applied only for referential CDS. Thus, for the purposes of referential 
CDS, we agree with commenters that expressed concern as to whether 
there is sufficient industry adoption of this standard. We agree that 
there may be other methods of providing context aware reference 
information and, that in some cases, it may be appropriate to use other 
methods. Nonetheless, we remain convinced that the widespread adoption 
of HL7 Context-Aware Knowledge Retrieval standard for the retrieval of 
clinical reference information is an important capability for EHR 
technology to include. In response to commenters concerns, we have 
adopted this standard as an alternative to a general capability for 
referential decision support that does not require a standard. We took 
this approach because we recognize that in order for CDS to benefit 
from the HL7 Context-Aware Knowledge Retrieval standard a large enough 
pool of publishers providing content in a standards-compliant manner 
need to be available. Thus, had we required that the HL7 Context-Aware 
Knowledge Retrieval Standard be implemented in order to meet this 
certification criterion, our requirement could have caused many EHR 
technology developers to invest in work that would have resulted in no 
clinical value to an EP or EH--as there may not be a desirable 
selection of referential CDS content available for consumption through 
the use of this standard. In future rulemaking, we do expect to require 
this standard for certification, and we encourage EHR technology 
developers to begin plans to implement functionality that would support 
the incorporation of knowledge resources made available with this 
standard, and seek optional certification for 2014. While we do not 
certify knowledge publishers, we also encourage such organizations to 
adopt this standard as a method of providing patient and/or provider 
facing clinical content to EHR technology. We clarify that because we 
have expressed the HL7 Context-Aware Knowledge Retrieval Standard-
enabled capability in the certification criterion with an ``or,'' EHR 
technology that is presented for certification with this capability 
would not also need to meet the general capability in order to be 
certified (i.e., one capability or the other will be sufficient to 
satisfy the certification criterion). Finally, we note that consistent 
with our adoption of the HL7 Context-Aware Knowledge Retrieval 
implementation guides (discussed in the patient-specific education 
resources certification criterion), we have also applied both 
implementation guides to this standard here.
CDS Configuration; CDS Interventions Automatically and Electronically 
Occur
    Comments. Commenters requested that we clarify our language 
regarding the configuration of CDS for a given ``setting,'' when CDS 
interventions occur in the workflow, and requested that we clarify 
``user'' to mean licensed healthcare professional.
    Response. After further evaluation and consideration as to whether 
they could be unambiguously tested, we have removed references to 
setting and workflow from this portion of the certification criterion. 
However, we have retained the first requirement--that CDS can be 
configured ``based on a user's role.'' We do not constrain ``user'' to 
mean ``licensed healthcare professional,'' because some users of CEHRT 
may not be licensed healthcare professionals. For example, a clerical 
user or a patient user may interact with CEHRT in some way, and there 
is no reason that the CDS should not be configurable to expose 
appropriate interventions (screening reminders, for example) to a 
patient or clerical user. Our requirement here is simply that the 
system be capable of configuration based on the user's role in the 
system. We expect that a physician, nurse, clerical worker, and patient 
would all have different settings, as the CDS interventions to which 
they should be exposed may differ--or may have different presentation 
formats.
    Comments. Many commenters expressed concern about the term ``when 
incorporated'' and the timing of CDS interventions being ``triggered'' 
based on data incorporated from the transition of care/referral 
summary.
    Response. We agree that reconciling information into EHR technology 
requires many steps in order to determine what information is 
clinically significant and valid. We also understand that there are 
semantic interoperability challenges for data at this granular level 
that may make accurate and responsive CDS intervention triggers overly 
difficult and/or unreliable. In the Proposed Rule, we proposed that EHR 
technology would need to be able to ``enable interventions to be 
triggered, based on the data elements specified in paragraph (a)(8)(i) 
of this section, when a transition of care/referral summary is 
incorporated pursuant to Sec.  170.314(b)(1).'' We have revised this 
language to make explicit three instances that this certification 
criterion implicitly required:
    (1) CDS interventions must be triggered based on data that is 
already recorded and stored within EHR technology;
    (2) CDS interventions must be triggered when a patient's 
medications, medication allergies, and problems have been incorporated 
by EHR technology upon receipt of a transition of care/referral summary 
formatted in accordance with the Consolidated CDA; and
    (3) For the ambulatory setting only, CDS interventions must be 
triggered when laboratory test results/values are incorporated by EHR 
technology upon receipt of a laboratory test report formatted in 
accordance with the LRI specification.
    We clarified our interpretation of the term ``incorporate'' earlier 
in this final rule and have also clarified that the only time 
incorporation is implicated by the adopted certification criteria is 
for the incorporation of certain data as a result of a transition of 
care and, for the ambulatory setting only, when lab results/values are 
received and incorporated by EHR technology according to the LRI 
specification. This modification reduces the ``incorporated data'' that 
would be expected to trigger a CDS intervention to at most four out of 
the six originally proposed data elements (three out of six for 
inpatient EHR technology) (i.e., for the ambulatory setting it would be 
problems, medications, medication allergies, and laboratory tests and

[[Page 54215]]

values/results and for the inpatient setting it would be problems, 
medications, and medication allergies). Thus, for the purposes of this 
certification criterion, we clarify that EHR technology must be capable 
of demonstrating that it behaves differently in two states: before and 
after the incorporation of new information. We make no specification 
regarding the timing of events. That is--we do not specify that the EHR 
technology must ``trigger'' an intervention at the time of 
incorporation. For example, if a transition of care/referral summary is 
incorporated into a patient's record with a new medication allergy, the 
EHR technology will behave differently in this state (would alert the 
EP who attempts to prescribe this medication) than it did before the 
transition of care/referral summary had been incorporated.
CDS Source Attributes
    Comment. Many commenters expressed support for transparency of the 
source attributes for CDS interventions. Some commenters expressed 
concern that requiring the display of such information could be 
distracting and not well accepted by end users. Commenters wanted 
clarification that the EHR technology must only enable the display, not 
be required to supply the content of the CDS intervention and reference 
source attributes.
    Response. The intent of the source attribute requirement is to 
permit end users of EHR technologies to have transparent access to 
information about their CDS resources, interventions, and reference 
information. We do not require the automatic display of the source 
attributes, just the availability of the information to the end-user. 
For example, additional action may be required for a user to ``drill 
down'' or ``link out'' to view the source attributes of CDS. We are 
also not requiring that the EHR technology create the content for the 
source attributes. In a scenario where the EHR technology developer 
uses a third party content provider for a clinical reference or 
interventions it would be the third party from which the EHR technology 
developer would get this information.
    Comment. One commenter suggested that the CDS source attributes 
should supply not only (A)-(D) but also the specific CQMs associated 
with the CDS intervention.
    Response. We appreciate this comment, which aligns with the 
direction we stated in the Proposed Rule to align the capabilities of 
EHR technology, CQMs, and CDS for future stages of the EHR Incentive 
Programs. Since many CDS interventions are not today directly linked to 
CQMs, we will not implement this as a certification requirement. This 
does not prevent CDS intervention developers or EHR technology 
developers from providing and leveraging this additional attribute to 
assist EPs, EHs, and CAHs in meeting the expectations of the EHR 
Incentive Programs.
    Comment. Several respondents wanted to eliminate the source 
attribute requirements for drug-drug and drug-allergy CDS 
interventions.
    Response. Drug-drug and drug-allergy interventions are clinical 
decision support resources. We proposed that EHR technology be required 
to enable the user to review the attributes for each intervention or 
reference source for all CDS resources. We believe that this is 
important because most EHR technology developers acquire the clinical 
knowledge that is represented in CDS from external sources. These 
sources should be available to the EP, EH, or CAH for reasons stated in 
the Proposed Rule and above. We agree with the commenter that it may be 
unnecessary or inappropriate for each and every such intervention to 
offer all of the source attributes. For example, a drug-allergy alert 
that warns a user not to prescribe a medication to which that patient 
is allergic may not merit the same scrutiny by the EP, EH, or CAH as an 
intervention that informs a provider of an opportunity to prescribe a 
new medication for which a given patient may be a candidate. We 
therefore have modified this criterion to constrain the required 
information to a bibliographic citation and identification of the 
developer of the intervention, and further clarify that global 
citations are permitted in cases where all interventions of a given 
type are provided by the same reference. For example, if all drug-drug 
and drug-allergy alerts are part of product ABC, provided by company 
XYZ, then one global statement that attributes these references to this 
product and company is acceptable, and need not be made available for 
each and every intervention.
    Comment. Some respondents requested additional clarity regarding 
the source attribute requirement. One commenter noted that further 
clarification is required for ``revision dates'' ``funding source,'' 
and ``developer of the intervention'' and noted that some CDS 
recommendations are developed in-house and may not be the result of 
published work. Additionally, they noted that ``developer of the 
intervention,'' and ``funding source'' may not be easily obtained.
    Response. We describe these requirements as follows:
     ``Bibliographic citation'' (clinical research/guideline) 
is a reference (if available) to a publication of clinical research 
that documents the clinical value of the intervention. If no such 
reference exists, as may be the case for a locally developed 
intervention, the EHR technology should make this information available 
as well. In this scenario, an EP, EH, or CAH who is interacting with 
guidance offered by the EHR would see that there is no clinical 
evidence available. The absence of such information is, in this case, 
valuable information and may (or may not) cause the EP, EH, or CAH to 
heed or ignore the guidance. Note that our goal here is not to assess 
the quality or evidence basis of decision support, but to enable the 
EP, EH, or CAH to do so.
     ``Developer of the intervention (translation from clinical 
research/guideline)'' is the team, person, organization, department, or 
other entity that interpreted the clinical research and translated it 
into computable form. In some cases, this is a ``knowledge vendor.'' In 
some cases, this is the EHR technology developer, and in some cases it 
is an EP or an employee of an EH/CAH. In all cases, there is 
interpretation and translation from prose to logic that can be 
interpreted and managed by the EHR technology.
     ``Funding source of the intervention development technical 
implementation'' is the source of funding for the work performed by the 
``developer of the intervention.'' In many cases, this will be the same 
organization as the developer of the intervention, but in some cases, 
this may be a government agency or Department of Health, commercial 
insurance carrier, employer, or biomedical product developer. For 
example, if the Health Department of State XYZ funds company JKL to 
create an intervention that translates a clinical practice guideline 
for management of disease ABC that can be incorporated into certified 
EHR technology as decision support, company JKL would be the 
``developer of the intervention,'' while Health Department of State XYZ 
would be the ``funding source.'' In cases where this information is 
unknown, then the EP, EH, or CAH should have access to the fact that 
this information is unknown.
     Patient-Specific Education Resources


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

[[Page 54216]]

 
  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)(15) (Patient-specific education resources).
------------------------------------------------------------------------

    We proposed 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 proposed to adopt the HL7 Context-Aware Knowledge 
Retrieval (Infobutton) standard, International Normative Edition 2010, 
as the required standard. We stated that HL7 Context-Aware Knowledge 
Retrieval standard is being increasingly used by more providers to 
electronically identify and provide patient-specific education 
resources. Therefore, we stated that it was appropriate 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 HL7 Context-Aware Knowledge Retrieval standard.
    Comments. With respect to patient-specific education materials, 
commenters focused on some aspect, or the potential affect, of the 
proposed inclusion of the HL7 Context-Aware Knowledge Retrieval 
standard. Some commenters supported its adoption as part of this 
certification criterion. Many commenters requested clarification on 
whether the use of the HL7 Context-Aware Knowledge Retrieval standard 
was mandatory (as a replacement of existing functionality). They 
qualified their support for the standard by suggesting that EHR 
technology developers (and their customers) be permitted to present 
education materials for any reference content using existing product 
capabilities or through a partnership with a content provider of such 
reference materials. These commenters reasoned that many EHR 
technologies are designed to allow for self-developed content or for 
use of third party content without the EHR technology having to go an 
external source. Some commenters suggested that the HL7 Context-Aware 
Knowledge Retrieval standard be positioned to augment, rather than 
completely replace other patient education mechanisms currently in 
place (e.g., vendor supplied, physician defined). Other commenters 
opposed the standard's adoption with some stating that its adoption was 
immature and that limiting the certification to just this standard 
would create limitations that could have negative effects on workflow 
and efficiency.
    Response. Our goal is to enable EPs, EHs, and CAHs to provide 
patients with the best possible information in the most efficient and 
cost-effective ways possible. While we believe Infobutton meets this 
goal, we also agree with commenters that alternative means for 
identifying patient-specific education materials could meet this goal 
and should be available to EPs, EHs, and CAHs. Therefore, we are 
adopting a certification criterion that requires EHR technology to 
demonstrate a capability to identify patient-specific education 
materials using the HL7 Context-Aware Knowledge Retrieval standard 
(with the applicable implementation guide) as well as through another 
means (i.e., at minimum, 2 different ways, one of which is through the 
use of the HL7 Context-Aware Knowledge Retrieval Standard). By doing 
so, we believe EPs, EHs, and CAHs will have added flexibility in 
meeting the MU objective and measure and an improved ability to provide 
quality care to patients.
    Comments. A few commenters recommended that we change the wording 
in the certification criterion. Specifically, they recommended that we 
change the phrasing in the proposed certification criterion from ``each 
one of the data elements'' to ``one or more of the data elements.''
    Response. As noted above, we have revised the certification 
criterion to require that EHR technology demonstrate the capability of 
using HL7 Context-Aware Knowledge Retrieval Standard and another means 
to identify patient-specific education resources. We have also revised 
the language referenced by this certification criterion to make it 
clearer. The certification criterion requires that EHR technology be 
capable of identifying patient-specific education resources based on 
data included in a patient's problem list, medication list, and 
laboratory tests and values/results. To clarify, EHR technology must be 
capable of identifying patient-specific education resources based on 
data from any one of these categories. The identification of patient-
specific education resources based on a combination of data from these 
categories would also be acceptable, but in order to demonstrate 
compliance with this certification criterion EHR technology must be 
able to identify patient-specific education materials, in some manner, 
for all of the categories (i.e., a combination of 2 out of 3 categories 
would be insufficient to satisfy this certification criterion's 
requirements).
    Comments. A commenter stated that the HL7 Context-Aware Knowledge 
Retrieval Standard, International Normative Edition 2010 (Infobutton) 
by itself is not implementable, but it can be implemented in 
conjunction with one of the two available implementation guides: the 
URL-based Implementation Guide and/or the SOA-based Implementation 
Guide. They recommended that the certification criterion explicitly 
require implementation to at least one of the two implementation 
guides. Other commenters echoed the same point and recommended that the 
URL-based Implementation Guide as the best implementation guide to 
accompany the standard.
    Response. We agree with the commenters that guidance is necessary 
for the implementation of the Infobutton standard. Accordingly, as 
recommended by the commenters, we are adopting the URL-Based 
Implementation Guide and the SOA-based Implementation Guide. We have 
adopted them as an ``or'' meaning that only one would need to be used 
to demonstrate compliance with this certification criterion. While we 
recognize that more EHR technology developers may use the URL-based 
version, we also wanted it to be possible for EHR technology to get 
certified to the SOA-based version.
    Comment. One commenter suggested that CEHRT should permit 
integration of MedlinePlus Connect to enhance patient education with 
other languages and topics that may not be available in the vendor's 
patient education product. They reasoned that this would also help 
standardize patient education content across different EHR technology 
developers.
    Response. We do not preclude the integration of MedlinePlus Connect 
in EHR technology and note that MedlinePlus Connect supports the 
Infobutton standard.
    Comments. One commenter recommended that we amend the certification 
criterion to require that EHR technology identify patient-specific 
education resources that are compliant with low health literacy 
standards and provide those resources to the patient in the patient's 
preferred language. Another commenter provided an opposing view in 
stating that meaningful users should not be required to provide 
materials at specific reading and cultural competency levels. They 
reasoned that for short hospital visits (such as emergency department 
visits) identifying patients who would need

[[Page 54217]]

materials at different levels could be difficult.
    Response. We appreciate the commenters' recommendations on both 
sides of the matter. The capability we require EHR technology to 
demonstrate to meet this certification criterion for the 2014 Edition 
EHR certification criteria sufficiently supports the correlated MU 
objective and measure. Therefore, we decline to require a more explicit 
capability at this time. We note, however, that a patient's preferred 
language should be recorded per the ``demographics'' certification 
criterion (Sec.  170.314(a)(3)). We would anticipate that, in an effort 
to be responsive to a patient and provide quality care, EPs, EHs, and 
CAHs would take the patient's recorded preferred language into 
consideration when providing patient education materials.
    Comments. Many comments also included aspects about: The MU 
numerator and denominator associated with this certification criterion; 
the proposal to move the meaningful use objective to core from menu; 
when education materials needed to be provided; how they needed to be 
provided; principles behind providing education materials; the quality 
of the education materials; and that patient educational material need 
to be provided digitally and free of charge as well as free of any 
advertising and produced either without sponsorship by parties with 
conflicts, or with full editorial control vested in the authors, not 
the sponsors.
    Response. We do not believe it is within the purview of 
certification to regulate some of these matters in the manner suggested 
by the commenters (e.g., requiring all education materials be free) and 
believe it best to have the policy for providing education materials 
set first through MU and then supported by certification. We direct 
commenters to the Stage 2 final rule for a discussion on the MU 
objective and measures, including how to interpret the measure, its 
requirements, and the numerator and denominator of the measure.
     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) (Transitions of care--receive, display, and
 incorporate transition of care/referral summaries).
Sec.   170.314(b)(2) (Transitions of care--create and transmit
 transition of care/referral summaries).
------------------------------------------------------------------------

    We proposed two revised certification criteria for the 2014 Edition 
EHR certification criteria at Sec.  170.314(b)(1) and (2). The first 
certification criterion we proposed would have required EHR technology 
to be able to incorporate a summary care record formatted according to 
the Consolidated CDA. The second certification criterion we proposed 
would have required that EHR technology be capable of creating and 
transmitting a summary care record in accordance with the Consolidated 
CDA, with certain specified vocabulary standards, and two specified 
transport standards. As noted in the Proposed Rule, 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. However, based on stakeholder feedback received 
after the publication of the S&CC July 2010 final rule, we stated our 
belief that the criterion should be split into two separate 
certification criteria based on the capabilities required. We explained 
that this approach would provide developers greater flexibility for 
certification.
    For the same reasons we discussed in the proposal for the new 
``view, download, and transmit to 3rd party'' certification criterion 
(Sec.  170.314(e)(1)), we proposed to adopt the Consolidated CDA for 
this certification criterion because its template structure can 
accommodate the formatting of a summary care record that includes all 
of the data elements that CMS proposed be available for inclusion in a 
summary care record. We acknowledged 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 included in the summary care record. We noted 
that 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 did not propose, 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 requested public 
comment on whether we should create separate certification criteria for 
all of these data elements in this final rule.
    For certain other data elements in Sec.  170.314(b)(2), we proposed 
to require that the capability to provide the information be 
demonstrated in accordance with the specified vocabulary standard. We 
noted that these vocabulary standards were either previously adopted or 
proposed for adoption in the Proposed Rule, consistent with HITSC 
recommendations. Additionally, we requested 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. We believed this would help 
prevent a summary care record from being combined with or attributed to 
the wrong patient.
    We proposed that EHR technology would need to be capable of 
transmitting a summary care record according to both of the Direct 
Project's specifications for secure transport. We also proposed to 
adopt as an optional standard at Sec.  170.202(a)(3) the SOAP-Based 
Secure Transport RTM version 1.0 \20\ which was developed under the 
nationwide health information network Exchange Initiative and to which 
we stated EHR technology should be able to be certified. We included 
this option to provide 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. We noted that, while we would only permit EHR technology to be 
certified to these two transport standards, we intended to monitor 
innovation around transport standards and would consider including 
additional transport standards, such as a RESTful implementation in 
this certification criterion.
---------------------------------------------------------------------------

    \20\ https://modularspecs.siframework.org/
NwHIN+SOAP+Based+Secure+Transport+Artifacts.
---------------------------------------------------------------------------

    Further, we requested public comment on whether equivalent 
alternative transport standards exist to the ones we proposed to 
exclusively permit for certification. We also requested comment on our 
proposed approaches for deciding whether additional transport standards 
would be appropriate and for adopting any such standards through 
interim final rulemaking with comment.

[[Page 54218]]

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 requested 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 proposed to adopt.
General Summary
    Many commenters reiterated or pointed to the comments they issued 
in response to the view, download and transmit to a 3rd party 
certification criterion. Many commenters also repeated points about a 
consistent set of data to be referenced across the certification 
criteria that proposed the adoption of the Consolidated CDA. In that 
respect, we do not repeat those responses where we have already 
addressed comments in other parts of this preamble that would also be 
applicable to the transitions of care certification criteria. Similar 
to the other certification criteria where we received detailed groups 
of comments on distinct concepts, we have used subheadings to improve 
the preamble's overall readability.
Receipt/Receive
    Comments. Some commenters expressed that the certification 
criterion proposed at Sec.  170.314(b)(1) was ambiguous. They also 
indicated that ``upon receipt'' in the certification criterion implied 
a capability that should be explicitly stated--that the EHR technology 
be able to receive a transition of care/referral summary according to 
the same transport standards we require (and permit) for certification 
for the transmission of a transition of care/referral summary. These 
commenters argued that we needed to include this specificity because 
EHR technology should be tested for both its ability to send and 
receive data. Further they suggested that we change the paragraph 
heading to include ``receive.''
    Response. We agree with commenters that the capability to receive 
transition of care/referral summaries according to the proposed 
transport standards was implied and that we should make it explicit. 
Further, in revising the proposed certification criterion to do so, we 
also noticed that Sec.  170.314(b)(1) should mirror the same structure 
as Sec.  170.314(b)(2) with its ``ambulatory setting only'' and 
``inpatient setting only'' because we had just included a list of data 
in our proposal that mixed both settings. We are finalizing these 
changes as well as changing the paragraph heading to better describe 
the overall capabilities specified by this finalized certification 
criterion. Any changes to Sec.  170.314(b)(2) in response to public 
comments, such as the applicability of certain transport standards are 
discussed in our responses below.
Display
    Comments. Several commenters recommended that, at the very least, 
we include some form of ``backwards compatibility'' in this 
certification criterion by requiring EHR technology to be able to 
display transition of care/referral summary formatted according to the 
standards adopted as part of the 2011 Edition EHR certification 
criteria. They reasoned that many EPs, EHs, and CAHs will have 2011 
Edition CEHRT capable of creating and displaying a transition of care/
referral summary according to the CCD/C32 and CCR. Additionally, they 
stated that by not doing so, we would significantly limit the ability 
of trading partners to continue to communicate with each other as they 
each separately upgraded their EHR technology to the capabilities 
required by the 2014 Edition EHR certification criteria. These 
commenters indicated that this requirement would be a relatively low 
burden since it is already required for certification.
    Response. We agree with commenters. We have revised the final 
certification criterion to require that EHR technology must be able to 
display in human readable format the data included in transition of 
care/referral summaries received and formatted according to each of the 
transition of care/referral summary standards we have adopted (i.e., 
CCD/C32; CCR; and Consolidated CDA). We believe this modification to 
the certification criterion, as expressed by commenters, results in a 
significant benefit while imposing very limited practical burden 
because it essentially builds on the 2011 Edition version of the 
certification criterion that we proposed to revise.
    Comments. A couple of commenters expressed concern regarding 
hospitalizations with large volumes of data such as lab results and how 
this information would display in a summary document of considerable 
length.
    Response. This certification criterion expresses that EHR 
technology must be able to display transition of care/referral 
summaries received according to any one of the three adopted standards 
mentioned in the above response. It does not, however, dictate how that 
information is displayed to a user. Those design decisions are fully 
within an EHR technology developer's discretion.
Incorporate
    Comments. We received a significant number of comments related to 
the specific ``incorporate'' capability expressed in this certification 
criterion. Many contended that the general description we provided at 
the beginning of the Proposed Rule was too generic, ambiguous, or 
inconsistent with their understanding of what it meant to 
``incorporate'' data as this certification criterion described. 
Commenters offered many perspectives on what incorporation should mean 
for this certification criterion. Most commenters described 
incorporation to mean the EHR technology's ability to store and 
reference data from a transition of care/referral summary.
    Many commenters stated that this proposal went far beyond what was 
required in the 2011 Edition EHR certification criterion's requirements 
and that it seemed to require that each and every data element 
referenced be incorporated as structured data. These commenters argued 
that for the 2011 Edition certification criterion, EHR technology only 
had to be able to incorporate the CCD or CCR transition of care/
referral summary as a whole, thus maintaining its integrity. Some 
commenters stated that incorporating an entire clinical summary might 
trigger the creation of a new encounter. Further, they added that for 
the 2014 Edition version, the only data that should be required to be 
incorporated (and that should be decomposed from the transition of 
care/referral summary) should be the same data specified in the 
``clinical information reconciliation'' certification criterion (i.e., 
problems, medications, and medication allergies) and focus on these 
data ``at a minimum.'' Other commenters argued that it made no sense to 
incorporate all of the data specified in the Proposed Rule because the 
data would be contextually specific--and could lose its semantic value 
if removed from the context of the whole document.
    Response. We agree with commenters that the single description for 
``incorporate'' in the Proposed Rule was insufficient to provide the 
clarity necessary for this certification criterion. As many comments 
expressed, and as we clarified in the beginning of this final rule, we 
intended for the term ``incorporate'' to mean that EHR technology would 
be able to process the structured data contained in those three

[[Page 54219]]

Consolidated CDA sections (medications, problems, medication allergies) 
such that it could be combined (in structured form) with data already 
maintained by EHR technology and would subsequently be available for 
use, such as to be used as part of the clinical information 
reconciliation capabilities (expressed in the certification criterion 
adopted at (Sec.  170.314(b)(4)). We have revised this certification 
criterion to make this distinction clear.
    In consideration of comments, such as those that indicated it may 
make no sense to incorporate specific data, we believe that there is 
clinical value to the extraction and individual display of the 
individual sections of the Consolidated CDA. To ensure that an EP, EH, 
or CAH, can reap the most benefit from a Consolidated CDA formatted 
transition of care/referral summary, we have added to this 
certification criterion a specific capability that EHR technology be 
able to extract and allow for individual display each additional 
section or sections (and the accompanying document header information 
(i.e., metadata)) that were included in a transition of care/referral 
summary received and formatted in accordance with the Consolidated CDA. 
For example, if a user wanted to be able to review other sections of 
the transition of care/referral summary that were not incorporated (as 
required by this certification criterion), such as a patient's 
procedures and smoking status, EHR technology would need to provide the 
user with a mechanism to select and just view those sections without 
having to navigate through what could be a lengthy document. We intend 
for testing and certification to verify that the document header 
information can be displayed with whatever individual sections are 
selected, but leave the ultimate quantity of header data to be 
displayed through implementation up to the EHR technology developer and 
its customers' preferences.
    We recognize this certification criterion is more rigorous than the 
2011 Edition EHR certification criterion, but believe that it is 
necessary to continue to introduce more demanding certification 
requirements for interoperability in order to advance our policy 
objectives for widespread electronic health information exchange. We 
stress that an EHR technology's ability to incorporate data for 
medications, medication allergies, and problems in structured form from 
a Consolidated CDA formatted document is the bare minimum necessary for 
EHR technology to meet this certification criterion. Even though we do 
not explicitly require more data to be incorporated in a structured 
form from a Consolidated CDA formatted document, we highly encourage 
EHR technology developers to go beyond this minimum as we intend to 
consider a more rigorous incorporation requirement in our next edition 
of EHR certification criteria. Finally, we believe our response under 
the ``display'' heading addresses the comments about incorporating a 
transition of care/referral summary as a whole, since such a capability 
would be addressed by the display requirement in this certification 
criterion.
    Comments. A few commenters stated that incorporation should not be 
automated and that there is a potential safety issue with bringing in 
data elements that have not been reconciled. Another commenter noted 
that one of the reasons incorporation cannot be automated is because 
many EHR technologies require that a term be in their ``problem list 
master file'' in order to get onto the problem list and that many EHR 
technologies have local problem terms that are mapped to SNOMED-CT. As 
a result, they stated that one cannot assume that two CCDs, each having 
a problem mapped to the same SNOMED-CT code, are both referring to 
exactly the same thing. They suggested that this capability be 
designated as optional. A couple of commenters noted that EPs, EHs, and 
CAHs should have some control over how exactly they want to be able to 
incorporate data into their EHR technology as part of their practice/
organization.
    Along these same lines, commenters responded to our question 
regarding whether some form of demographic matching would be important 
to include for this certification criterion. Commenters responded 
favorably, but requested that we not dictate a standard or any 
particular matching methodology so as to permit a range of different 
options and to let innovation continue in this area. One commenter 
stated that EHR technology must perform patient matching in order to 
aggregate PHI from multiple sources that provide electronic feeds into 
the EHR technology. Additionally, the commenter noted that the EHR 
technology developer typically determines the most appropriate patient 
matching algorithm based on a number of factors relating to the data 
available in order to facilitate a correct patient match. They also 
stated that some EHR technology developers may choose a very robust 
matching capability based on available demographics or practice size. 
Another commenter requested guidance on what data would be used for 
patient demographic matching. While a different commenter recommended 
that we establish a minimum set of demographic information that could 
be used to accurately match patient records.
    Response. We appreciate commenters' feedback and expressed 
concerns. We anticipate that EHR technology developers will be able to 
automate the incorporate capability in some manner, but this 
certification criterion does not necessarily require that it be fully 
automated. It is our understanding and, it was implied by the 
certification criterion, that some form of matching would occur when a 
transition of care/referral summary is received in order to correctly 
determine that the document as a whole (as discussed under the 
``display'' heading) was attributed to the right patient. Further, that 
upon receipt of a transition of care/referral summary is the 
appropriate point at which to verify that the transition of care/
referral summary is being attributed to the correct patient. 
Accordingly, we have not included this type of matching as part of the 
clinical information reconciliation certification criterion since the 
data will have already been attributed to a particular patient at the 
point in time reconciliation is executed. Finally, we have revised this 
certification criterion to include a general statement that the EHR 
technology must be able to demonstrate that a transition of care/
referral summary received is or can be properly match to the correct 
patient. As requested by commenters, we have intentionally left this 
requirement flexible to permit many different ways for this capability 
to be designed. As such, we decline to provide specific guidance on 
particular demographic information except to note that the demographics 
certification criterion would be a good starting point in addition to 
any data that may be available in the header of a transition of care/
referral summary. We encourage EHR technology developers to apply this 
specific capability to other capabilities where it may prove 
beneficial.
    Comments. Some commenters asked that we clarify that information 
made available in an HIE or a portal counts as incorporation for this 
certification criterion.
    Response. Considering the response above and how we have explained 
our interpretation of ``incorporate,'' we do not believe or see how 
this could satisfy the capability required by the certification 
criterion.
    Comment. A commenter in support of incorporating problems, 
medications,

[[Page 54220]]

and medication allergies suggested that this data should be 
incorporated into EHR technology in such a way that those data elements 
can be used for real-time clinical decision support and recommend that 
the ONC consider this as an additional criterion.
    Response. We refer readers to our discussion of the clinical 
decision support certification criterion.
Create and Transmit (now Also Applicable To Receive as Part of Sec.  
170.314(b)(1))
    Comments. As noted in the view, download, and transmit to a 3rd 
party certification criterion's comment and response section, we 
indicated that the only place where the data type ``encounter 
diagnoses'' would be included was as part of a transition of care/
referral summary in the transition of care certification criterion. 
Similar to the comments we received and discussed related to 
``procedures,'' some comments supported the use of ICD-10-CM while 
others stated that we should refer to SNOMED CT[supreg] and only SNOMED 
CT[supreg] for the same reasons they stated before (e.g., clinical 
accuracy versus a billing diagnosis code set). One commenter stated 
that both ICD-10-CM and SNODENT should be a requirement for diagnoses 
coding in dental systems. They reasoned that SNODENT has been mapped to 
ICD-9-CM and the mappings between SNODENT and ICD-10-CM are being 
developed.
    Response. We appreciate commenters' feedback. As with procedures, 
commenters provided many different perspectives on the appropriate 
vocabulary to adopt for encounter diagnoses. Because this is a billing 
data type, we have decided to finalize our proposal to allow for the 
use of ICD-10-CM to represent encounter diagnoses in addition to 
permitting SNOMED-CT. We believe this is the best approach to take for 
all parties involved. Additionally, the National Library of Medicine 
has created a publicly available mapping from SNOMED-CT to ICD-10-CM, 
available at https://www.nlm.nih.gov/healthit/meaningful_use.html. This 
mapping is available to any EHR technology developer, or practice 
management/billing system developer for the translation of SNOMED 
CT[supreg] to ICD-10-CM. In this way, EHR technology may send a 
representation of encounter diagnosis using either SNOMED-CT or ICD-10-
CM. Since providers will most likely be using SNOMED CT[supreg] for the 
selection of problems, this criterion allows for the use of only 
clinical vocabularies in such clinical systems and the association of 
problems with encounters, thereby encouraging the translation of SNOMED 
CT[supreg] to ICD-10-CM to occur in an administrative system. By 
permitting ICD-10-CM to be used to represent encounter diagnosis for 
certification, we also accommodate EHR technology developers who choose 
to make this translation within the clinical system as well. We decline 
to accept the recommendation for us to adopt SNODENT for the same 
reasons we provide elsewhere in this final rule in response to this 
comment.
    Comments. In response to our question as to whether we should 
create separate certification criteria for the data elements implicit 
and necessary to satisfy this certification criterion (as well as the 
other certification criteria that rely on the same data) some comments 
expressed support while others opposed doing so and suggested it was 
unnecessary. Those who opposed the adoption of separate certification 
criteria for the additional data (e.g., care plans) stated that while 
standards do not exist at the present time for these elements, they can 
be incorporated in the Consolidated CDA as text. They did, however, add 
that because no standards exist, we should consider deferring their 
adoption until the next edition of EHR certification criteria.
    Response. We thank commenters for responding to the question we 
posed. As suggested by those commenters that opposed the adoption of 
explicit certification criteria for each of these additional elements, 
we have not done so. We agree with the logic provided by commenters. So 
long as the Consolidated CDA can support this information, we believe 
it is sufficient to continue our approach of referencing this data 
within the applicable certification criteria. Consistent with our 
general approach to support MU, we have made sure to align all of the 
data specified and expected by CMS in applicable certification 
criteria. Thus, unless CMS removed a particular data element/type, we 
have included the data element/type in our final rule for the 
applicable certification criteria.
    Comment. A commenter stated that there appeared to be a hidden 
requirement for CEHRT to translate local codes to standard codes for 
all data in all instances, including when the original source of the 
data did not provide the data in standard codes. They suggested that in 
instances where the EHR technology simply passes-through the data that 
the requirement to use a standard vocabulary for outbound data exchange 
be waived. They further explained that when source data such as 
laboratory results or documentation from non-CEHRT/HIT is received by 
the CEHRT it may not contain data according to the adopted standard 
vocabulary. They contended that translating such data to a standard 
vocabulary should be the responsibility of the data source (to ensure 
the standard vocabulary is used most appropriately). They noted that 
downstream translation may not capture the translation subtleties that 
are clear within the source system's environment. They concluded by 
stating that it was unreasonable for us to implicitly or explicitly 
require that outbound data exchange from the CEHRT always apply a 
standard vocabulary to data that the CEHRT did not itself create until 
all relevant source systems utilize standard vocabularies.
    Response. We agree that there could be scenarios in which an EP, 
EH, or CAHs CEHRT receives data from a source that has not formatted 
the data according to the applicable adopted vocabulary standard. In 
instances where the EP, EH, or CAH's CEHRT receives data from an 
outside source, we acknowledge that requiring the CEHRT to translate 
the data into an adopted standard vocabulary could alter its intended 
meaning. We understand that there may be scenarios in which local or 
proprietary codes are transmitted in a transition of care/referral 
summary, laboratory report, or other exchanged document. Further, we 
agree with this commenter that the responsibility of the sending EP or 
EH/CAH is to send information with standard terms, and in the case when 
such standard terms are not used, it should not be the responsibility 
of the receiving EP or EH to translate local or proprietary codes into 
standard codes. However, we emphasize that for the purposes of 
certification, and demonstrating compliance with this certification 
criterion, EHR technology will need to be tested and certified as being 
able to apply all of the adopted standard vocabularies to data required 
to be included in a Consolidated CDA formatted transition of care/
referral summary. This response is applicable to the other 
certification criteria to which this clarification would apply.
    Comments. Many commenters supported our proposal to require the 
Applicability Statement for Secure Health Transport specification (the 
primary Direct Project specification) and the second Direct Project 
specification (XDR and XDM for Direct Messaging). Others supported our 
reference to the SOAP-based transport standard as well. Some commenters 
contended that we should require both transport approaches for 
certification. Other commenters stated that we should only

[[Page 54221]]

require the primary Direct Project specification. While others 
specified that we should reference the XDR and XDM for Direct Messaging 
specification as a bridge for the primary Direct Project specification 
and the SOAP-based transport standard.
    Response. In considering the range of comments received, we have 
finalized a modified certification approach with respect to transport 
standards. We have adopted, as proposed, that the Applicability 
Statement for Secure Health Transport specification be a required 
condition of certification as part of this certification criterion. We 
have removed the XDR and XDM for Direct Messaging specification as also 
being required in lieu of a broader range of options for certification. 
Thus, to be certified to this certification criterion an EHR technology 
must enable a user to electronically transmit a transition of care/
referral summary in accordance with the Applicability Statement for 
Secure Health Transport specification. This requirement sets a baseline 
for EHR technology certification and enables simple and secure SMTP-
based exchange. Additionally, because this certification criterion is 
part of the Base EHR definition, all EHR technology used by EPs, EHs, 
and CAHs and that meets the CEHRT definition will, at a minimum, be 
capable of SMTP-based exchange. For the reasons we discussed under the 
``view, download, and transmit to 3rd party'' certification criterion 
earlier in this preamble, we have adopted the updated version of this 
specification that was established by the stakeholder community during 
this final rule's drafting.
    To permit additional flexibility and options for EHR technology 
developers to provide their customers with EHR technology that has been 
certified to support an EP, EH, or CAH's achievement of the 
``transitions of care'' MU objective and associated measure, we have 
adopted two optional certification approaches for transport standards. 
For each option, EHR technology would need to demonstrate its 
compliance with both of the identified specifications in that option in 
order to be certified to the option.
     The first option would permit EHR technology to be 
certified as being in compliance with our original proposal: 
Certification to both the Applicability Statement for Secure Health 
Transport specification and the XDR and XDM for Direct Messaging 
specification.
     The second option would permit EHR technology to be 
certified to: The Simple Object Access Protocol (SOAP)-Based Secure 
Transport Requirements Traceability Matrix (RTM) version 1.0 standard 
and the XDR and XDM for Direct Messaging specification.
    We have included the XDR and XDM for Direct Messaging specification 
as a required specification for both of these options because it serves 
as the bridge or translator for electronic exchange partners that 
engage in SMTP to SOAP and SOAP to SMTP exchanges.
    Comments. A few commenters noted that the proposal to adopt the 
Simple Object Access Protocol (SOAP)-Based Secure Transport 
Requirements Traceability Matrix (RTM) version 1.0 specification was 
confusing and requested that we clarify whether its adoption permitted 
the use of other nationwide health information network specifications 
to be used (e.g., patient discovery, document query, document 
retrieval). Some of the same commenters also suggested that we added 
the IHE-XDR profile as an implementation guide for the proposed 
standard. Last, these commenters requested that we change the paragraph 
heading for the transport standards so as not to imply their use is 
limited to directed exchange.
    Response. We seek to clarify any confusion that may have been 
caused by our proposed adoption of the SOAP-Based Secure Transport 
Requirements Traceability Matrix (RTM) version 1.0 specification. As 
indicated within the specification, its purpose is to ``define the 
primary set of security and transport protocols needed to establish a 
messaging, security, and privacy foundation for health information 
exchange.'' Further, it is ``constrained to technical specifications 
for security and transport protocols and does not address any content 
specifications.'' Last, it is ``intended to provide an understanding of 
the context in which the web service interface is meant to be used, the 
behavior of the interface, the Web Services Description Language 
(WSDLs) used to define the service, and any Extensible Markup Language 
(XML) schemas used to define the content.
    This specification, and not IHE designated specifications, was 
purposefully adopted because it serves as the baseline SOAP 
specification on top of which other (March 1, 2012 effective) 
Nationwide Health Information Network Exchange specifications can be 
implemented. If an EHR technology is presented for certification to 
this optional transport standard, we intend for testing and 
certification to establish that the SOAP specification is properly 
implemented (i.e., EHR technology's ability to send and receive 
messages in accordance with the specification). Because this 
specification serves as the underlying set of web services protocols 
for other more detailed context/use case specific specifications, we 
clarify that so long as EHR technology is certified to this baseline 
SOAP specification other more detailed/use case specific specifications 
may be used in addition to, or on top of, this specification (i.e., not 
in lieu of).
    With respect to the recommended IHE profile, we did not accept this 
recommendation. We have included the bridge specification in the XDR 
and XDM for direct messaging specification and have concerns about the 
testability of the IHE-XDR profile. As we understand it and as 
currently described in the IHE Technical framework, the IHE XDR is a 
``pattern'' of a transaction that can be tailored and implemented by 
EHR technology developers as they wish, based on a particular use case. 
Additionally, both of the transport standards adopted in this final 
rule can be used independent of IHE XDR profile. This does not preclude 
EHR technology developers from also implementing it outside of 
certification, but we decline to require it as a condition of 
certification.
    Finally, we have removed the paragraph heading in Sec.  170.202 as 
indicated by commenters so as not to imply that the specifications can 
only be used in the context of directed exchange.
    Comments. Commenters raised several questions and concerns related 
to the proposed Direct Project specifications and how EHR technology 
would be tested and certified to the transitions of care certification 
criteria. Commenters indicated that there are multiple ways to deploy, 
configure, and implement EHR technology to meet the specifications. 
Some asked that we clarify whether all implementation options must be 
simultaneously supported or if some were intended to be prohibited. 
Further these commenters stated that only one test of a particular 
implementation/configuration would be necessary to verify that an 
appropriate SMTP + S/MIME communication was correctly structured, but 
all implementations would rely on that capability to be present. 
Commenters recommended that we clarify what would be required to 
demonstrate compliance with these certification criteria. They 
recommended that testing and certification focus on EHR technology's 
ability to correctly create and receive messages formatted in 
accordance with the Applicability Statement for Secure Health Transport 
specification. They concluded by stating that this approach would 
enable EPs, EHs, and CAHs to utilize other email infrastructures 
without requiring EHR technology

[[Page 54222]]

developers to test with multiple infrastructures.
    Response. We thank commenters for the detailed comments and in some 
cases illustrations to describe the different deployment and 
configurations anticipated by the Applicability Statement for Secure 
Health Transport specification. These detailed comments greatly aided 
our policy deliberations. We agree with commenters on the approach that 
should be used to test and certify whether EHR technology is in 
compliance with the Applicability Statement for Secure Health Transport 
specification. Specifically, we agree that testing and certification 
should not focus on particular deployments or configurations, but 
rather on what will remain constant across those variances--EHR 
technology's ability to correctly produce and receive SMTP + S/MIME 
messages formatted in accordance with the Applicability Statement for 
Secure Health Transport specification. We further clarify that we do 
not intend for testing and certification to focus on the particular 
email protocols that may be implemented to support the routing of these 
messages, such as Internet Message Access Protocol (IMAP), Post Office 
Protocol (POP) and other vendor-specific proprietary protocols. These 
capabilities and others such as mailbox management, storage, and 
forwarding of received messages that would be implementation or 
deployment specific would not be assessed as part of testing or as a 
condition of certification.
    Further, we expect that the National Coordinator will approve a 
test procedure for the transitions of care certification criteria that 
rigorously assesses EHR technology's ability to transmit and receive 
electronic health information according to the adopted transport, 
content exchange, and vocabulary standards. We anticipate that this 
test procedure will be specified to ascertain the EHR technology's 
ability to engage in standards-based exchange with any other EHR 
technology that has also implemented the standards we have adopted. To 
enable this form of electronic testing, the NIST has developed a 
conformance test tool that receives and validates a Consolidated CDA 
formatted file from the EHR technology under test. The conformance tool 
will be a part of a ``test bed'' that simulates exchange between a test 
EHR technology and a standards-compliant EHR technology. This will 
eventually allow for all levels of interoperability to be assessed in 
the electronic exchange of transition of care/referral summaries. This 
capability will also provide a future platform for testing more 
comprehensive forms of interoperability between EHR technologies.
    Comment. A commenter requested that we clarify whether a health 
information exchange using only CONNECT to exchange could meet the 
certification criterion. Another commenter asked that we confirm that 
the transport capabilities can be demonstrated by a Complete EHR or EHR 
Module itself, or through demonstration by the Complete EHR or EHR 
Module to achieve the transport capability through integration with a 
service provider--such as a network or health information service 
provider (HISP). They stated their interpretation that the current 
definition of an EHR Module permits a combination of a service and a 
component to be certified.
    Response. While we would need to examine a specific fact pattern to 
issue a definitive response, it seems possible for a health information 
exchange using CONNECT to seek certification to this certification 
criterion. We have always maintained and reaffirm that any EHR 
technology that can demonstrate compliance with a certification 
criterion can be issued an EHR Module certification as evidence that 
the capability the EHR technology included was certified. We interpret 
and use the term EHR technology (and intentionally not the term EHR) 
broadly so as to permit innovative market-based electronic exchange 
solutions to be paired with other EHR technology that performs 
clinically focused capabilities. Thus, to the degree that a HISP or 
like entity would be performing a capability for which certification is 
required and an EP, EH, or CAH would like to use the entity's 
technological capabilities as a way to meet the definition of CEHRT, 
the entity would need to seek certification for the technical 
capabilities that its systems can perform as if those capabilities were 
natively part of the EP, EH, or CAH's CEHRT. In these situations, we 
highly encourage EHR technology developers to work together to make the 
use of these capabilities as seamless as possible.
    Comments. Commenters suggested that ONC offer guidance on how the 
sending system will know the transport protocol understood by the 
receiving system unless that is something the Health Information 
Service Provider (HISP) would be responsible for indicating so the 
sending system sends using XDR or XDM appropriately.
    Response. Pursuant to our responses above, we believe this comment 
drifts into a specific implementation dependent scenario. However, we 
will consider whether additional guidance is required after this final 
rule to assist stakeholders.
    Comments. Several commenters stated that they reviewed potential 
RESTful transport alternatives and concluded that the alternatives 
lacked maturity and sufficient testing. A few commenters supported 
RESTful as an optional standard.
    Response. We agree with those commenters that have concluded 
potential RESTful transport alternatives lack sufficient maturity at 
this time for adoption. We will, however, continue to monitor the 
testing and implementation of RESTful transport alternatives to 
determine whether they have reached a maturity sufficient enough to 
consider for adoption.
     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 Proposed Rule, we proposed 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 
in each of a patient's medication, problem, and medication allergy 
lists. We proposed to adopt a revised certification criterion at Sec.  
170.314(b)(4) which we labeled as ``clinical information 
reconciliation'' to express the three specific capabilities that EHR 
technology would need to include.
    We specified that EHR technology would first need to be able to 
electronically display the data from two or more sources in a manner 
that allows a user to view the data and their attributes, which must 
include, at a minimum, the source and last modification date of the 
information. We proposed that the second specific capability EHR 
technology would need to include would be to enable a user to merge and 
remove individual data. We clarified that, 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 we proposed that 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.

[[Page 54223]]

In our proposal, we emphasized that EHR technology's role is to be 
assistive and not to determine without human judgment which data 
elements should be reconciled. Thus, we noted that this third specific 
capability would require EHR technology to present a final set of 
merged data for a user to validate and confirm before updating the 
prior list. Finally, we requested 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.
    Comments. Commenters were generally in favor of the proposed 
clinical information reconciliation certification criterion. Many 
agreed with our proposal to expand reconciliation to include problems 
and medication allergies, but some stated that it exceeded what was 
minimally required for meaningful use and that we should just keep the 
certification criterion focused on medication reconciliation. A couple 
of commenters stated that the certification criterion was over 
specified, premature, and prescribed workflow. One followed suit and 
stated that the requirement to merge the data from a source and 
automatically update from a foreign source requires common data models 
and terminology sufficient to instantiate the medication, medication 
allergy, or problem into the receiving system and that these models and 
terminologies are not fully defined.
    Response. We appreciate commenters support and constructive 
feedback. We have finalized this certification criterion with specific 
modifications as detailed below in other responses. We believe these 
changes may address some commenters concerns, however, we have 
maintained this certification criterion's scope to include medications, 
medication allergies, and problems. We believe this is the minimum that 
EHR technology should be able to assist EPs, EHs, and CAHs reconcile. 
Further, as we have noted in the transitions of care certification 
criterion Sec.  170.314(b)(2), we intend for these same three data 
types to be able to be incorporated from a transition of care/referral 
summary formatted according to the Consolidated CDA standard and 
subsequently available to use for reconciliation as part of this 
capability. We anticipate that test procedures will be developed to 
thread these steps together where EHR technology presented for 
certification includes both capabilities (transitions of care 
incorporation and clinical information reconciliation). While we 
typically do not express capabilities in certification criteria that 
exceed what would be necessary to support meaningful use, we remind 
readers that our authority to adopt certification criteria is not 
limited by meaningful use. That is, meaningful use does not set a 
ceiling for certification. Rather, we generally use it as the baseline 
upon which we propose and adopt, in some cases, more rigorous 
requirements.
    Comments. Some commenters asked for clarification regarding the 
term ``source'' in the certification criterion and what would be used 
to indicate source. They asked if the information would be needed in 
the future, would be stored as part of the patient record, or if a link 
could be used to get to the source. Some did not support including this 
information.
    Response. We believe that, at a minimum, EHR technology needs to be 
able indicate to a user the data's source (i.e., where the data came 
from). For the purposes of this certification criterion and its linkage 
to the transitions of care certification criterion (Sec.  
170.314(b)(2)), we intend to focus certification on the identification 
of the source from the transition of care/referral summary's header. 
However, we do not preclude other sources, such as patients from being 
able to be identified as part of this certification criterion. Given 
the additional specificity in this 2014 Edition version, we intend to 
incrementally increase and enhance the assistive power of this 
capability over time.
    Comments. Commenters asked what ``last modification date'' in the 
certification criterion meant. They asked whether it was the last date 
of medication reconciliation or the date that the medication was added 
or updated. Some did not support including this information.
    Response. For the purpose of this certification criterion, ``last 
modification date'' should be interpreted differently for each data 
type. For medications, it should be interpreted as the last date the 
medication was documented, ordered, prescribed, refilled, dispensed or 
edited. For problems it should be interpreted as the last date the 
problem was documented or edited. For medication allergies, it should 
be interpreted as the date that the medication allergy was last 
documented, edited, or updated.
    Comments. Some commenters requested clarification on the term 
``merge'' in the certification criterion and what our expectation was 
for merge. They also asked that we clarify that merging would only be 
for medications, medication allergies, and problems.
    Response. We interpret ``merge'' to generally mean that EHR 
technology assists a user in creating a single list that is 
representative of the medications, medication allergies, or problems 
that are relevant to a patient. However, we believe that an approach 
using plain language to express the desired outcome would make this 
certification criterion clearer. It would also represent the many 
acceptable approaches we had in mind when we drafted this proposed 
certification criterion. Accordingly, we have modified Sec.  
170.314(b)(4)(ii) to state that EHR technology would need to enable a 
user to ``create a single reconciled list of medications, medication 
allergies, or problems.'' How this would be accomplished is up to the 
EHR technology developer, but could include a user's ability to merge 
equivalent elements and remove/deactivate no longer relevant 
information.
    Comments. Some commenters requested clarification that ``confirm'' 
was meant to be interpreted as the list itself and not each individual 
element within the list.
    Response. Confirm is meant to apply to the single reconciled list 
(not each element) once it meets a user's satisfaction.
    Comments. A couple of commenters requested that we expand this 
certification criterion to require that EHR technology be capable of 
conducting medication reconciliation using electronic health 
information exchange to obtain a medication history.
    Response. We appreciate this suggestion and recognize its value, 
however, we did not propose this type of extended capability, nor does 
meaningful use presently require it. Thus, we encourage EHR technology 
developers to consider including this capability if they have not 
already and we intend to bring this topic to the HITSC for 
recommendations on our next edition of certification criteria.
    Comments. Commenters requested that we clarify that the 
reconciliation process does not require all reconciliation activities 
to occur in one system function but may be performed in more than one 
function so that the functions can be placed in appropriate workflows. 
Commenters also asked that we clarify that each list type was expected 
to be separately reconciled and not that we expected two or more 
different list types to be reconciled at the same time (e.g., 
medication list and problem list). They suggested that we revise the 
certification criterion to expressly indicate that it would be at least 
two lists or at least two sources.
    Response. To clarify, we did not intend to imply that the 
reconciliation capability had to happen all in one step. For instance, 
if medications are reconciled at a different points in the

[[Page 54224]]

clinical workflow than problems, this would not be precluded by the 
certification criterion. However, the same underlying reconciliation 
capability required by the certification criterion would need to be 
initiated for each of those different list reconciliations. To make 
this clear we have modified the certification criterion, as commenters 
suggested to say ``from at least two list sources.'' We also wish to 
further explain for commenters that as the certification criterion 
begins to express each specific capability there is the following 
introductory text, ``For each list type:'' This should and is meant to 
be interpreted as separately applying to each list type. For instance, 
(b)(ii) would be interpreted as ``For each list type enable a user to 
create a single reconciled list of medications, medication allergies, 
or problems''. As in, there would be a single list for medications, a 
single list for medication allergies, and a single list for problems.
    Comments. A few comments asked that we provide an example for what 
an acceptable capability for this certification criterion would be. A 
commenter explicitly suggested (as part of our example) we clarify 
that, at a minimum, the EHR technology should have the ability to 
simultaneously display and update the appropriate list type.
    Response. First, we agree with the commenter that EHR technology 
should have the ability to simultaneously display the list type that is 
actively being reconciled. We have modified the certification criterion 
to make this implicit requirement explicit. We believe this is a 
critical clarification so as to prevent EHR technology from being 
certified that requires a user to toggle between different views to 
reconcile data for one list type. As far as an example goes, (and 
keeping in mind the revisions we have made to this certification 
criterion) assuming a transition of care/referral summary has been 
received as part of a transition of care, an EP's CEHRT would need to 
be able to receive the transition of care/referral summary and make a 
logical identification of the medications, medication allergies, and 
problems from the Consolidated CDA formatted transition of care/
referral summary pursuant to the incorporation requirement. Next, at 
the appropriate points in the EP's workflow, the EP would be able to 
interact with CEHRT to create a single reconciled list for each of the 
data included in the medication, medication allergy, and problem lists. 
For each of these lists, once the EP has the data reconciled to his or 
her satisfaction, the EP would be able to review the list and confirm 
the reconciled list, which would then be updated and saved as the 
single medication, problem or allergy list.
    Comments. Commenters requested clarification regarding the scenario 
where the source list is unstructured data. One stated that if the 
source list is unstructured, then whatever manner the EHR enables 
unstructured data to be presented which could subsequently be 
reconciled through manual transcription should be acceptable for 
certification. One commenter suggested that medications should be 
reconciled in whatever process the EHR technology supported for the 
2011 Edition EHR certification criterion. Other commenters requested 
clarification that a document received as a Consolidate CDA must 
contain structured data. They stated that for unstructured data, 
certification should not require corresponding items to appear on the 
reconciliation screens.
    Response. We agree with commenters suggestions. In the event that 
data is in unstructured form, any method implemented by which the EHR 
is capable of assisting in reconciliation is acceptable. Presumably, 
this is how (at a minimum) reconciliation is performed in accordance 
with the 2011 Edition EHR certification criterion. With respect to data 
received from a document formatted in accordance with the Consolidated 
CDA, we expect EHR technology to be tested on its ability to utilize 
structured data to assist in the reconciliation process.
    Comment. One commenter stated that reconciliation based on two or 
more lists has been and would continue to be artificial. They stated 
that the purpose of reconciliation is to reset and consider the patient 
at transitions of care. Further, they stated that a transition of care 
may or may not require reconciliation between two or more autonomous, 
overlapping lists. As an example they indicated that they support both 
ambulatory and acute care and that a transition from ambulatory to 
acute care involves a pruning, adding, and filtering the problem list 
from the ambulatory setting to a working problem list in the acute care 
setting. They stated that this does not require a demographic match nor 
does it involve foreign lists. They stated that if the intent of the 
Proposed Rule was to include lists coming from different legal entities 
or systems that we should state that it is.
    Response. While we understand this commenter's concern, we believe 
it is somewhat misdirected. This certification criterion is appropriate 
and broadly applicable to a vast majority of EPs, EHs, and CAHs, many 
of which will be getting data from multiple sources. Further, this 
certification criterion applies to EHR technology as a capability 
required for certification and does not prevent the actions described 
by the commenter from taking place.
     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).
------------------------------------------------------------------------

    In the Proposed Rule, we noted that, although 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 believed that we 
should leverage the significant progress made by the S&I Framework LRI 
initiative. We believed that we could achieve this by proposing 
revisions to this certification criterion for the ambulatory setting. 
We acknowledged that, 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, we stated that 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 
proposed to adopt LOINC[supreg] version 2.38 as the vocabulary 
standard, because the LRI specification requires the use of 
LOINC[supreg] for laboratory tests. We requested 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) could be adopted for 
certification of the inpatient setting as well. Besides the proposed 
revisions discussed, we also proposed to use the term ``incorporate'' 
to replace the terms ``attribute,'' ``associate,'' and ``link'' which 
were used in the 2011 Edition EHR certification criterion.

[[Page 54225]]

    In the Proposed Rule, we acknowledged that the LRI specification 
was undergoing HL7 balloting and stated that we intended to continue to 
monitor its progress and anticipated that a completed specification 
would be available prior to the publication of this rule.
    Comments. A few commenters commented on our proposal to specify HL7 
2.5.1 as the content exchange standard for the receipt of laboratory 
test results. A couple of these commenters recommended that we should 
permit HL7 2.3.1 and signal a direction to the market. Another opposed 
this requirement because they opposed any meaningful use requirement 
that would restrict laboratory results sent in HL7 2.5.1 to count 
towards the meaningful use objective this certification criterion 
supports. They contended that a vast majority of lab results are in HL7 
2.3.1.
    A couple of commenters indicated that we had erred in specifying 
HL7 2.5.1 because the Laboratory Results Interface (LRI) specification 
references both HL7 2.5.1 elements and HL7 2.7.1 elements. Thus a 
literal interpretation of what we proposed would create conflicts for 
implementers. These commenters suggested that only the LRI 
specification should be referenced as the standard. Another commenter 
suggested that we clarify that code sets should be used in accordance 
with the guidance provided in the LRI specification. One commenter 
recommended that we reference a transport standard to transmit 
laboratory test results.
    Response. As we have stated in other places in this final rule, 
just because EHR technology is required to demonstrate certain 
capabilities for certification, it does not necessarily mean that those 
capabilities must always and only be used to demonstrate MU. Those 
policies are established by CMS.
    After conducting additional research, we agree with commenters that 
we erred in referencing the HL7 2.5.1 standard in addition to the LRI 
specification. We have removed the reference to the HL7 2.5.1 standard 
in this certification criterion. We also note, for the same reasons we 
discussed earlier in this preamble in adopting it for the 
``transmission of electronic laboratory tests and values/results to 
ambulatory providers'' certification criterion (Sec.  170.314(b)(6)), 
we have adopted for this certification criterion the LRI implementation 
guide approved as a Draft Standard for Trial Use in July 2012 by HL7. 
We clarify that with the exception of the baseline minimum version of 
LOINC[supreg] that must be supported by EHR technology, we expect, in 
adopting this specification that it will be followed and implemented as 
authored. Further, we note that consistent with other certification 
criteria that rely on lab test results, we expect that EHR technology 
certified to this certification criterion will be able to make 
available for subsequent use (such as clinical decision support) the 
structured laboratory tests and values/results data received. Because 
we have specified a standard by which EHR technology designed for an 
ambulatory setting must be capable of receiving lab results, we clarify 
that testing and certification for this setting will examine whether 
EHR technology can properly extract lab tests results/values and 
incorporate the data from the LRI specification for subsequent use. We 
have included the term incorporate in this portion of the certification 
criterion for clarity. Last, because this certification criterion only 
focuses on receipt and not transmission of laboratory orders we decline 
to modify this certification criterion in response to the commenter's 
recommendation that we reference a transport standard for transmission 
of laboratory orders.
    With the exception of the change already noted, the only additional 
modification we have made in response to public comment was to reinsert 
the phrase ``attribute, associate, or link'' in 170.314(b)(5)(iii) to 
reflect the 2011 Edition version of this certification criterion due to 
the confusion we caused by overloading the term ``incorporate.''
    Comments. Commenters supported the adoption of LOINC[supreg] but 
expressed concern that LOINC[supreg] is subject to frequent updates and 
that the version we adopt in the rule would be quickly out dated.
    Response. We refer commenters to our responses later in this 
document on our approach to ``minimum standards'' code sets.
    Comments. A few commenters suggested that ONC work with CMS to 
encourage labs to adopt and use the S&I Framework LRI specification. 
They contended that without the ``source systems'' on board that 
requiring capabilities on receiving systems (EHR technology) would fall 
short of the intended purpose of reducing development time and costs 
and improving quality.
    Response. We appreciate these comments and will continue to work 
with our sister agencies in HHS to advance health IT policy in other 
programs and regulations that affect stakeholders that are not eligible 
to receive EHR incentive payments.
    Comment. A commenter asked that we confirm that ``internal 
exchanges'' within an organized health care arrangement (OHCA) (e.g., 
between the OHCA's clinical laboratories and its EHR systems) are not 
subject to this certification criterion.
    Response. This certification criterion specifies the capabilities 
that EHR technology must include in order to be certified. It does not 
implicate organizational exchanges.
    Comments. Several commenters echoed that the LRI specification 
should not be applied for the inpatient setting.
    Response. We agree and have not referenced it for the inpatient 
setting in the final certification criterion.
    Comment. A commenter requested a list of CPT codes that define 
imaging studies and a listing of CPT codes that define a laboratory 
test.
    Response. We received this same comment on the ``transmission of 
electronic laboratory tests and values/results to ambulatory 
providers'' certification criterion. As with the comment on that 
certification criterion, the commenter did not provide any supporting 
rationale as to why a list of CPT codes would be relevant to the 
capabilities expressed by this certification criterion. Thus, we 
decline to provide any additional information.
    Comments. A couple of commenters stated that the LRI specification 
includes a number of different ``profiles'' that provide options for 
users. They added that this approach was taken because the authors of 
the LRI specification recognized that not all systems or users would or 
should be able to meet a single set of requirements. These commenters 
recommended that the profile choice be left to the EHR technology 
developer and that we not require all combinations of all profiles to 
be required.
    Response. We do not intend to specify a particular profile or limit 
the use of the LRI specification to only one profile at this time. We 
understand that the LRI specification was drafted to create a path 
toward more constrained and specific implementations, the most rigorous 
being the Base + GU + RU (GU = Globally Unique Identifiers and RU = 
Unique Filler or Order Number Required). We intend to move toward this 
direction in our future rulemakings. We also seek to clarify for EHR 
technology developers that we do not expect the optional portions of 
the LRI specification/profile to be tested.
    Comment. A commenter asked that we clarify that the certification 
criterion only applies to the electronic receipt of

[[Page 54226]]

laboratory results and does not apply to the electronic transmission of 
the laboratory test order to the laboratory.
    Response. This certification criterion only applies to the 
electronic receipt of laboratory tests and does not focus on the 
transmission of orders.
    Comments. A couple of commenters requested we clarify that because 
EHR technology would need to include the capability to display all of 
the test report information specified in the CLIA rules at 42 CFR 
493.1291(c)(1)-(7) in order to meet this certification criterion, that 
doing so with transport standards that provided an acknowledgement back 
to the laboratory that the complete message was received as sent would 
satisfy the CLIA requirements for the delivery of a laboratory report.
    These same commenters touched on a different point and suggested 
that because the capability expressed by this certification criterion 
required EHR technology to be capable of displaying all of the test 
report information specified in the CLIA rules at 42 CFR 
493.1291(c)(1)-(7), that such capability should be enabled by default 
and must not be capable of being changed, overwritten, or deleted. They 
suggested this modification to the certification criterion because 
``CLIA mandates that the physician actually view the information.''
    Response. As we stated in the S&CC July 2010 Final Rule (75 FR 
44608) ``the scope of our authority under this final rule only applies 
to capabilities that Certified EHR Technology must include. As a 
result, we cannot provide the regulatory relief that these commenters 
seek.'' However, we would note that what the commenters have described 
could go a long way towards meeting the requirements set forth in 42 
CFR 493.1291. We encourage commenters to consult with CMS regarding 
particular implementations and questions with CLIA regulatory 
compliance. We also note that significant progress has been made to 
ensure that Direct Project specifications can be implemented in a CLIA 
compliant manner.
    With respect to the interpretation provided by the commenters, that 
``CLIA mandates that the physician actually view the information,'' we 
have consulted with CMS and seek to clarify that this interpretation is 
incorrect. The CLIA rules do not specify how results can be viewed by a 
provider, just that they can be accurately, timely, confidentially and 
reliably transmitted to the final destination. Laboratories need to 
verify that this occurred, as well as that the CLIA required elements 
were sent, but there is no requirement in the CLIA rules that a 
provider must be able to immediately view all of the information. Thus, 
we did not modify this certification criterion in response to the 
additional requirements suggested by the commenters as they would 
artificially lead to design limits that are unnecessary to impose as 
part of certification. We do, however, encourage EHR technology 
developers to present the laboratory test data in a format that is most 
useful to the provider who will use them.
     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--import and calculate).
Sec.   170.314(c)(3) (Clinical quality measures--electronic submission).
------------------------------------------------------------------------

    For the 2014 Edition EHR certification criteria, we proposed to 
revise previously adopted CQM certification criteria for the ambulatory 
and inpatient settings to more explicitly specify the capabilities EHR 
technology would need to include. These revisions focused on:
     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 which could be 
used 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.
     Report--the capability of EHR technology to create a 
standard data file that can be electronically accepted by CMS.
    We noted that by explicitly proposing separate CQM certification 
criteria focused on these discrete capabilities user experiences 
relative to CQMs could be enhanced, the burden of capturing data 
elements necessary for CQMs could 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
    We explained in the Proposed Rule that 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. We further explained how the National Quality Forum 
(NQF), under contract with CMS, created the Quality Data Model 
(QDM),\21\ which today serves as the information model from which new 
CQMs are specified. We explained that because older CQMs were not 
specified as ``EHR-ready'' when initially developed, they may 
implicitly 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 acknowledged in the Proposed Rule that we 
understood 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 further noted 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 in a consistent 
manner in order to facilitate CQM calculation.
---------------------------------------------------------------------------

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

    In the Proposed Rule, we explained that the CQM lifecycle in the 
EHR starts with the determination of data to be captured and the 
subsequent capture of clinical or demographic data. Thus, the first 
specific capability we proposed for CQM certification (Sec.  
170.314(c)(1)(i)) focused on the capability of EHR technology to 
electronically record all of the data elements that are represented in 
the QDM. More specifically, we stated that 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. We 
provided the following 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 ``state of being.'' We noted that 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, we acknowledged that 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

[[Page 54227]]

explicitly required to be recorded in other proposed certification 
criteria. We explained that 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 
did 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, we stated that 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.
    We recognized in the Proposed Rule that the gap between the data 
defined by the QDM and the data traditionally captured in EHR 
technology is, in some areas, broad. We requested 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. We also acknowledged that some specialty-focused EHR 
technologies may not need to capture all of the data that the QDM 
describes and requested public comment on how certification could 
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. Finally, we 
requested public comment with respect to whether we should pursue one 
or more of the alternative approaches below for certification in the 
final rule and made specific requests for public comment on those 
alternatives.
     CQM-by-CQM Data Capture: As an alternative to our proposal 
on certification for data capture, we considered a data capture 
approach that would be based on the data elements reflected in the 
individual CQMs selected by CMS instead of the entire QDM.
     Explicit Certification Criteria: We recognized that, in 
some cases, many EHR technologies already capture data elements 
included in the QDM even though they are not explicitly required by an 
adopted certification criterion. In these cases, we considered and 
believed 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, we noted that 
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, we stated that 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 reason.''
     CQM Exclusions: In cases where a CQM specifies a negation 
exclusion,\22\ we proposed that EHR technology would not be required to 
capture the ``reason'' justification attribute of any data element in 
an encoded way. Rather, we proposed to permit ``reason'' to allow for 
free text entries. For calculation and reporting purposes, we proposed 
that the presence of text in the ``reason'' field may be used as a 
proxy for any ``reason'' attribute.
---------------------------------------------------------------------------

    \22\ 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: Based on our work with CMS and NQF, we 
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. We noted that 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. We expressed that such CQMs would be 
identified as ``2014-EHR-ready'' while other CQMs would not. We stated 
that we would subsequently collaborate with CMS to remove CQMs that did 
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. We believed 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. We suggested that CDS could provide the interactive 
capability that would be required in order to capture the granular 
exclusion data that is expected today by many CQMs. We noted that with 
the inclusion of CDS in the clinical quality improvement strategy for 
future stages of this program, we expected to be able to remove the 
flexibility for the capture of ``reason'' attributes. This would 
improve the accuracy of CQMs while retaining optimal clinical workflow 
because CDS would ideally be engaged to prompt for this information 
only where indicated rather than in all cases.
     Explicit Data Capture List: The last approach we 
considered was (instead of specifying the QDM) 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. We explained that 
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
    In addition to being able to capture data elements for CQMs, we 
proposed that EHR technology presented for certification must be able 
to export this data in the event that an EP, EH, or CAH chooses to use 
a different certified EHR Module to perform the calculation of CQM 
results. We included the export capability as part of the certification 
criterion proposed at Sec.  170.314(c)(1). We indicated that this 
approach would preserve portability and flexibility and offer 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 an EHR Module certification for the 
services that they offer. We acknowledged that we were unaware of the 
existence of a widely adopted standard to export captured CQM data. We 
also proposed that 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. We recognized that 
this

[[Page 54228]]

scenario would not be ideal, but we believed 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. Finally, we requested comment on whether any 
standards (e.g., QRDA category I or III, 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.
Import and Calculate
    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 
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.
    We discussed that we previously adopted at Sec.  170.304(j) the CQM 
certification criterion for EHR technology designed for an ambulatory 
setting and expressed that it was treated as a threshold. We explained 
that, 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. We noted that if there was an additional CQM 
that the EHR technology included, CMS permits the EP to report on that 
CQM, even though it was not expressly listed on the CHPL. We also 
explained that 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. We noted that other EHR 
technology developers took the opposite approach and sought 
certification for more than the 9 CQMs and consequently, those EHR 
technologies were listed on the CHPL as being certified to more CQMs.
    We sought 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 believed this approach would provide 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.
    We proposed a separate certification criterion at Sec.  
170.314(c)(2) for the calculation of CQMs in anticipation 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 example, the calculation of CQMs could be performed with a 
commercial solution or the popHealth tool.\23\ The certification 
criterion we proposed included two specific capabilities. The first 
capability (Sec.  170.314(c)(2)(i)) 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. We explained that, for 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 did 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 requested public comment on 
this assumption before we added this exception to the certification 
criterion. In all other cases, an EHR technology would need to meet 
Sec.  170.314(c)(2)(i) and (ii).
---------------------------------------------------------------------------

    \23\ https://projectpophealth.org/.
---------------------------------------------------------------------------

    The second specific capability (Sec.  170.314(c)(2)(ii)) we 
proposed focused on an EHR technology's ability to calculate each CQM 
for which it is presented for certification. We clarified that 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, we 
emphasized that 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. We expressed our expectation 
that EHR technology certified to this criterion would be capable of 
accurately, and without errors, calculating CQMs and that the accuracy 
of these calculations would be verified through testing. We requested 
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 acknowledged that a scenario 
could arise 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. Recognizing that this scenario could 
present challenges for providers who possess licenses to such 
mismatched certified EHR modules, we requested comment regarding this 
scenario and its likelihood and any additional methods we could employ 
to mitigate this risk.
Reporting
    We proposed a certification criterion at Sec.  170.314(c)(3) to 
require EHR technology to enable a user to electronically create for 
transmission CQM results in a data file defined by CMS. We noted our 
expectation 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. We also anticipated that CMS would make available the XML data 
file template in time for us to adopt it in our final rule. We believed 
that this approach would give EPs, EHs, and CAHs a default solution for 
reporting CQMs electronically. We noted 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.
    We organized the comments and responses below using the same

[[Page 54229]]

subheadings we used in the Proposed Rule as well as other more specific 
subheadings on particular topics.
Capture
    Comments. Many commenters stated that certification to the entire 
QDM would place too much of a burden on EHR technology developers, 
noting that the QDM includes many data elements not traditionally 
captured in the EHR. Many commenters stated that ONC should require 
capture of only data elements that are contained within the CQMs that 
EHR technology developers chose to implement for calculation via their 
technology as opposed to a requirement that EHR technology capture all 
of the data elements required for calculation and reporting for all of 
the clinical quality measures or the entire QDM. Some commenters also 
noted that design and development for capture of the entirety of the 
QDM would be a distraction from much needed development of features and 
enhancements to existing technology. Many commenters also expressed 
concern with the clinical relevance of the entire QDM. Several 
commenters suggested ONC require EHR technology to capture to a 
constrained QDM as described in our Proposed Rule.
    Several commenters noted that the QDM is not intended as a 
certification standard, but as an extensible model for discussing the 
types of data that are included in quality measures, and that for an 
EHR to be usable, each of these pieces of information would need to be 
captured with appropriate standard terms, at appropriate points in the 
appropriate user's workflow. These commenters also stated that the 
scope of the work to be done to capture all of the data elements 
envisioned in the QDM is ``enormous.'' One commenter compared the 
capabilities of EHR software today against 2,100 of the category and 
attribute combinations in the QDM, and found that only 400 of the 2,100 
were always or usually captured in EHR workflows. More than half were 
never captured in EHR workflows. This commenter suggested that we 
publish a list of all data elements required for the CQMs included in 
the Stage 2 final rule rather than reference the QDM.
    One commenter suggested that ONC work to constrain the QDM by 
aligning parts of the QDM with ``core'' and ``optional'' CQMs.
    Some commenters suggested that EHR technology be required to 
capture all data elements that are components of the EHR Incentive 
Programs CQM measure set.
    One commenter suggested that we perform a full assessment of the 
data elements and associated attributes that are required by the QDM to 
determine if each of these are appropriate and required for CQM 
reporting.
    Some commenters stated that all EHR technology developers should be 
required to certify their EHR technology to all CQM data elements in 
the EHR Incentive Programs measure set to ensure that EPs, EHs and CAHs 
have the flexibility of selecting appropriate CQMs from the entire set 
to avoid situations where EHR technology developers have too much 
influence over provider quality improvement measures rather than the 
local institutions' quality improvement goals.
    One commenter stated that some Stage 1 CQMs require a level of 
clinical documentation and the capture of data that are far more 
extensive than the 2011 Edition EHR certification requirements and are 
not necessarily in common use. Furthermore, this commenter stated that 
some data for the inpatient measures comes from documentation that may 
be contained in written or dictated notes in the EHR and therefore not 
available in encoded form.
    A commenter stated that is critical that EHR systems support the 
collection of data from all sources, including from patients, nurses, 
other providers, and other systems and that quality measurement should 
not be dependent on the direct entry of data by EPs.
    Response. We agree that capture of the entirety of the QDM as a 
requirement for certification is not appropriate, and we know of no 
systematic constraints to the QDM, including a distinction between 
``core'' and ``optional'' measures that would meet the needs of our 
certification program for 2014. Yet, we are optimistic that a future 
version of the QDM may provide guidance for CQM developers on the 
feasibility of certain elements or element types for EHR technology. We 
may therefore incorporate the QDM and a QDM ``style guide'' in future 
rulemaking. We do not believe that it is appropriate for all EHR 
technology developers to have to seek certification for their EHR 
technology to all of the data elements necessary for all CQMs included 
in the Stage 2 final rule. We understand that there exist many EHR 
technologies that have been developed for specialty markets such as 
chiropractics, dentistry, ophthalmology, and wound care. Some CQMs are 
not relevant to the providers in these specialties and are therefore 
unnecessary to be built into the systems that they purchase. Such a 
requirement would cause these EHR technology developers to divert 
development resources away from the features and functionality that 
these providers need in future releases to functionality that would be 
present only for certification--and would never be used. It is our 
intent that this program aligns the functionality of CEHRT with the 
true clinical needs of EPs, EHs, and CAHs and, by extension, their 
patients. We agree that EHR technology developer selection of measures 
may impact the options available to providers, and we encourage the 
developers of EHR technology submitted for certification to present the 
broadest range of measures for certification possible, in order for 
EPs, EHs, and CAHs to have as much flexibility as possible in selecting 
measures for reporting under the EHR Incentive Programs. If EHR 
technology developers create sufficient functionality to meet EP, EH, 
and CAH needs in the future, we will not need to mandate an expansive 
requirement (such as a requirement to certify EHR technology for all 
CQMs selected for the EHR Incentive Programs) in subsequent rulemaking.
    We will therefore require EHR technology submitted for 
certification to Sec.  170.314(c)(1)(i) to be capable of capturing the 
data elements specified in the standard adopted at Sec.  170.204(c) 
(Data Element Catalog) \24\ as required for each and every CQM for 
which the technology is to be certified (the ``CQM-by-CQM Data 
Capture'' option discussed in our Proposed Rule (77 FR 13851)). For 
example, if EHR technology developer XYZ is seeking to certify their 
EHR technology for CQMs 1 through 10, 13, 15 and 22, then the EHR 
technology developer will need to review the list of data elements in 
the standard adopted at Sec.  170.204(c) for each of these CQMs and 
demonstrate that each of these data elements can be captured by the EHR 
technology. Also included in the standard adopted at Sec.  170.204(c) 
is a list of ``supplemental'' data elements required for CQM data 
submission to CMS. The list of supplemental data elements will be 
required for capture and transmission in each and every CQM report and 
includes (but is not limited to) race, ethnicity, sex, payer, Medicare 
HIC number, and where appropriate, NPI, CCN and TIN.
---------------------------------------------------------------------------

    \24\ https://www.nlm.nih.gov/healthit/dec/.
---------------------------------------------------------------------------

    We selected this option for several reasons. First, as noted above, 
there was strong support for this option in response to the Proposed 
Rule. Second, this option provides flexibility for EHR technology 
developers because it allows them to clearly understand the necessary 
data elements required to be captured for their customers (based on the 
CQMs for which they intend to seek

[[Page 54230]]

certification) rather than the entirety of the QDM. This is a 
significant improvement from our 2011 Edition CQM certification 
criteria, and will, in combination with a publicly available value set 
repository that the National Library of Medicine will release, assist 
EHR technology developers in meeting the requirements of CQM reporting. 
We believe that many of the historical problems with CQM reporting were 
due to the absence of accurate and complete data capture. A provider 
cannot accurately report on data from EHR technology that was not 
captured by EHR technology. With specific guidance and defining of the 
data that will be required for each CQM, we are now providing the 
foundation on which more accurate and reliable CQM reporting can be 
based. The supplemental data elements mentioned above are required by 
CMS, and will be important for the accurate processing, stratification, 
and assignment of CQM reports.
    EPs, EHs, and CAHs may employ many methods to capture the 
information required by CQMs and we do not intend for this criterion to 
imply that technology submitted for certification would be required to 
demonstrate manual data entry through a user interface (such as form 
fields or templates). Rather, the technology must be capable of 
capturing the information in some manner, and this includes information 
transferred from other systems (such as a practice management system, 
PHR, portal or kiosk).
    We appreciate the comments on the CQM measure set from the Stage 1 
Final Rule. Some EHR technology certified to the 2011 Edition EHR 
certification criteria do not capture all data elements of these CQMs 
as structured data, and we note that this was not explicitly required 
for 2011 certification. This will be required for 2014 certification, 
as described above.
CQM Exclusions
    Comments. One commenter stated that only exclusions that are 
clinically meaningful to ongoing care of the patient, for example, an 
allergy or drug intolerance should be required for CQMs in order to 
reduce the burden on documentation. Other commenters stated that 
negation rationales, exclusions and exceptions, should be minimized and 
be clinically relevant. Multiple commenters also suggested that 
negation rationales should not allow any free text submissions by 
providers, because free text would be very difficult to codify, use for 
decision support, or normalize or perform analytics.
    Many commenters expressed support for linking CQM and CDS to 
improve the quality of care and patient outcomes. Some commenters 
expressed concern that the linkage of CDS to CQM would lead to alert 
fatigue and if a 1:1 CQM:CDS intervention was required and that would 
be a burden to both developers and users of EHR technology. Commenters 
also expressed concern that our Proposed Rule does not include criteria 
for ``linking'' or ``relating'' CDS and CQM.
    Response. We appreciate the comments on our proposal regarding CQM 
exclusions. We agree that all data elements needed for CQM calculation 
should be discrete and codified. We don't believe that exclusions and 
exceptions must be captured to the granular level of detail described 
by a CQM that was developed for manual chart abstraction, but agree 
that where this granular data is available in coded form, it can and 
should be employed. In light of these comments, we will not require 
free text, but will permit that free text be captured and made 
available in addition to a codified entry. Codified entries may include 
specific terms as defined by each CQM, or may include codified 
expressions of the three global concepts: ``patient reason,'' ``system 
reason'' or ``medical reason.'' In addition, we appreciate the comments 
regarding linkage of CDS to CQM, and agree that this should not be an 
explicit requirement for 2014 certification, as we have not formally 
defined how CDS and CQM should be ``linked'' or how this would be 
tested. We do not intend to require a 1:1 requirement of CDS 
interventions to CQM. Rather, we suggest that EHR technology developers 
incorporate CDS interventions for the clinical areas in which they have 
selected to submit CQMs for certification. For example, if an EHR 
technology developer has selected to seek certification for NQF 0028 
``Preventive Care and Screening: Tobacco Use: Screening and Cessation 
Intervention,'' then we would recommend that they incorporate CDS that 
would enable their customers to assess their patients' smoking status 
and facilitate the documentation of smoking cessation interventions.
Data Export
    Comments. Several commenters supported standardized patient level 
data export capability as a certification criterion. A few commenters 
stated concern regarding the use of QRDA category I as an export 
standard noting that requiring a separate export format to support 
clinical quality measurement is an extra step in quality improvement 
with ``little value added'' that increases maintenance costs and 
represents an additional potential point of failure. One commenter also 
noted that many EHRs are, in fact, particularly highly modularized in 
the inpatient setting, noting that it is rare for a single module to 
include all the data necessary for calculation. Others noted that QRDA 
Category I standard is too narrow in focus to support calculation and 
analytics because not all of the data elements that would be required 
for calculation are included in a QRDA Category I report. A few 
commenters encouraged investigation to determine the feasibility of 
using the Consolidated CDA or other applicable standard to support the 
required export.
    Several commenters stated they did not believe that ``complete 
EHRs,'' which can calculate CQMs, should be required to support data 
export and that patient-level data export, should be optional.
    Other commenters argued in support of this requirement, and one 
noted that there would be value in a ``simple and standardized CQM data 
export format.'' One commenter expressed support for our approach to 
CQM export and believes that this approach ``will support both the 
development of certification standards for all CQMs and encourage 
interoperability among systems.''
    Response. We appreciate the comments on export of clinical quality 
data, and after careful review of these comments, we have decided to 
require this functionality for certification at Sec.  
170.314(c)(1)(ii). As stated in our Proposed Rule, for 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 EHR 
technology that meets the Base EHR definition, 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 will 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

[[Page 54231]]

that they offer. We requested comment regarding the appropriate data 
standard for this export functionality, and at the time of publication 
of our Proposed Rule, the HL7 QRDA Category I standard had not yet been 
successfully balloted. Several commenters noted that it was at that 
time too immature for inclusion in our regulation. QRDA Category I has 
now been successfully balloted through HL7, has been selected by CMS as 
an accepted form of quality data reporting, and will therefore be 
required for certification to Sec.  170.314(c)(1)(ii). We disagree that 
this criterion or this standard format provide little ``value added.'' 
Indeed, this standard provides, for the first time--a method of moving 
a ``snapshot'' of patient data from one EHR technology to another 
without loss of semantic integrity. We anticipate that there may be 
opportunities for this model to be of value beyond quality measurement 
in the future--such as in the domain of clinical decision support 
services.
Import and Calculate
    Comments. Many commenters supported certification of incorporation 
and calculation capabilities to each CQM. One commenter noted that some 
EHR technology developer products have been certified for CQMs with 
very light testing requirements and that the certification process for 
EHRs did not include testing the accuracy of the embedded measure 
calculations, nor did it examine whether the needed data were, in fact, 
available in the EHR. Several commenters described frustration with the 
lack of testing devoted to CQMs under the temporary certification 
program. One commenter expressed concern about errors encountered in 
measures that have been transcribed from paper abstraction to e-
specification. This commenter noted that the original measure developer 
specified measures for non-EHR use and in many cases did not e-specify 
the measures for EHR-use and that subsequent changes in measures occur 
with e-specification. This commenter called for a process to ensure 
comparable data calculations across EHR technology developers and 
hospitals and a systematic process to ensure these changes are broadly 
communicated and systematically incorporated. Multiple commenters 
suggested methods for the field testing of new measures. One commenter 
noted that there was minimal feasibility testing of CQM measure 
specifications for the Stage 1 CQMs.
    Response. We appreciate the comments on CQM calculation and 
testing. Through the rulemaking comment period and via additional 
channels, we have become aware of challenges that providers have faced 
in the use of technology certified under our 2011 Edition EHR 
certification criterion. Our proposed changes were intended to rectify 
these concerns. Notably, we have modified our proposal for Sec.  
170.314(c)(2) to finalize a more specific and clear certification 
requirement that EHR technology be able to import a QRDA category I 
file that has been generated by the ``export'' capability in Sec.  
170.314(c)(1)(ii) specified above. Unlike for the 2011 Edition EHR 
certification criteria for CQMs, EHR technology will be tested and 
certified for conformance with this capability. As we noted in the 
Proposed Rule, we now seek to provide express guidance to ONC-ACBs that 
when an EHR technology is presented for certification and includes 
capabilities to meet all three CQM certification criteria (i.e., the 
certification criteria adopted at Sec.  170.314(c)(1), (2), and (3)) 
that the capability to ``import'' as specified in Sec.  
170.314(c)(2)(i) will not need to be assessed. Given that the CQM 
capabilities within the EHR technology are in essence ``self-
contained,'' we believe that it is unnecessary to require EHR 
technology to be able to import data from itself. EHR technology that 
is eligible for this treatment would still have to meet all of the 
other specific capabilities required by all three of the CQM 
certification criteria. Finally, consistent with other terminology 
changes we have made, we changed the term ``incorporate'' to ``import'' 
in this certification criterion to provide more clarity regarding the 
action that is required to be demonstrated for certification. Note that 
in our discussion of Sec.  170.314(c)(1) (Clinical quality measures--
capture and export), we did not require that all data be directly 
entered through a user interface. Some data may flow into EHR 
technology through other means. These functions are not required for 
certification, nor will they be tested as part of the certification 
process.
    We appreciate the comments on e-specification of chart-abstracted 
measures, but note that many comments about the selection, content, and 
management of the CQMs are beyond the scope of this final rule. We 
appreciate the value of reliability and validity testing for CQM 
technical specifications and support testing of CQMs prior to public 
release. CMS is responsible for CQM testing and we defer to their 
comments on this subject in their Final Rule that is published 
elsewhere in this issue of the Federal Register. We also appreciate the 
many comments in reference to feasibility testing. Feasibility testing 
in preparation for Stage 2 of MU has been enhanced in order to minimize 
variation and post-specification modifications to electronically 
specified CQMs.
Electronic Submission
    Comments. Commenters were supportive of our proposal. One commenter 
suggested that the XML file format should be a valid standard that has 
been tested for accuracy and completeness. Another commenter expressed 
agreement with the use of aggregate XML and recommend that the 
technical structure align with 2011 Physician Quality Reporting System 
registry reporting. One commenter suggested that we employ the Core 
Measure XML and particularly The Joint Commission's ``HCD'' XML.
    Response. We referred to this capability as ``reporting'' in the 
Proposed Rule, but now refer to this capability as ``electronic 
submission'' in this final rule and in regulation. This renaming more 
accurately reflects the required capability, which is the ability to 
create a file in a particular format and be capable of submitting that 
file to CMS in a manner that CMS is able to accept. We appreciate the 
supportive comments regarding a standard XML format and aggregate 
reporting methods. In order to provide CQM file submission flexibility 
for EPs, EHs and CAHs, CMS intends to offer several reporting methods 
from which providers will choose, as described in the Stage 2 final 
rule published elsewhere in this issue of the Federal Register and is 
considering other mechanisms/methods that could be implemented or 
relied upon in the future. In this regard, we believe that EHR 
technology should be capable of creating CQM data files that would 
support the forms of electronic submission that CMS makes available to 
EPs, EHs, and CAHs. Therefore, we have adopted both the HL7 QRDA 
Category I standard to support a patient level data submission approach 
and HL7 QRDA Category III to support an aggregate level data submission 
approach.
    As noted above, we proposed that the electronic submission 
capability would require EHR technology to generate an (XML) data file 
with aggregate CQM calculation results in the format CMS would have the 
capacity to accept. CMS has since specified that the optimal XML format 
for aggregate reporting will be the HL7 QRDA Category III. CMS has also 
made a policy decision to provide an option for patient-level 
reporting. CMS has specified that the optimal XML format for patient-
level reporting will be

[[Page 54232]]

the HL7 QRDA Category I. Although these standards were in development 
at the time of our Proposed Rule, QRDA Category I has now been balloted 
through HL7, and QRDA Category III is much more complete than it was at 
the time of the Proposed Rule, with balloting scheduled in the near 
future. We understand that the timing of the QRDA Category III 
balloting is suboptimal, but note that the alternative would have been 
for CMS to develop its own XML specification for a format that performs 
precisely the same functionality as QRDA Category III. This would have 
been redundant of the QRDA Category III effort and could have adversely 
affected its progress. We also note that the patient-level reporting 
standard (QRDA Category I) is the same standard as the standard we have 
adopted for the ``export'' capability in Sec.  170.314(c)(1). 
Therefore, we anticipate that the burden on EHR technology developers 
that also submit EHR technology for certification to this certification 
criterion will be minimal.
    In general, we expect that providers who choose to submit aggregate 
reports will use the standard specified at Sec.  170.205(k) (HL7 QRDA 
Category III), and providers who choose to submit patient-level reports 
will use the standard specified at Sec.  170.205(h) (HL7 QRDA Category 
I). We require that EHR technology, regardless of the setting 
(inpatient or ambulatory) for which it was designed, be certified to 
produce CQM data that could be submitted by an EP, EH, or CAH according 
to either standard. While the HL7 QRDA Category III standard has not 
yet been successfully balloted, we expect it to become a normative 
standard in the near future. Further, we agree with and support CMS's 
decision to select this format rather than developing its own CMS-
defined XML template because QRDA Category III is a product of several 
years of industry consensus work. EHR technology presented for 
certification will therefore need to be certified as being capable of 
creating results for transmission to CMS according to both reporting 
standards (Sec.  170.205(h) (HL7 QRDA Category I)) and Sec.  170.205(k) 
(HL7 QRDA Category III)).
    We note for readers that we have modified this certification 
criterion to more explicitly address the fact that CMS must be able to 
receive an electronic data file created by EHR technology and submitted 
by an EP, EH, or CAH. If this could not occur then, arguably, the most 
important aspect of what certification was intended to support would go 
unmet. Accordingly, we have added to this certification criterion, not 
only that EHR technology be able generate both QRDA Category I and QRDA 
Category III data files, but that such files can also be electronically 
accepted by CMS. This explicit requirement creates two benefits while 
also reducing regulatory burden due to CMS' intended programmatic 
alignment efforts. It benefits providers and CMS in that each will know 
as a result of certification that when EHR technology is used to 
electronically submit a QRDA Category I or III that CMS will be able to 
receive it. With respect to testing, we expect to approve a test 
procedure for this certification criterion that will assess an EHR 
technology's ability to create data files conformant to the QRDA 
Category I and III standards, and upon a positive conformance 
assessment, verify that these data files could be accepted by CMS. If 
the data files were conformant and verified by the accredited testing 
laboratory in terms of their ability to be accepted by CMS, then the 
EHR technology would have fully demonstrated compliance with this 
certification criterion.
     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)).
------------------------------------------------------------------------

    We proposed two revised certification criteria at Sec.  
170.314(d)(2) and (3)--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). We also proposed 
to 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. We made these 
proposals based on HITSC recommendations as well as stakeholder 
feedback that indicated splitting the 2011 Edition certification 
criterion into two separate certification criteria would permit a wider 
variety of EHR technologies to be certified as EHR Modules. We also 
expanded upon the scope of the HITSC's recommendation to address input 
from the HHS Office of Inspector General (May 2011 report \25\) and to 
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. The proposed expansion included 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 proposed a revised standard at Sec.  
170.210(e) and proposed 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. 
Finally, we acknowledged, as recommended by the HITSC, that an example 
standard that 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.
---------------------------------------------------------------------------

    \25\ https://oig.hhs.gov/oas/reports/other/180930160.pdf.
---------------------------------------------------------------------------

    General Comment Summary. Many commenters generally supported the 
more detailed certification criteria and the standards we proposed. 
Comments on the two certification criteria and standards we proposed 
focused on a number of different dimensions. The following comment 
summaries and responses address each of these dimensions.
    Comments. Many commenters requested clarifications related to the 
proposed certification criterion's first specific capability--that the 
auditable events capability be ``enabled by default.'' Many commenters 
noted that our proposal essentially skipped a step from an 
implementation perspective. They contended that the certification 
criterion should include, make reference to, or that we should make 
clear that the certification criterion did not prohibit the audit 
recording capability or service from being be subject to some type of 
initial configuration. Further they stated that once initial 
configuration was

[[Page 54233]]

complete the audit log could be ``enabled by default.'' Another 
commenter stated that audit logs should not be enabled by default by 
EHR technology developers because the decision of whether settings in 
the software are enabled or disabled are the responsibility of each 
organization, not the EHR technology developer. Additionally, this 
commenter and others indicated that EHR technology developers cannot 
enable the audit logs of organizations that already have this 
capability in use.
    Response. We understand the concerns raised by commenters and seek 
to clarify this proposal as follows. It appears that by including the 
parenthetical ``(i.e., turned on)'' that we confused many commenters 
because, as they noted, steps needed to occur before the auditing 
service could actually be ``turned on.'' We acknowledge that 2014 
Edition EHR technology will need to be setup and configured at each 
practice or hospital in which EHR technology with this capability is 
installed. This certification criterion is not meant to prohibit such 
configuration. Rather, what this certification criterion expresses (and 
what we have made clear in modifications to the certification 
criterion) is that in order for the EHR technology to be certified it 
must be set by default to record the actions and information specified 
in the standards referenced by the certification criterion. Thus, this 
part of the certification criterion is meant to ensure that at the 
point of installation or upgrade EHR technology certified to this 2014 
Edition EHR certification criterion, the EHR technology will be set by 
default for an EP, EH, or CAH to record the actions and information 
specified in the standards referenced by the certification criterion.
    Comments. Commenters also expressed a set of concerns with respect 
to another element included in the proposed certification criterion's 
first specific capability--that only a limited set of identified users 
be permitted to be disable (and re-enable) the capability to record 
auditable events. Some commenters, typically EHR technology developers, 
referenced that some EHR technologies do not include any capability at 
all for users to change (enable/disable) auditable event recording. As 
such, these commenters stated that the final rule should accommodate 
this approach with respect to certification. Further, commenters agreed 
that if auditable events can be disabled, that it only be able to be 
done so by a limited set of users. Echoing that this provided 
separation of duties, so that a user who is able to access or make 
changes to a patient's health information is not also able to modify 
the audit log to remove traces of suspicious activity. One commenter 
stated that since EHR technology cannot interpret the meaning of 
``limited,'' that we should change the wording to `` * * * by 
authorized users.'' Another commenter noted that it may be necessary to 
turn off the auditable events capability for performance, patching, or 
other events.
    Response. In response to comments, we have modified the 
certification criterion to make the accommodations requested. As noted 
by at least one commenter, the practice indicated by others to never 
permit anyone to be able to disable an audit log is not uniformly 
applied in EHR technology. Therefore, we have reframed and reordered 
the specific capabilities within the certification criterion. As a 
general rule, the certification criterion identifies the actions and 
statuses that EHR technology must be able to record. The actions 
related to electronic health information are listed first; the change 
in audit log status second; and the change in encryption status of 
electronic health information locally stored by EHR technology on end-
user devices third. With respect to the latter two (the two status 
oriented requirements), we have included conditional statements as 
requested by commenters to permit EHR technology to meet this 
certification criterion if the EHR technology developer can demonstrate 
that no user has the ability to change those statuses. Further, we have 
reworded and moved to the third specific capability within this 
certification criterion the separation of duties aspect that many 
commenters endorsed. This modified requirement specifies that if EHR 
technology permits the recording of auditable actions or statuses to be 
disabled the ability to do so must be restricted to a limited set of 
identified users. We decline to modify this certification criterion in 
response to the commenter's suggestion to change the wording related to 
``limited'' set of identified users because the commenter has 
misinterpreted the requirement that the certification criterion 
specifies. EHR technology does not have to interpret the meaning of 
``limited.'' Rather, to meet this certification criterion, EHR 
technology would need to include a capability that allows only a 
limited set of identified users (by the EP, EH, or CAH) to be have the 
privileges necessary to change when auditing is enabled or disabled. In 
general, we do not expect and would discourage any general EHR 
technology user from being permitted to perform such actions.
    Comments. Some commenters requested clarification on the meaning of 
``as applicable'' in the ``auditable events'' certification criterion 
and accompanying standard with respect to auditing the encryption 
status of end-user devices managed by EHR technology. Consistent with 
other comments provided in terms of the capabilities within the scope 
of an EHR technology's control, commenters noted that ``as applicable'' 
in this context should be if an EHR technology developer supplied the 
end-user device and if the sole purpose of the device is to use the EHR 
technology. In other words, tracking the enabling and disabling of 
encryption on health care providers' personal devices (such as smart 
phones) should not apply.
    Response. The phrase ``as applicable'' was originally intended (in 
this proposed certification criterion and standard) to accommodate 
situations where the EHR technology did not locally store electronic 
health information on any end-user devices. In general, we agree with 
commenters that tracking the enabling and disabling of encryption on 
health care providers personal devices would not apply, because the 
primary certification criterion implicated by this requirement 
(170.314(d)(7)) is not applicable to all end-user devices. However, we 
note for commenters that this situation is fact dependent and could 
apply to the health care provider's personal device if EHR technology 
is run on the device and locally stores electronic health information 
on the device after use has stopped. Consistent with the changes 
discussed in our responses above, we believe the certification 
criterion has been clarified. Further we have removed the phrase ``as 
applicable'' in the standard listed at 170.210(e) in favor of more 
plain language usage in the certification criterion itself.
    Comments. Several comments applied to the standards we proposed to 
adopt and associate with the proposed ``auditable events'' 
certification criterion. Consistent with other comments summarized 
above, commenters asked that we accommodate situations where EHR 
technology does not allow for an audit log to be disabled or when it 
does not permit the encryption of electronic health information managed 
by EHR technology on end-user devices to be disabled. Other commenters 
suggested that we rely on SDO standards compared to the enumerated 
requirements we specified in the proposed standard at 170.210(e). They 
reasoned that an SDO standard has undergone much more extensive review

[[Page 54234]]

and socialization than the list of requirements embedded in the 
proposal and that an SDO standard is much more broadly adopted than a 
``standard'' embedded in a regulation, and therefore more likely to 
take on uniform interpretation. Along those lines, they suggested that 
the ASTM E2147 standard we referenced in the proposed rule would be 
preferred over enumerating a list of requirements embedded in 
regulation. One commenter further suggested that a variety of HL7 and 
ASTM standards be referenced by this certification criterion to denote 
information objectives, actions, structural roles, participation 
function codes with security permissions, and data types to encode user 
identification. Another commenter asked that we clarify if the part of 
the ASTM E2147-01 standard that deals with disclosures has 
applicability to this certification criterion. One commenter suggested 
that we clarify that audit logging requires at a minimum date, time, 
and user id to determine who accessed certain electronic health 
information. With limited exceptions, commenters generally supported 
the adoption and application of the clock synchronization standards we 
had proposed.
    Response. As discussed in the responses directly above related to 
changes already made to the certification criterion, we do not believe 
that it would be necessary or appropriate to include the conditional 
language suggested by commenters in the standards (and have since 
removed it from what we proposed). We agree with commenters that we 
should leverage SDO produced standards wherever possible and not embed 
an enumerated list in regulation. Accordingly, and as suggested by 
commenters, we analyzed ASTM E2147-01(2009) and believe that it 
includes an equivalent set of requirements as we proposed. Thus, the 
standards we express now refer to the appropriate sections of ASTM 
E2147-01(2009), rather than an enumerated list. For the first specific 
capability related to actions involving electronic health information, 
we have required that the data elements specified in sections 7.2 
through 7.4, 7.6, and 7.7 of ASTM E2147-01(2009) be captured. For the 
other two specific capabilities related to the status of the audit log 
or the encryption status of electronic health information managed by 
EHR technology on end-user devices, we have required that the data 
elements specified in sections 7.2 and 7.4 of ASTM E2147-01(2009) be 
recorded. All three of these standards require that the user ID, date 
and time be recorded. We note that not all of the section 7.X parts of 
the ASTM E2147-01(2009) standard have been specified as they go beyond 
what we proposed to include. Thus, we seek to make clear that only 
those sections in section 7 that we have explicitly included in our 
standards are the minimum required for certification.
    We decline to modify the certification criterion in response to the 
commenter's suggestion that we include a variety of standards to denote 
information objectives, actions, structural roles, participation 
function codes with security permissions, and data types to encode user 
identification. We did not propose such specificity, nor did the HITSC 
recommend that we include such specificity in the certification 
criterion. As we have noted in other responses, certification is a 
minimum. Thus, where additional standards exist and can be used to 
further improve capabilities for which certification is required, we 
encourage EHR technology developers to consider doing so. As requested 
by a commenter, we confirm that the ``disclosure log'' section (section 
8) of ASTM E2147-01(2009) has no applicability to this particular 
requirement.
    Last, we are finalizing the changes we discuss in this response as 
well as our proposal to adopt the clock synchronization standards we 
proposed.
    Comments. Numerous commenters requested different clarifications 
related to the expected granularity of actions and information to be 
recorded. A commenter suggested that the granularity of electronic 
health information be limited to the metadata involved in identifying 
the patient whose record has been accessed, be sufficient for recording 
actions, and that it not require lower level clinical data objects to 
be logged if appropriate context of what kinds of information is logged 
is otherwise recorded. Another recommended that the certification 
criterion be more explicit in describing the level of how the ``action 
taken'' should be captured in terms of what was done, the data, and how 
it was changed. Yet another suggested that the information logged 
should be sufficient to enable a system administrator to identify, for 
example, that a specific patient's order that was modified, deleted, 
etc., or that a user accessed a patient's medication list. Other 
commenters raised concerns about the about the granularity of the 
information recorded in the audit log and its potential to include 
electronic health information. They contended that requiring this level 
of specificity would inappropriately duplicate clinical information in 
the audit log and could cause greater security issues. Instead, they 
suggested that the type of data acted upon should be the proper scope 
of this certification criterion and that implementing this approach 
would be more feasible and less costly. Further, these commenters 
expressed concern that the certification criterion could be interpreted 
to require very granular auditing which would adversely impact system 
performance and place undue burden on security auditors who may not be 
able to find the information they need. They argued that requiring this 
type of very granular auditing may introduce a burden on EHR adopters 
because of the amount of disk space required to store these audit logs. 
Other commenters stated that the scope of the data recorded should not 
be at the same level as a ``history table'' or ``action/event history 
table.'' Commenters indicated that the clinical level of detail 
included in those tables is appropriate to maintain the wholeness of 
clinical documents and data, but not for security audit trails. 
Instead, commenters suggested that HHS consider adopting a ``medical 
record history and completeness'' objective that is not related to 
security auditing.
    Response. We appreciate the detail and thoughtfulness of the 
comments submitted on this certification criterion. In consideration of 
comments received, we agree that further explanation is necessary 
related to the scope and granularity of the information expected to be 
recorded. Given that we are now referencing relevant sections of ASTM 
E2147-01(2009), we believe that this standard reinforces what we would 
have said had we maintained our enumerated requirements. Section 7.7 of 
ASTM E2147-01(2009) discusses the ``identification of patient data that 
is accessed.'' It states that the ``granularity should be specific 
enough to clearly determine if data designated by federal or state law 
as requiring special confidentiality protection has been accessed.'' 
And, more to the point, Section 7.7 goes on to state that ``[s]pecific 
category of data content, such as demographics, pharmacy data, test 
results, and transcribed notes type, should be identified.'' We agree 
with commenters and understand the burden and security and privacy 
concerns issued as well as the disk space limitations referenced. Thus, 
we believe that it is appropriate for actions made to electronic health 
information and recorded in the audit log to be identified at a 
categorical (or type) level--this is also consistent with the guidance

[[Page 54235]]

included in ASTM E2147-01(2009). For instance, as noted by a commenter, 
we believe that the ability of the audit log to record that a user 
accessed a patient's medication list would be sufficient for 
certification and that the audit log would not have to also record the 
specific medication.
    Comment. One commenter asked whether we intended for the 
certification criterion to require that relevant information be 
captured in a manner that supports the forensic reconstruction of the 
sequence of changes to a patient's chart or if we intended for the 
certification criterion to require that users be provided with on-
demand snapshot views of the patient chart at any point in time with a 
highlighted comparison of data which is changed at any given moment. 
This commenter preferred the former because it stated that in order to 
implement the latter EHR technology developers would need to expend 
substantially more effort into the development of user interface 
capabilities, which would be used only in rare circumstances.
    Response. We intend for the former, as stated by the commenter, 
that the actions and information can be captured in a manner that 
supports the forensic reconstruction of the sequence of changes to a 
patient's chart.
    Comments. Commenters almost unanimously focused on the scope of the 
proposed certification criterion's third specific capability--that 
actions record must not be capable of being changed, overwritten, or 
deleted. Commenters' feedback included a range of different opinions. 
One commenter noted that this certification criterion should focus on 
access and alterations, while being cautious about pursuing attainment 
of immutable audit logs and detection of audit logs because the EHR 
technology can still be circumvented by select individuals with 
malicious intent. Another indicated that there were other techniques 
such as using separate hardened audit log technologies and suggested 
that this capability be met by proving separation of duty for security 
auditors and clinical EHR end users, detection of changes in audit 
system configuration to the extent it is allowed by the audit system 
for recording, and audit log abilities that may be present in the audit 
log solution itself for detecting accesses to the log. The majority of 
commenters noted that from a technological perspective there is only so 
much that is within the control of the EHR technology. These commenters 
sought clarifications in terms of the extent to which EHR technology is 
responsible for preventing changes, overwrites or deletions to the 
audit log. Several provided similar examples referencing the fact that 
users could access a file or database used by the EHR technology 
through the operating system on top of which the EHR technology may run 
or by directly accessing the database in which the audit information is 
stored. In general, all of these commenters requested that we should 
limit the scope of this specific capability to make clear that the 
audit log should not be able to be changed, overwritten or deleted 
through the EHR technology by its users.
    Response. We appreciate the detailed responses and examples offered 
by commenters. As noted by many commenters, we acknowledge that there 
is only so much that is within the control of EHR technology and that 
nothing is ever 100% impenetrable. Thus, we have revised this specific 
capability within the certification criterion to state that the audit 
log must not be capable of being changed, overwritten, or deleted by 
the EHR technology. We believe this addition properly scopes the 
capability for which certification is required and will address 
commenters' concerns. As discussed in other responses, where the EHR 
technology permits the auditable actions and statuses to be disabled, 
we have required that some form of separation of duty be implemented in 
that only a limited set of identified users should be able to modify 
audit settings.
    Comments. Several commenters expressed concern that the proposed 
certification criterion's third specific capability we proposed--that 
actions recorded must not be capable of being changed, overwritten, or 
deleted--did not permit the deletion of the audit log. Further 
commenters stated that this specific capability disallows the purging 
of audit logs after the required legal retention period has expired. 
They recommend adding ``except when disposing of log information after 
a legally defined retention period.'' Another commenter expressed a 
similar concern with the implications of an ``immutable'' audit log. 
They stated that data may not be kept on the same physical device as it 
ages and that data is ``added'' to another device and ``deleted,'' and 
thus cannot be ``immutable.'' They also stated that immediate storage 
of an audit log on ``write once read many'' (WORM) technology is not 
practical in all configurations.
    Response. We are uncertain as to what in the Proposed Rule led 
commenters to make this interpretation since this certification 
criterion focuses on a capability that EHR technology would need to 
include. It was not our intention, nor did the certification criterion 
specify, that audit logs could not be deleted or purged after a legal 
retention period. Such a step would be an organizational policy 
decision and not within the scope of certification. Thus, we decline to 
make the more detailed suggested modifications. However, to make it 
clear that such steps are not prevented by the certification criterion, 
we have added to the specific capability related to the audit log's 
immutability that the audit log must not be capable of being changed, 
overwritten, or deleted by the EHR technology. We believe this addition 
properly scopes the capability for which certification is required and 
will address commenters' concerns.
    Comments. A few commenters indicated that they believed an 
inconsistency existed between the proposed certification criterion's 
third and fourth specific capabilities. Commenters noted that if the 
certification criterion requires that an audit log not be capable of 
being changed, overwritten, or deleted that it was unclear why we would 
also require EHR technology to detect an alteration to the audit log. 
The commenters questioned whether the third specific capability 
rendered the fourth capability moot and if the fourth was still 
necessary. Last, a commenter requested clarification regarding what 
would constitute an alteration of an audit log.
    Response. Given the reordering of the specific capabilities within 
this certification criterion and the clarification that we made above 
regarding the scope of the now finalized fourth specific capability 
``(iv)'' (that requires that an audit log not be capable of being 
changed, overwritten, or deleted by the EHR technology), we believe 
that it is also necessary to clarify the scope of the specific 
capability we proposed regarding EHR technology's ability to detect an 
alteration to the audit log. This specific capability, which is now 
designated as the fifth specific capability ``(v),'' has been revised 
to state that ``EHR technology must be able to detect whether the audit 
log has been altered.'' We believe that this specific capability 
complements the other capability specified at (d)(2)(iv) from a 
defense-in-depth perspective. Further, we clarify that this specific 
capability requires EHR technology to be able to determine whether 
activity outside of its control has in some way altered the audit log 
(e.g., that the operating system was exploited to modify the EHR 
technology's database). In this respect, the EHR technology will be 
able to detect whether its audit log has been corrupted. While this may 
not

[[Page 54236]]

be the only approach EHR technology developers can use, we encourage 
the use of hashing algorithms specified in FIPS 180-4 (Secure Hash 
Standard) to determine whether the audit log has been altered.
    Comments. Commenters strongly supported the two certification 
criteria we proposed from the single 2011 Edition EHR certification 
criterion. Further, a commenter encouraged that testing and 
certification for these two certification criteria should be done 
independently to allow for separate security audit log technologies to 
be presented for certification as EHR Modules. This commenter urged 
that there should not be a dependence for an EHR technology developer 
of a free standing audit log reporting technology to certify with each 
and every source EHR that may send it audit events and data as if a 
business partnership were required to do so. In essence the commenter 
sought clarification that it was possible for the certification 
criterion proposed at 170.314(d)(3) to be certified independently and 
on a standalone basis.
    Response. Yes, it is possible for EHR technology to be 
independently certified to 170.314(d)(3). We proposed two separate 
certification criterion for exactly this reason. Previously the 2011 
Edition EHR certification criterion required that EHR technology 
demonstrate both the recording of auditable events and the report 
generation in order to be certified. With this separation EHR 
technology can be separately certified to perform these two 
capabilities. A stand-alone EHR Module for audit log reporting would 
not need to certify with each and every source EHR technology that may 
send it auditable events. In order to meet the certification criterion 
the EHR technology would need to demonstrate that it could capture the 
required data.
    Comments. We received only a few comments on the proposed audit 
reports certification criterion at 170.314(d)(3). They expressed 
support for the proposed certification criterion and one commenter 
requested clarification of the expectation for reports generation.
    Response. We appreciate commenters' support. We are finalizing the 
certification criterion as proposed. This certification criterion 
expresses the capability that EHR technology must 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 
standards at Sec.  170.210(e). Anything beyond that requirement is 
beyond the scope of certification and likely depends upon 
organizational policy.
     End-User Device Encryption

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
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) (End-user device encryption).
------------------------------------------------------------------------

    In the Proposed Rule, we proposed to revise the ``general 
encryption'' certification criterion adopted at Sec.  170.302(u) as 
part of the 2011 Edition EHR certification criteria 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. We proposed this revised approach because we 
thought it would be more practical, effective, and easier to implement 
than the otherwise general encryption requirement adopted at Sec.  
170.302(u). Further, we agreed with the HITSC 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 protected health information \26\). 
The OIG provided similar rationale in its May 2011 report (previously 
cited under the discussion of the ``auditable events and tamper-
resistance'' and ``audit report(s)'' certification criteria) in which 
it recommended that ONC address IT security controls for encrypting 
data on mobile devices. The proposed certification criterion was 
drafted to permit EHR technology developers to demonstrate in one of 
two ways that a Complete EHR or EHR Module is compliant.
---------------------------------------------------------------------------

    \26\ https://www.hhs.gov/ocr/privacy/hipaa/administrative/breachnotificationrule/breachrept.pdf.
---------------------------------------------------------------------------

    The first proposed way, Sec.  170.314(d)(7)(i), accounted for 
circumstances in which EHR technology was designed to manage electronic 
health information on end-user devices 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 clarified that we 
intended for the term ``stopped'' to mean that the session had been 
terminated, including the termination of the network connection. We 
stated that 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), that 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 determined it was best to 
focus certification on the most critical capability, the act of 
encryption after use of the EHR technology on the end-user device has 
stopped. Last, we explained that the phrase ``manages electronic health 
information'' in the certification criterion meant that the EHR 
technology was designed in a way that it could 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. We stated, for 
example, that if an EHR technology was 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 specified at Sec.  170.314(d)(7)(i) in order to be 
certified.
    The second proposed way to demonstrate compliance with this 
certification criterion was for an EHR technology developer to 
demonstrate that its EHR technology could 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 explained that this alternative method was 
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).
    Comments. Many commenters offered their support for this 
certification criterion. One applauded the decision to allow the option 
to either encrypt end-user devices or make sure no data remains on end 
user devices managed by the EHR technology. Several noted that since a 
majority of breaches by

[[Page 54237]]

HIPAA covered entities or their business associates have been due to 
lost or stolen unencrypted portable media, requiring default encryption 
functionality for end-user devices managed by CEHRT should help reduce 
health data breaches. Another commenter indicated that this security 
measure has largely been ignored and agreed that making encryption a 
requirement for EHR certification should help spur industry to protect 
data security.
    Response. We thank commenters for the positive feedback. As we have 
stated elsewhere in this final rule, we believe that certification can 
help to ensure that in adopting CEHRT EPs, EHs, and CAHs have technical 
capabilities that they can use to enhance their security practices and 
make compliance with other regulatory requirements more efficient.
    Comments. A few commenters requested clarification of the term 
``stopped.'' One suggested that we include ``in the prescribed 
manner.'' A second referenced ``prescribed manner'' and stated that 
they thought it would be difficult to test that an EHR technology never 
leaves electronic health information on an end-user device when it is 
terminated in the prescribed or non-prescribed manner. They encouraged 
that attestation be permitted for the test procedure. Another suggested 
that we consider whether ``stopped'' includes abnormal termination of a 
session and a network connection versus normal termination. They 
explained that routines that manage temporary storage may only be part 
of normal session termination whereas there may be processes to 
preserve images or caches for session resumption in the case of an 
abnormal termination that could pose risk by persisting health 
information in order to prevent data loss when an abnormal interruption 
such as battery failure or power outage to the device occurs.
    Response. We decline to modify this certification criterion to add 
``in a prescribed manner.'' We do not believe that this qualifying 
phrase is necessary or adds significant clarity to the proposed 
certification criterion. We continue to believe that our general 
description of ``stopped'' in the proposed rule (``that the session has 
been terminated, including the termination of the network connection'') 
is sufficient for this certification criterion. In other words, use of 
EHR technology is considered to be stopped when a user closes or exits 
the EHR technology application and would need to re-execute the EHR 
technology application to again engage in use. However, we acknowledge, 
as commenters pointed out, that there could be predictable/prescribed 
stops and unpredictable/abnormal stops (i.e., power or battery 
failure). For the purposes of certification to this 2014 Edition EHR 
certification criterion, we clarify that testing and certification will 
focus on normal terminations. We will consider whether more advanced 
and rigorous testing and certification requirements for future editions 
of certification criteria would be necessary. In the following 
responses when we refer to ``stop'' or ``stopped,'' we are referring to 
normal stops.
    Comments. Numerous commenters requested clarification regarding the 
phrase ``managed by'' in the certification criterion. Along those lines 
many asked that we clarify the certification criterion's scope and 
applicability. Some stated that we should clarify that it only applies 
to storage capabilities that are designed for use with EHR technology 
developer provided or supported technologies for desktop, laptop, 
mobile, cellular based technologies or similar technologies, and not to 
capabilities that may be present in technology components such as 
operating systems, swap files, and memory management technologies that 
are embedded and non-configurable as to their use by the EHR system 
(since the EHR technology developer is unable to change those 
capabilities). These commenters suggested that this certification 
criterion be applied to the deliberate use of storage capabilities that 
are configurable or to the management of caching files that the EHR 
technology developer, by design, elects to use and manage on such 
devices. One commenter asked whether the EHR technology is expected to 
enforce encryption or if it must be capable of notifying the receiving 
device that the data being downloaded contains electronic health 
information and therefore such data must be encrypted.
    A few sets of comments on the ``managed by'' concept included 
detailed information on two points. The first asked whether we had 
intended for the certification criterion to apply only in cases where 
the EHR technology has control over the ability of the user to store 
data on their device, installs a client application, etc. This 
commenter suggested that the language in the certification criterion 
may be unclear when it is read in isolation, outside of the preamble. 
Further, this commenter noted (as was echoed in a different comment) 
that the meaning of the term ``managed by'' was missed by many of its 
contributors and that many assumed that the certification criterion 
required the EHR technology to enforce encryption on any mobile or 
portable device. The second point addressed a technical concern and 
limitation. Commenters stated that the operating system or other 
technology on the end-user device may cache electronic health 
information and retain it after use of the EHR technology on an end 
user device has stopped. They indicated that, for example, swap and 
cache files, sleep and hibernate features, and application context 
switching in Windows 8 Metro apps or iOS may all cause electronic 
health information to be cached to disk. Similarly, they stated that 
some browsers do not respect ``no-cache'' headers, potentially leading 
to electronic health information being cached on the end-user device if 
users access the EHR with a non-vendor supported browser. Additionally, 
commenters indicated that these instances were beyond the control of 
the CEHRT and are subject to user configuration and control to achieve 
the desired objective. These commenters requested a reasonable 
clarification of the term ``manage'' and stated that it would be 
unreasonable to expect EHR technology to control how operating systems 
and other technologies perform memory management and that they did not 
consider this information to be managed by the EHR technology.
    Last, a commenter asked who was responsible for encryption on end-
user devices (e.g., EHR developer, covered entity/business associate, 
etc.). They stated that in practice this requirement will affect all 
desktops--even home computers--that cache content from web-based EHR 
systems. Further, they questioned how this requirement interacted with 
the proposal that the encryption capability must only be disabled by a 
limited set of identified users.
    Response. We appreciate the detailed and thoughtful feedback 
provided by commenters. Because all of the comments revolved around the 
phrase ``managed by,'' we believe it will be most effective to respond 
to the general clarifications up front and then explain the revisions 
we have made to this proposed certification criterion. We believe this 
approach will be clearer and more efficient with respect to how we 
interpret this certification criterion than if we were to individually 
address each specific comment within this comment summary.
    As noted in the Proposed Rule, we proposed this certification 
criterion to focus and encourage EHR technology developers to design 
secure implementations and equip EHR technology with the ability to 
assist users in keeping end-user devices

[[Page 54238]]

secure. End-user devices can pose a specific vulnerability, especially 
as they become more prevalent and computationally powerful.
    Given the uniform confusion surrounding the phrase ``managed by,'' 
we have revised this certification criterion to functionally describe 
the event that we had intended to capture with the phrase--the local 
storage and persistence of electronic health information on end-user 
devices. The general policy we express in this certification criterion 
requires EHR technology designed to locally store electronic health 
information on end-user devices to encrypt such information after use 
of EHR technology on those devices stops. We clarify that in this 
context, locally stored electronic health information is intended to 
mean the storage actions that EHR technology is programmed to take 
(i.e., creation of temp files, cookies, or other types of cache 
approaches) and not an individual or isolated user action to save or 
export a file to their personal electronic storage media. Similar to 
the changes we made to the auditable events certification criterion, we 
have clarified that in this scenario, the EHR technology must be set by 
default to perform this capability and, unless this configuration 
cannot be disabled by any user, the ability to change the configuration 
must be restricted to a limited set of identified users. While it may 
not ``enforce'' encryption per se, this certification criterion does 
require that EHR technology designed in this way be set by default to 
encrypt when electronic health information is locally stored on end-
user devices.
    We agree with commenters and clarify that this certification 
criterion focuses on, and only applies with respect to, the storage 
capabilities that are designed for use with EHR technology developer 
provided or supported technologies for desktop, laptop, or mobile 
technologies (and similar variations of such technologies) (i.e., it is 
generally not intended to apply to personally owned end-user devices, 
unless an EHR technology developer supported technology is loaded/
installed on such a device). The certification criterion does not apply 
with respect to capabilities that may be present in the underlying 
technology on which EHR technology may run, but is unable to control 
through the EHR software, such as operating systems, swap files, and 
memory management technologies that are embedded and non-configurable 
by the EHR technology. Thus, these revisions are consistent with the 
sentiments issued by commenters that suggested this certification 
criterion be applied to the deliberate use of storage capabilities that 
are configurable or to the management of caching files that the EHR 
technology developer, by design, elects to use and manage on such end-
user devices. We recognize that a spectrum of different implementations 
exist and that they may range from a ``thin client,'' \27\ to a viewer 
that shows the screen of remote virtual server, to a web browser that 
accesses a remote web service, to more traditional client/server 
``thick client'' \28\ implementations, and to where EHR technology in 
its entirety could run entirely on single a device. On one end of the 
spectrum no electronic health information would persist when a user 
stops using EHR technology. Toward the other end of the spectrum 
electronic health information would always persist when a user stops 
using EHR technology. Ultimately, as expressed in the paragraph 
(d)(7)(i) of this certification criterion, if the EHR technology 
developer designs EHR technology that requires or utilizes locally 
stored electronic health information, it is the EHR technology 
developer's responsibility to ensure that such information is set to be 
encrypted by default in order to meet this certification criterion. We 
expect that this capability could be accomplished through a number of 
different technical mechanisms, including techniques to ``sandbox'' 
\29\ and limit the extent to which data can be accessed and used to 
only be within a secure session.
---------------------------------------------------------------------------

    \27\ In some cases referred to as lean or slim, a thin-client 
typically does not perform/provide any computational assignments. 
Rather, it serves as a terminal through which a user can access 
computational resources on a server.
    \28\ Compared to thin-clients, thick-clients typically perform/
provide for computational assignments to be completed on the thick-
client rather than the server, but may also utilize certain 
features/resources that a server includes.
    \29\ ``Sandbox'' or ``sandboxing'' is typically used to describe 
an information security approach that allows programs to run in a 
separate and secure environment. Programs run within a sandbox 
typically have limited access to certain system resources and may be 
restricted from performing certain actions.
---------------------------------------------------------------------------

    With respect to paragraph (d)(7)(ii) of this certification 
criterion, we have revised the language to acknowledge that despite an 
EHR technology developer's best effort to design EHR technology in such 
a way (as suggested by our proposal) that electronic health information 
never remains, we understand from commenters that such absolutes cannot 
always be guaranteed (especially when an EHR technology developer is 
unable to modify the functionality a particular web browser or 
operating system employs). With this in mind, we have revised this 
portion of the certification criterion to state that an EHR technology 
developer would not have to demonstrate that its EHR technology can 
encrypt electronic health information locally stored on end-users 
devices if the EHR technology is designed to prevent electronic health 
information from being locally stored on end-user devices after use of 
EHR technology on those devices stops. We interpret ``prevent'' to 
include, for example, situations where EHR technology is designed to 
and would normally disallow electronic health information to be locally 
stored on end-user devices after use of EHR technology on those devices 
stops, but is run in a browser that does not respect ``no-cache'' 
headers. In this circumstance, and if shown under normal circumstances 
(i.e., running in a browser that does respect ``no-cache'' headers), 
the EHR technology could meet paragraph (d)(7)(ii) of this 
certification criterion.
    Comment. A commenter stated that they considered information that 
has been sent to a print queue or downloaded by the user (such as 
downloading a PDF report) to no longer be managed by the EHR 
technology.
    Response. We generally agree with this statement.
    Comment. A commenter asked that we clarify whether data at rest on 
a server located at a secure data center must be encrypted and, if yes, 
to please reconsider this requirement because they believed it would 
slow down response times in large cloud-based EHR systems.
    Response. As indicated above, this certification criterion does not 
focus on server-side or data center hosted EHR technology. We 
recognized that these implementations could employ a variety of 
different administrative, physical, and technical safeguards, including 
hardware enabled security protections that would be significantly more 
secure than software oriented capabilities.
    Comment. One commenter recommended that disk level encryption, 
which is implemented outside of CEHRT, be deemed an acceptable means 
through which to fulfill this criterion. They contended that EHR 
technology developers should not be forced to create their own 
proprietary encryption implementations, when this capability is already 
available through other means.
    Response. We cannot deem this approach acceptable to fulfill this 
certification criterion because it would not be a capability that could 
be demonstrated by EHR technology. However, in situations where a user 
has implemented disk encryption hardware

[[Page 54239]]

and would be using EHR technology that is designed to save electronic 
health information to local storage on end-user devices, the user may, 
through a risk analysis, determine that disabling the EHR technology's 
encryption capability is prudent since its data will be protected 
through the disk encryption hardware.
    Comment. A commenter recommended that we discourage the use of or 
remove the allowance for 3DES because the algorithm is on track to be 
deprecated by NIST in the near future.
    Response. We agree with this commenter and encourage EHR technology 
developers to use the other encryption algorithms, such as AES, that 
are included in FIPS 140-2 Annex A.
    Comment. A commenter expressed concern that this certification 
criterion would cause financial hardship related to the additional 
involvement of copy machines, EKG machines, etc., and stated that 
health care practices need to be aware of the cost.
    Response. Given our responses above, we do not believe that this 
concern is valid.
    Comment. In the context of this certification criterion, a 
commenter encouraged ONC to evaluate the necessary steps to incorporate 
the ability to access a patient's health information during urgent or 
emergency situations.
    Response. We have considered this comment and do not believe that 
any change to the certification criterion is warranted given the 
clarifications we have made above.
    Comments. A commenter indicated that the proposed certification 
criterion could be interpreted to exceed the requirements set forth in 
the HIPAA Security Rule, which provides that encryption is addressable 
requirement (evaluated as part of a risk assessment), rather than a 
required control. They stated that one might infer that the 
implementing organization must use this capability if their EHR 
technology was required to be certified to it. The commenter suggested 
that we clarify any distinction between the HIPAA Security Rule and the 
proposed certification criterion. Last, they suggested that if the 
encryption of data on connecting devices is truly considered a best 
practice, that it seems that it is best first addressed by OCR as a new 
required control in the HIPAA Security Rule, which could then be 
incorporated into the MU requirements (compared to using the MU 
requirements to indicate best practice for a limited set of HIPAA 
regulated entities).
    Response. This certification criterion applies to EHR technology 
and does not supersede or affect the HIPAA Security Rule's requirements 
or associated flexibilities. As we have stated in this preamble and 
prior rules, we believe that by requiring these capabilities to be part 
of an EP, EH, or CAH's CEHRT that it will assist and enable them to 
more efficiently comply with security requirements such as the HIPAA 
Security Rule. We note that HHS \30\ has issued guidance around 
encryption as a possible risk management strategy to address storage of 
electronic protected health information.\31\ In addition, HHS has 
issued guidance on how to render unsecured protected health information 
unusable, unreadable, or indecipherable to unauthorized 
individuals.\32\
---------------------------------------------------------------------------

    \30\ Please note that CMS originally issued HIPAA Security Rule 
guidance.
    \31\ https://www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/remoteuse.pdf.
    \32\ https://www.hhs.gov/ocr/privacy/hipaa/administrative/breachnotificationrule/brguidance.html.
---------------------------------------------------------------------------

     Immunization Information; and Transmission to Immunization 
Registries

------------------------------------------------------------------------
 
---------------------------------------------------------------------------
MU Objective
Capability to submit electronic data to immunization registries or
 immunization information systems except where prohibited, and in
 accordance with applicable law and practice.
------------------------------------------------------------------------
2014 Edition EHR Certification Criteria
Sec.   170.314(f)(1) (Immunization information).
Sec.   170.314(f)(2) (Transmission to immunization registries).
------------------------------------------------------------------------

    We proposed two certification criteria for immunization registries 
that were essentially a split of the 2011 Edition EHR certification 
criterion for submission to immunization registries (Sec.  170.302(k)). 
We proposed one certification criterion that focused just on the 
capabilities to electronically record, change, and access immunization 
information (data capture) and another that focused on the capability 
to electronically create immunization information for electronic 
transmission in accordance with specified standards. We discussed these 
two proposed certification criteria together in the Proposed Rule for 
simplicity and to prevent confusion, but noted that we did not consider 
the certification criterion we proposed to focus on data capture to be 
a revised certification criterion. Rather, we stated that we believed 
that the certification criterion would constitute an unchanged 
certification criterion because all the capabilities included in the 
criterion were the same as the capabilities included in the 
corresponding 2011 Edition EHR certification criterion (Sec.  
170.302(k)). Additionally, for this certification criterion, we 
proposed to replace the terms ``retrieve'' and ``modify'' in the 
revised criterion with ``access'' and ``change,'' respectively.
    For the certification criterion focused on electronically creating 
immunization information for electronic transmission, we clarified that 
this criterion focuses on the capability of EHR technology to properly 
create immunization information for electronic transmission in 
accordance with the applicable standards and implementation 
specifications. We further emphasized that 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. We proposed the use of only the HL7 2.5.1 standard for 
formatting immunization information because immunization registries are 
rapidly moving to this standard. We also proposed to adopt the HL7 
2.5.1 Implementation Guide for Immunization Messaging Release 1.3 as 
the implementation specification which provides corrections and 
clarifications to Release 1.0 and contains new guidance on how to 
message vaccines for children (VFC) eligibility. Finally, we proposed 
to adopt the August 15, 2011 version of CVX code sets.
    Comments. Commenters supported our proposed ``two certification 
criteria approach.'' One commenter noted strong support for ONC's 
change in terminology from ``retrieve and modify'' to ``access and 
change'' and the clarification that this criterion does not include in 
scope the retrieval of immunization data from an external source to the 
EHR.
    Response. We appreciate the support for the proposed certification 
criteria and the change in terminology. We are adopting these 
certification criteria as proposed, but with the inclusion of an 
updated implementation guide as discussed below.
    Comments. Commenters expressed support for moving to only HL7 
2.5.1. Commenters stated that requiring all EHR technology developers 
to consistently adopt the same standards would promote the access and 
use of immunization data and further boost

[[Page 54240]]

interoperability and exchange. A couple of commenters recommended that 
HL7 2.3.1 and HL7 2.5.1 both be accepted for certification as part of 
the 2014 Edition EHR certification criteria. These commenters also 
recommended that HL7 2.5.1 could be required and HL7 2.3.1 could be 
optional as a means of allowing a reasonable transition period.
    Response. We appreciate the support for the moving solely to HL7 
2.5.1. We do not believe that permitting EHR technology to continue to 
be certified to HL7 2.3.1 as a means of meeting this certification 
criterion promotes improved exchanged and interoperability. Therefore, 
we are adopting only HL7 2.5.1 for the ``transmission to immunization 
registries'' certification criterion.
    Comments. Commenters generally agreed with our proposal to adopt 
the HL7 2.5.1 Implementation Guide for Immunization Messaging Release 
1.3 as the implementation specifications. One commenter contended that 
the implementation guide is vague on several important points regarding 
requirements for specific types of data and the circumstances in which 
specific data should be sent. The commenter recommended using the HL7 
2.3.1 standard for certification because the HL7 2.3.1 Implementation 
Guide for Immunization Messaging is more clear on these important 
points than the 2.5.1 guide.
    Response. We appreciate the support for the implementation guide. 
The CDC has worked to clarify ambiguities in Release 1.3 of the 
implementation guide and has published a new version of the 
implementation guide, Release 1.4, which reflects these clarifications. 
In particular, Release 1.4 clarifies the separate usage 
responsibilities for senders and receivers, provides conformance 
statements identifying core data elements that must be supported based 
on the National Vaccine Advisory Committee (NVAC) core data elements, 
adds support for messaging Vaccine Information Statement (VIS) data 
based on a 3D barcode, and provides HL7 version 2.7.1 usage guidance 
that improves clarity for conformance criteria and the requirements for 
HL7 message elements. Overall, these revisions do not establish 
additional substantive requirements in comparison to Release 1.3. 
Rather, the revisions improve the ability to test and certify EHR 
technology to the implementation guide and make it easier for EHR 
technology developers to implement the guide's requirements based on 
the corrections and clarifications. Accordingly, in lieu of adopting 
Release 1.3 of the implementation guide as we had proposed, we have 
adopted Release 1.4 for the ``transmission to immunization registries'' 
certification criterion. For the reasons stated above, we are not 
adopting HL7 2.3.1.
    Comments. One commenter recommended that EPs, EHs and CAHs comply 
with the public health agency's local HL7 specifications guide as these 
guides describe what data elements are required within the jurisdiction 
that may go beyond those described in the CDC HL7 implementation guide. 
Conversely, another commenter stated variances at the local public 
health agency level in the content and transmission specifications 
continue to add challenges and cost to the adoption of immunization 
reporting (e.g., additional requirements or proprietary 
specifications). The commenter stated these challenges are further 
exacerbated by the fact that there are no standard specifications for 
the transmission of immunization reports. The commenter urged ONC to 
work with the CDC to identify ways to improve the adoption of the CDC 
implementation guides (content and transmission specifications) by the 
state immunization registries.
    Response. Release 1.4 of the implementation guide reduces 
variability and standardizes the required data elements across public 
health jurisdictions. Release 1.4 also notes a standard format for 
states to indicate any variability. The certification criteria do not 
address transport standards, as this is left to the receiving public 
health authority. However, an expert panel convened by CDC and American 
Immunization Registry Association (AIRA) has recommended a SOAP-based 
standard for transport of immunization data.
    Comments. Commenters stated that at least several states have made 
recording a patient's consent decision relative to the disclosure of 
immunization data by the provider (or consent to its re-disclosure by 
the external agency collecting it) a de facto requirement for 
electronic submission of immunization data. Commenters noted that 
recording patient consent was not part of the testing and certification 
for the 2011 Edition EHR certification criterion, but asked whether 
recording a patient's consent will be part of certification to the 2014 
Edition EHR certification criteria. Some commenters more specifically 
asked whether patient consent would not to be recorded per the PD1-12 
Protection Indicator of the referenced implementation guide.
    Response. We believe that Release 1.4 of the implementation guide 
reduces the variability and standardized the required data elements 
across public health jurisdictions, including requirements for consent.
    Comments. Commenters expressed support of the continued use of the 
CVX code sets and the August 15, 2011 version. Commenters requested 
that we specify that the vaccine administered be coded by the CVX and 
MVX (where known) as the combination would allow a specific vaccine to 
be identified accurately. One commenter recommended that a detailed 
review be conducted between ONC, the AIRA, CDC, and selected public and 
commercial stakeholders, for the purpose of revising the current CVX 
immunization code set to account for a small but significant number of 
remaining common discrepancies between data necessary to comprise an 
accurate and minimally complete immunization record which remains 
unaccounted for in current certified EHR systems. A few commenters 
recommended the inclusion of the National Vaccine Advisory Committee 
(NVAC) approved Immunization Information System Core Data Elements as 
required elements. One commenter noted that these are currently under 
review and revision but expected to be in place for 2013. One commenter 
requested clarification on what data should be included in immunization 
history.
    Response. As we required for the 2011 Edition EHR certification 
criterion for immunization reporting, we continue to believe that the 
adoption of CVX is appropriate and that no other vocabulary standard 
need to be expressly adopted for the purposes of certification. We do, 
however, appreciate the points raised by commenters and will discuss 
them with our colleagues at CDC for consideration in proposals for the 
next edition of EHR certification criteria we propose.
    Comments. One commenter noted a challenge facing transitioning data 
entry immunization registry challenges relating to replacing the 
``Vaccines for Children'' inventory tracking and ordering functionality 
with EHR functionality.
    Response. It is not clear exactly what the commenter was 
specifically addressing. The Implementation Guide defines a 
standardized way to record and track VFC eligibility. However, it does 
not address issues of inventory tracking.
    Comments. A commenter expressed concern about specifying a 
particular CVX code set in regulation, particularly as the code set has 
been updated since the August 15, 2011 version. Commenters recommended 
the

[[Page 54241]]

following wording change: ``HL7 2.5.1 and Implementation Guide for 
Immunization Messaging Release 1.3, or the most recent version as 
published by CDC'' for adoption of the implementation guide in 
regulation.
    Response. We have established a process for adopting certain 
vocabulary standards, including CVX, which permits the use of newer 
versions of those standards than the one adopted in regulation. We 
refer readers to section IV.B for a discussion of ``minimum standards'' 
code sets and our new more flexible approach for their use in 
certification and upgrading certified Complete EHRs and certified EHR 
Modules. Readers should also review Sec.  170.555, which specifies the 
certification processes for ``minimum standards'' code sets. In 
response to the commenters' suggestion that we permit the use of the 
``most recent version'' of the implementation guide for certification, 
we refer the commenters to section III.A.5 found earlier in this 
preamble. This section explains why we cannot take such an approach. To 
note, as discussed above, in lieu of adopting Release 1.3 of the 
implementation guide as we had proposed, we have adopted Release 1.4.
    Comments. A commenter noted concerns about the meaning of the 
language regarding reporting immunizations after receipt of a CCDA. It 
should be the responsibility of the EHR transmitting the CCDA to report 
the original immunization information. Requiring EHRs to report 
immunizations not administered within the context of the EHR may lead 
to duplicate results and require additional reconciliation at state 
immunization registry level.
    Response. We cannot locate the exact language in the Proposed Rule 
that would have led this commenter to raise these concerns. The 
triggering event for reporting of an immunization is not part of the 
certification criteria. Certification focuses on the ability of EHR 
technology to properly create immunization information for electronic 
transmission according to the adopted standard and implementation 
specification.
    Comments. One commenter disagreed with the requirement to transmit 
data to an immunization registry. The commenter stated that a process 
where data is directly entered into a state's certified application 
that is provided by the state immunization registry should be 
acceptable. The commenter noted that this information is stored 
directly in the state's immunization database and then the commenter's 
EHR technology hosts the state's immunization application. The 
commenter argued that this obviates the need for an interface and does 
not put the data at risk. The commenter stated that because of the 
inflexibility of the certification requirements, it has had to create a 
costly and inefficient interface to send data from its EHR technology 
to the state's registry. Therefore, the commenter recommended that 
Sec.  170.314(f)(2) be made optional for those institutions that use a 
certified module provided by a state registry to directly enter 
immunization information as part of their EHR technology.
    Response. The purpose of this certification criterion is to support 
interoperability between EHR technology and public health. Thus, any 
EHR technology that meets the certification requirements can be 
utilized to submit data to an Immunization Registry. Again, to meet 
this certification criterion, EHR technology must be able to properly 
create immunization information for electronic transmission according 
to the adopted standard and implementation specification. How this 
standardized data created by CEHRT gets to public health is not within 
the scope of certification. Additionally, we are aware that some states 
are considering modular certification of the state immunization 
registry to accomplish this function.
    Comments. Commenters noted that the HITSC commented that it would 
be useful to have a standard for updating registries with groups or 
lists of patients instead of only individual patient transactions. The 
commenters stated that we should consult standards development 
organizations (i.e., HL7 for the v.2.5.1 message) to determine the most 
appropriate standard to achieve this goal.
    Response. It is our understanding that most state immunization 
registries can accept batch reporting via the HL7 2.5.1 message 
standard and we previously indicated this approach was acceptable in 
FAQ 9-10-002-1.
    Comments. Commenters expressed confusion over whether EHR 
technology must be certified to a transport standard to meet this 
certification criterion and whether EPs, EHs, and CAHs must use certain 
transport standards for submitting immunization information to 
immunization registries. Several commenters supported the requirement 
that eligible professionals utilize the transport method or methods 
supported by the public health agency to achieve meaningful use. 
Conversely, commenters requested that ONC require EHRs be certified in 
SOAP web services as well as Direct. These commenters also recommended 
that SOAP web services requirements should include the Centers for 
Disease Control and Prevention (CDC)'s Transport Layer Expert Panel 
WSDL specifications.
    Response. We want to make clear that we do not require EHR 
technology to be certified to any transport standard, including Direct, 
to meet this certification criterion. There is no consensus transport 
standard that states and public health agencies use for the reporting 
of immunization information. Therefore, we believe that it is 
appropriate for EHR technology developers to have the flexibility to 
include in their EHR technology and implement the transport standards 
that permit EPs, EHs, and CAHs to report in their states and to local 
public health agencies.
    Comments. Several commenters suggested using the preferred term 
``Immunization Information Systems'' for the ``transmission'' 
certification criterion rather than ``Immunization Registries.''
    Response. We appreciate this suggestion, but are retaining the same 
naming convention for the certification criterion to prevent confusion 
with the associated MU objective and measure. The associated MU 
objective specifically references immunization registries.
    Comments. Commenters stated that EPs, EHs, and CAHs that are 
currently successfully submitting immunization data in an ongoing 
manner using the HL7 2.3.1 and its implementation guide should continue 
to be able to do so for MU. One commenter suggested we explore offering 
additional incentives to early-adopting EPs, EHs, and CAHs that upgrade 
to the HL7 2.5.1 standard. A few commenters stated that, although bi-
directional communication is not proposed for MU Stage 2, we should 
indicate that it will likely be required for MU Stage 3.
    Response. We appreciate the submission of these comments, but they 
are outside the scope of this rulemaking. We direct commenters to the 
Stage 2 final rule found elsewhere in this issue of the Federal 
Register for a discussion of the MU objective and measure and a 
response to these comments.
    Comments. A commenter stated that patients should be able to have 
access to immunization records and receive an accounting of all 
disclosures for public health surveillance. Another commenter requested 
that interoperable immunization registries which require all registries 
to accept the proposed standards without requiring additional data.

[[Page 54242]]

    Response. We thank commenters for these comments, but they are 
outside the scope of this rulemaking.
    Comments. One commenter requested that Federal sources build a 
common portal for connectivity to immunization registries and other 
external data sources (e.g., HIEs, public health agencies, cancer 
registries, and non-cancer registries) so that the financial burden on 
EHR technology developers and end users is reduced.
    Response. We appreciate this feedback, but it is outside the scope 
of certification and this rulemaking. We note that while no proposal 
for a single interface to all immunization registry exists, an expert 
panel convened by CDC and AIRA recommended standards for transport that 
include a standard WSDL which should help reduce the financial burden 
on EHRs to interface with immunization registries.
     Transmission to Public Health Agencies--Syndromic 
Surveillance

------------------------------------------------------------------------
 
---------------------------------------------------------------------------
MU Objective
Capability to submit electronic syndromic surveillance data to public
 health agencies except where prohibited, and in accordance with
 applicable law and practice.
------------------------------------------------------------------------
2014 Edition EHR Certification Criteria
Sec.   170.314(f)(3) (Transmission to public health agencies--syndromic
 surveillance).
------------------------------------------------------------------------

    We proposed two certification criteria for reportable laboratory 
tests and values/results that were essentially a split of the 2011 
Edition EHR certification criterion for reportable lab results (Sec.  
170.302(l)). We proposed one certification criterion that focused just 
on the capabilities to electronically record, change, and access 
syndrome-based public health surveillance information (data capture) 
and another that focused on the capability to electronically create 
syndrome-based public health surveillance information for transmission 
in accordance with specified standards. We discussed these two proposed 
certification criteria together in the Proposed Rule for simplicity and 
to prevent confusion, but noted that we did not consider the 
certification criterion we proposed to focus on data capture to be a 
revised certification criterion. Rather, we stated that we believed 
that the certification criterion would constitute an unchanged 
certification criterion because all the capabilities included in the 
criterion were the same as the capabilities included in the 
corresponding 2011 Edition EHR certification criterion (Sec.  
170.302(1)).
    For the certification criterion focused on creating syndrome-based 
public health surveillance information for transmission, we proposed 
the use of only the HL7 2.5.1 standard for formatting syndrome-based 
public health surveillance. We stated that we proposed only the HL7 
2.5.1 standard because public health agencies are rapidly moving to 
this standard and all stakeholders would benefit from focusing on a 
single standard for public health surveillance. We also proposed to 
constrain the standard for hospitals with the PHIN Messaging Guide for 
Syndromic Surveillance: Emergency Department and Urgent Care Data HL7 
Version 2.5.1 (Release 1.0). We further proposed that certification to 
this guide be optional for the ambulatory setting because certification 
of ambulatory EHR technology to this guide could be useful for EHR 
developers that provide EHR technology to EPs that practice in urgent 
care settings.
    Comments. Commenters supported our proposed ``two certification 
criteria approach.'' Commenter also stated that proposing the 
certification criteria in the manner that we had would permit HIEs to 
be certified to the certification criterion that includes the 
capability to create syndrome-based public health surveillance for 
transmission in accordance with specified standards and then serve as 
intermediaries for the transport of syndromic information to public 
health agencies. Another commenter noted that there should be no 
certification requirement required of the HIE to support this MU 
measure.
    Response. We appreciate the support expressed by commenters for our 
approach. We are adopting as part of the 2014 Edition EHR certification 
criteria the certification criterion focused on the capability to 
create syndrome-based public health surveillance in accordance with the 
standards we have specified (Sec.  170.314(f)(3)). We are not, however, 
adopting the certification criterion we proposed that focused on data 
capture. We have chosen to drop this proposed certification criterion 
because we do not believe that it is essential to focus on from a 
testing and certification perspective. It is our understanding that 
EPs, EHs, and CAHs will not necessarily be recording, accessing, and 
capturing separate kinds of ``syndromic surveillance'' information to 
facilitate the transmission of syndrome-based public health 
surveillance information to public health agencies. Rather, they will 
simply be ``passing on'' or reporting the information that already 
exists in their CEHRT to public health agencies. Thus, upon further 
reflection, this ``data capture'' certification criterion is 
unnecessary for certification.
    We agree with commenters regarding HIEs and noted in the Proposed 
Rule that our approach to the public health certification criteria 
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. In regard to 
the commenters assertion that HIE should not be required to be 
certified, we note that there is no such requirement. However, if an 
HIE performs a capability for which certification is required and an 
EP, EH, or CAH uses that capability for MU, then that capability must 
be certified.
    Comments. Many commenters supported the use of the HL7 2.5.1 
standard and moving to a single standard. Some commenters asserted that 
imposing new standards, like a move from HL7 2.3.1 or HL7 2.5.1 to a 
requirement for HL7 2.5.1 only, on all systems will penalize early-
adopting providers. One commenter suggested that newer data formats 
supported through the consolidated CDA be acceptable alternatives for 
transmission to public health agencies for medical research and public 
health.
    Response. We appreciate the support for the HL 2.5.1 standard we 
proposed and have now adopted this standard as the sole standard for 
this certification criterion. We are adopting only the 2.5.1 standard 
because, as noted above and in the Proposed Rule, public health 
agencies are rapidly moving to this standard and all stakeholders would 
benefit from focusing on a single standard for public health 
surveillance. In regard to the concern expressed by commenters that our 
approach would punish early adopters using HL7 2.3.1, we direct 
commenters to the Stage 2 final rule found elsewhere in this issue of 
the Federal Register for a response to this comment. Last, we do not 
believe that the Consolidated CDA is appropriate for this certification 
criterion at the present time.
    Comments. A commenter believed that it would be sufficient to 
simply adopt the implementation guide itself for this certification 
criterion because it incorporates the HL7 2.5.1 standard.
    Response. We believe it is appropriate to specifically adopt this 
standard and not just the implementation guide that references this 
standard to provide clarity around the certification requirements for 
this certification criterion. In particular, the implementation guide 
is optional for the ambulatory setting. Therefore, clearly specifying 
the standard will ensure that

[[Page 54243]]

EHR technology designed for the ambulatory setting will be certified to 
the HL7 2.5.1 standard.
    Comments. Commenters supported the adoption of the PHIN Messaging 
Guide for Syndromic Surveillance: Emergency Department and Urgent Care 
Data HL7 Version 2.5.1 (Release 1.0). Commenters also supported having 
certification to the implementation guide optional for the ambulatory 
setting, while one commenter requested that it be mandatory and another 
commenter stating that it was unnecessary to have for the ambulatory 
setting.
    Response. We appreciate the support expressed for the 
implementation guide. The CDC has recently published Release 1.1 of the 
implementation guide. Release 1.1 reflects the work of the CDC to 
correct errors and clarify ambiguities that were present in Release 1.0 
as well as provide information that was missing in Release 1.0. The CDC 
also recently published an addendum to the implementation guide, titled 
``Conformance Clarification for EHR Certification of Electronic 
Syndromic Surveillance.'' The addendum consolidates Release 1.1 
information and clarifies existing conformance requirements of the 
implementation guide. For example, it specifies conformance statements 
and conditional predicates that clarify message requirements. It also 
specifies value set requirements and provides general clarifications 
and PHIN MG corrections. Overall, Release 1.1 and the addendum do not 
create additional substantive requirements in comparison to Release 
1.0. Therefore, we believe the adoption of Release 1.1 and the addendum 
is appropriate as they will improve the ability to test and certify EHR 
technology to the implementation guide, as well as make it easier for 
EHR technology developers to implement the guide's requirements.
    EHR technology designed for the inpatient setting seeking 
certification to this certification criterion must be certified to the 
implementation guide, while EHR technology designed for the ambulatory 
setting will have the option of being certified to the implementation 
guide. We believe that the guide can provide necessary clarity for 
ambulatory EHR developers that provide EHR technology to EPs that 
practice in urgent care settings.
    Comments. Several commenters recommended replacing ``Inpatient'' 
with ``Hospital or urgent care.'' The commenters asserted that such a 
change more appropriately reflects the clinical settings that transmit 
syndromic surveillance data to health departments.
    Response. While we appreciate the commenters' recommendation, the 
designation ``inpatient'' is a general designation that we use to 
distinguish certification criteria and capabilities that apply to a 
particular setting for certification. We currently designate only two 
settings for certification, the inpatient setting and the ambulatory 
setting without variation. EHs use ``inpatient-certified'' EHR 
technology for their inpatient department and emergency departments. 
For urgent care settings that are not the emergency department, the 
providers would be non-hospital-based EPs and would require 
``ambulatory-certified'' EHR technology. Therefore, we are retaining 
the ``inpatient'' designation.
    Comment. Commenters recommended adding in regulation after the 
implementation guide the following statement ``or the most recent 
version as published by CDC.''
    Response. We refer the commenters to section III.A.5 found earlier 
in this preamble. This section explains why we cannot take such an 
approach.
    Comments. Commenters expressed confusion over whether EHR 
technology must be certified to a transport standard to meet this 
certification criterion and whether EPs, EHs, and CAHS must use certain 
transport standards for submitting syndrome-based public health 
surveillance information to public health agencies. Some commenters 
requested that we require EHR technology to be certified in SOAP web 
services as well as Direct. One commenter encouraged us to expand the 
required transport standards to include commonly used transports, such 
as MLLP (HL7) and IHE XDS, or define specific data types and 
transactions for each transport type.
    Response. We want to make clear that we do not require EHR 
technology to be certified to any transport standard, including Direct, 
to meet this certification criterion. There is no consensus transport 
standard that states and public health agencies use for the reporting 
of syndrome-based public health surveillance information. Therefore, we 
believe that it is appropriate for EHR technology developers to have 
the flexibility to include in their EHR technology and implement the 
transport standards that permit EPs, EHs, and CAHs to report in their 
states and to local public health agencies.
    Comment. One commenter suggested that this certification criterion 
include the capability to capture adverse drug events for reporting to 
public health agencies. Another commenter recommended that we should 
require the capture of occupational exposure and industry worker health 
information.
    Response. The certification criterion does not preclude other types 
of reportable events from being captured and reported by EHR 
technology. We do not believe, however, that it is appropriate to 
modify the certification criterion to explicitly reference adverse drug 
events or any other specific syndrome-based surveillance information 
for the purposes of EHR technology certification.
    Comments. A commenter recommended that the ONC tighten the message 
structures within the HL7 message, such that one single message works 
with all registries of the same type. Specifically, there should not be 
50 different flavors of the HL7 2.51 format for 50 different states for 
each transmission type. In addition, to make transmission simple, the 
registries captioned above should be required to accept messages via 
the Direct Project messaging system only as this will reduce the burden 
on providers for making dozens of point-to-point connections with 
registries.
    Response. We acknowledge this commenter's recommendation, but do 
not believe that the recommended outcome can be effectively reached 
through certification. While certification can ensure that EHR 
technology can create a single, standardized message it cannot affect 
the additional data states may also require be submitted or the IT 
system differences across states.
    Comments. One commenter stated that in consideration of the 
challenges for many public health agencies to receive this data 
electronically, the objective and associated criterion should be 
removed.
    Response. We appreciate the submission of this comment, but it is 
outside the scope of this rulemaking. We direct the commenter to the 
Stage 2 final rule found elsewhere in this issue of the Federal 
Register for a discussion of the MU objective and measure and a 
response to this comment.
     Automated Measure Calculation

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

    We proposed to adopt a revised ``automated measure calculation'' 
certification criterion for the 2014 Edition EHR certification 
criteria. We revised the certification criterion to clearly identify 
that the recording, calculating, and reporting capabilities

[[Page 54244]]

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. We clarified that the 
capabilities are the capabilities included in the certification 
criteria to which a Complete EHR or EHR Module is presented for 
certification.
    We emphasized 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 stated testing to ensure the accuracy of these 
calculations would significantly reduce the reporting burden for MU 
attestation. Additionally, we stated that testing and certification to 
this 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 and adopted in a final rule.
    Comments. Commenters supported this certification criterion and 
emphasized the value of automated measure calculation for EPs, EHs, and 
CAHs. Commenters noted that it is important to ensure that EHR 
technology can accurately calculate these measures and stated that 
accurate measure calculations are critical to reducing the burden of 
reporting and for promoting adoption. One commenter noted that although 
``automated measure calculation'' suggests a simple process is required 
for physicians to calculate their data for meeting MU measures, they 
recommended that ONC explicitly require that EHR technology enable the 
automatic creation of reports.
    Response. We thank commenters for supporting this certification 
criterion and agree that the improved accuracy of measure calculations 
will reduce reporting burdens for EPs, EHs, and CAHs. We have adopted 
this certification criterion as proposed. This certification criterion 
requires EHR technology to demonstrate the capability to automatically 
create reports based on the numerator and denominator for MU objectives 
with percentage-based measures.
    Comments. A commenter stated that this certification criterion does 
not fall into patient-centric care and while a necessary component of 
reporting, the functionality it includes could be performed by another 
technical component outside the EHR.
    Response. As stated in the S&CC July 2010 final rule (75 FR 44642), 
we adopted this certification criterion to reduce the reporting burden 
associated with participating in MU. This certification criterion is 
required in order for EHR technology presented for certification to 
meet the Complete EHR definition. We permit, but do not require, EHR 
technology presented as an EHR Module for certification to also be 
certified to this certification criterion. In instances where an EHR 
Module is not presented for certification to this certification 
criterion, it would need to be certified to the ``automated numerator 
calculation'' certification criterion adopted in this final rule. We 
also note that CMS permits reporting outside certified EHR technology 
per FAQ 3063, which can be found at https://questions.cms.gov/faq.php?id=5005&faqId=3063.
    Comments. A commenter recommended that EHR technology developers be 
required to provide not only the numerator, denominator, and percentage 
for the selected reporting period, but also offer the capability to 
display a detail level that includes patient identifiers and data 
elements and if the patient record assessed met or did not meet the 
objective.
    Response. While we realize such detailed information may have value 
for an EP, EH, and CAH, but we do not believe that we need to require 
such level of detail be displayed to the user for purposes of 
certification and to support the calculation and reporting of 
objectives with percentage-based measures. We note, however, that this 
level of detail may be useful to demonstrate an EHR technology's 
compliance with this certification criterion during testing.
    Comments. Commenters requested clarification on the testing 
procedures that will be used for this certification criterion. 
Commenters also provided many recommendations for testing EHR 
technology to this certification criterion. One commenter suggested not 
moving forward with this criterion unless a test data set is provided 
from ONC that validates the ability of EHR technology to generate these 
accurate calculations and reports. Other commenters requested 
clarification on whether test data would be provided and EHR technology 
would be expected to match some predetermined calculations by the 
tester. These commenters stated if EHR technology developers are 
expected to demonstrate each measure calculation on the report, then 
they are concerned about the time that could be required to validate 
such accuracy and thus added to the time it takes to certify EHR 
technology. Another commenter suggested providing specifications on how 
the numerators and denominators for these measures should be 
calculated. The commenter also requested that in giving EHR technology 
developers a test data set, they are also given multiple ways to 
accommodate the different approaches that exist to importing practical 
data sets.
    Some commenters expressed concerns that testing tools similar to 
Cypress are not accurate. For an accuracy test, commenters recommended 
that test scripts be developed that can be used by EHR developers. The 
commenters further recommended that the test scripts be based on real-
world clinical workflows where a patient should be included or excluded 
from the numerators and denominators of an objective in an expected 
manner. The commenters noted that the test would determine the accuracy 
of the EHR technology based on whether the patient is included or 
excluded from the numerators and denominators according to 
expectations. Commenters also recommended that testing include time-
based elements to simulate an EHR reporting period.
    Response. We appreciate the many comments on testing to this 
certification criterion. Consistent with the process we outlined in the 
Permanent Certification Program final rule (76 FR 1280), we anticipate 
approving a test procedure for this certification criterion that, at 
minimum, is clearly traceable to the capabilities included in the 
certification criterion, sufficiently comprehensive (i.e., assesses all 
required capabilities) for NVLAP-accredited testing laboratories to use 
in testing a Complete EHR's or EHR Module's compliance with the 
certification criterion, and was developed using an appropriate public 
comment process. With CMS, we intend to be more proactive about 
explaining numerator and denominator requirements so that 
misinterpretations are reduced to a minimum. To that end, we will work 
with CMS to provide education materials and any additional guidance 
necessary to help EHR technology developers better understand the 
numerator and denominator requirements for MU objectives and measures. 
Finally, we wish to make clear that for MU objectives which CMS has 
provided flexibility in its final rule for EPs, EHs, and CAHs to pursue 
alternative approaches to measuring a numerator and denominator, the 
EHR technology must be able to support all CMS-

[[Page 54245]]

acceptable approaches in order to meet this certification criterion. 
For example, there are two options for counting emergency department 
admissions. If an EHR technology developer only included one option in 
its EHR technology for certification, the EHR technology developer 
would take away the flexibility granted to the EP, EH or CAH by CMS. We 
believe that this flexibility should be available to all EPs, EHs, and 
CAHs regardless of what Certified EHR Technology they utilize.
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).
------------------------------------------------------------------------

    We proposed to adopt a revised certification criterion for the 
ambulatory setting that requires the use of RxNorm as the vocabulary 
standard. We proposed to continue to permit the use of NCPDP SCRIPT 
version 10.6 to meet this certification criterion, but also to no 
longer include the use of NCPDP SCRIPT version 8.1 as a way to meet the 
2014 Edition EHR certification criterion. We stated that we made this 
proposal because we understood CMS was planning to propose the 
retirement of NCPDP SCRIPT version 8.1 (adopted as a Medicare Part D e-
prescribing standard) in a proposed rule that was scheduled to be 
issued soon after the Proposed Rule was published. We noted that if we 
received 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 
stated that we were proposing to adopt this certification criterion for 
both the ambulatory and inpatient settings because it supports our 
desired policy and interoperability outcome for content exchange 
standards to be used when information is exchanged between different 
legal entities.
    In the interest of providing readers with a clear, cohesive, and 
consistent recitation of comments and our response and to also avoid 
redundancy, we direct readers to our discussion of the adopted 
``electronic prescribing'' certification criterion (Sec.  
170.314(b)(3)) under section III.A.8.c.
     Clinical Summary

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

    We proposed to revise the ``clinical summaries'' certification 
criterion for the 2014 Edition EHR certification criteria to reflect 
the proposed new and revised standards for problem lists and other 
vocabulary standards. We noted in the Proposed Rule that we made 
several refinements to the HITSC recommended certification criterion to 
ensure that EHR technology meets the appropriate standards and is 
capable of making available the information CMS is proposing be 
provided to a patient after an office visit.
    We proposed that when information is provided electronically, the 
information should be provided according to the Consolidated CDA 
standard. We stated in the Proposed Rule that adopting the Consolidated 
CDA for this certification criterion is advantageous since its template 
structure can accommodate the formatting of a summary of care record 
that includes all of the data elements that CMS proposed be provided to 
a patient after an office visit. We requested public comment on whether 
we should adopt separate certification criteria to explicitly require 
the capture of unique data elements included in clinical summaries, 
such as care plans and future scheduled tests. For certain other data 
elements in Sec.  170.314(e)(2), we proposed to require that the 
capability to provide the information be demonstrated in accordance 
with the specified vocabulary standard. We noted that these vocabulary 
standards had been previously adopted or were proposed for adoption in 
the Proposed Rule.
    Comments. Many commenters expressed agreement with this 
certification criterion and the use of the Consolidated CDA. Commenters 
noted that the use of the Consolidated CDA would be beneficial for 
interoperability purposes.
    Response. We appreciate the support for this certification 
criterion and the use of the Consolidated CDA for the clinical summary. 
We are adopting this certification criterion as proposed with Release 
2.0 (July 2012) of the Consolidated CDA standard as discussed earlier 
in the preamble under the ``view, download, and transmit to a 3rd 
party'' certification criterion, which fully supports the clinical 
summary as defined by CMS in the Stage 2 final rule for the MU 
objective and measure associated with this certification criterion. To 
note, we have revised the certification criteria heading to the 
singular form (``clinical summary'').
    Comments. We received numerous comments regarding what should and 
should not be included in a clinical summary, including requests for 
clarification of data in the clinical summary and care plan. We also 
received requests for alignment of the data in a clinical summary used 
for this certification criterion and with the data included in the 
clinical summary used for other certification criteria. We also 
received requests for alignment with the use of the clinical summary by 
CMS for MU.
    Some commenters stated that the inclusion of names and contact 
information of any additional care team members provides no clinical 
benefit and will likely distract the patient and degrade the 
effectiveness of the clinical summary. A few commenters stated that we 
postpone the adoption of standards and certification criteria for care 
plans and future scheduled tests as part of the clinical summaries. 
Other commenters stated that EHR technology should offer EPs the 
capability to customize the clinical summary, where omitting some 
information is in the best interest of the patient.
    Response. As noted in the Proposed Rule, this certification 
criterion specifies the capabilities that EHR technology would need to 
include in order for an EP to provide the information identified by CMS 
to a patient after an office visit. A clinical summary and the data it 
includes such as a care plan are defined or described by CMS. We direct 
commenters to the Stage 2 final rule found elsewhere in this issue of 
the Federal Register for a complete discussion of the ``clinical 
summaries'' MU objective and measure, including the clinical summary 
data that are required to be provided after an office visit. We have 
adopted the Consolidated CDA standard, which supports all of the data 
that CMS has included for the MU objective and measure to which this 
certification criterion correlates.
    Further to make this certification criterion easier to read and to 
clearly express the capabilities that EHR technology must include in 
order to support MU, we have broken the certification criterion into 
three separate specific capabilities. The first echoes the requirement 
that EHR technology must be able to create a clinical summary in both 
human readable format and according to the Consolidated CDA. The second 
would require EHR technology

[[Page 54246]]

to enable a user to customize (e.g., be able to edit) the data they 
include in the clinical summary. This capability supports CMS's policy 
for this MU objective and measure that permits EPs excluding certain 
data from a clinical summary and clarifies as well as makes explicit 
the customization capability other commenters mentioned should be 
present. And, overall we believe this capability will assist EPs in 
determining how to best structure the clinical summary they want to 
provide their patients based on the data their CEHRT is able to 
produce. The third specific capability identifies the minimum data EHR 
technology must permit a user to select for inclusion in a clinical 
summary.
    Comments. A commenter stated that future appointments could be a 
part of scheduling system and not readily available to the EHR to 
include in the summary. The commenter noted that this could perhaps 
require that another application be included in the ``process for 
certification.''
    Response. We interpret EHR technology broadly for the purposes of 
certification in that any technology that meets a certification 
criterion is defined as an EHR Module.
    To meet this certification criterion, EHR technology must 
demonstrate all the capabilities included in the certification 
criterion. These capabilities support the associated MU objective and 
measure, which includes providing any future appointments in a clinical 
summary.
    Comments. Commenters stated that it was unnecessary to adopt 
separate certification criteria to explicitly require the capture of 
unique data elements included in clinical summaries such as care plans 
and future scheduled tests, while a few commenters suggested we pursue 
such an approach.
    Response. We agree with those commenters that stated it was 
unnecessary to adopt separate certification criteria. We made this 
similar response in the transitions of care certification criterion 
where we also posed this question.
    Comments. Commenters stated that they support the increased focus 
on supporting patients' access to their information through various 
means, but were concerned that the proposed certification criterion for 
clinical summaries included requirements to share information with 
unknown third parties. A commenter suggested that patients as well as 
their designated agent(s) be registered on the EP's CEHRT to enable 
transmission of their clinical data to them.
    Response. We are unclear as to what language in the Proposed Rule 
prompted commenters to raise this concern. This certification criterion 
does not require the sharing of patient health information with third 
parties. We encourage commenters to review our responses to comments on 
the view, download, and transmit to a 3rd party certification 
criterion.
    Comments. A commenter noted that patients should be able to access, 
download, and use clinical summaries which are a matter of patient 
safety so errors and omissions can be detected.
    Response. This certification criterion requires EHR technology to 
be capable of enabling a user to electronically create a clinical 
summary in human readable format and formatted according to the 
Consolidated CDA.
    Comment. A commenter stated that EHR technology should support 
integration with HIEs to enable the export of clinical summaries, 
making the information available to any authorized provider involved in 
the patient's care.
    Response. This certification criterion focuses on capabilities that 
EHR technology would have to demonstrate for certification that would 
support an EP's ability to provide a clinical summary to a patient, 
including electronically. It is not focused on the exchange of a 
patient's health information. Therefore, we decline to modify this 
certification criterion in response to this recommendation. We note, 
however, that the ``transitions of care-create and transmit transition 
of care/referral summaries'' certification criterion (Sec.  
170.314(b)(2)) requires EHR technology to be capable of formatting a 
patient's transition of care/referral summary in accordance with the 
Consolidated CDA and capable of using transport standards.
c. Inpatient Setting
    We are adopting the following revised certification criterion for 
the inpatient setting.
     Transmission of Reportable Laboratory Tests and Values/
Results

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Capability to submit electronic reportable laboratory results to public
 health agencies, except where prohibited, and in accordance with
 applicable law and practice.
------------------------------------------------------------------------
2014 Edition EHR Certification Criteria
Sec.   170.314(f)(4) (Inpatient setting only--transmission of reportable
 laboratory tests and values/results).
------------------------------------------------------------------------

    We proposed two certification criteria for reportable laboratory 
tests and values/results that were essentially a split of the 2011 
Edition EHR certification criterion for reportable lab results (Sec.  
170.306(g)). We proposed one certification criterion that focused just 
on the capabilities to electronically record, change, and access 
laboratory rests and values/results (data capture) and another that 
focused on the capability to electronically create reportable 
laboratory tests and values/results for electronic transmission in 
accordance with specified standards. We discussed these two proposed 
certification criteria together in the Proposed Rule for simplicity and 
to prevent confusion, but noted that we do not consider the 
certification criterion we proposed to focus on data capture to be a 
revised certification criterion. Rather, we stated that we believed 
that the certification criterion would constitute an unchanged 
certification criterion because all the capabilities included in the 
criterion were the same as the capabilities included in the 
corresponding 2011 Edition EHR certification criterion (Sec.  
170.306(g)).
    For the certification criterion focused on creating reportable 
laboratory rests and values/results for transmission, we proposed the 
use of only the HL7 2.5.1 standard and LOINC[supreg] version 2.38 as 
the vocabulary standard. Following consultation with the Centers for 
Disease Control and Prevention, we also proposed to adopt the HL7 
Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to 
Public Health, Release 1 (US Realm) with Errata and Clarifications and 
SNOMED CT[supreg] International Release January 2012 version--which, we 
noted, 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.
    Comments. Commenters supported our proposed ``two certification 
criteria approach.'' Commenter also stated that proposing the 
certification criteria in the manner that we had would permit HIEs to 
be certified to the certification criterion that includes the 
capability to create reportable laboratory tests and values/results for 
transmission in accordance with specified standards and then serve as 
intermediaries for the transport of laboratory tests and values/results 
to public health agencies.
    Response. We appreciate the support expressed by commenters for our 
approach. We are adopting as part of the 2014 Edition EHR certification 
criteria the certification criterion focused on the capability to 
electronically create reportable laboratory rests and values/

[[Page 54247]]

results for electronic transmission in accordance with the standards we 
have specified (Sec.  170.314(f)(4)). We are not, however, adopting the 
certification criterion we proposed that focused on data capture. For 
similar reasons as expressed in the syndromic surveillance 
certification criterion, we have dropped this requirement because we 
believe it is not necessary to focus on for the purposes of EHR 
technology certification.
    We agree with commenters regarding HIEs and noted in the Proposed 
Rule that our approach to the public health certification criteria 
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.
    Comments. Commenters supported maintaining the use of the HL7 2.5.1 
standard and adopting the HL7 Version 2.5.1 Implementation Guide: 
Electronic Laboratory Reporting to Public Health, Release 1 (US Realm) 
with errata, as well as the latest versions of SNOMED CT[supreg] and 
LOINC[supreg]. Commenters suggested that we simply state in regulation 
that EHR technology can be certified to the most recent versions of the 
vocabulary standards (SNOMED CT[supreg] and LOINC[supreg]) and the 
implementation guide for certification.
    Response. We appreciate the commenters' support for the standards 
and implementation guide we proposed. We have adopted the proposed 
certification criterion, including the proposed standards and 
implementation guide with errata and clarifications and a recently 
published supplement to the implementation guide, titled ````ELR 2.5.1 
Clarification Document for EHR Technology Certification.'' The 
supplement was not available when the Proposed Rule was published. It 
does not specify additional substantive requirements. Rather, it 
clarifies conformance requirements and other aspects of Release 1 with 
errata and clarifications that will improve testing and certification 
to the implementation guide. Accordingly, we are adopting the 
supplement and the proposed Release 1 with errata and clarifications.
    We have established a process for adopting certain vocabulary 
standards, including SNOMED CT[supreg] and LOINC[supreg], which permits 
the use of newer versions of those standards than the one adopted in 
regulation. We refer readers to section IV.B for a discussion of 
``minimum standards'' code sets and our new more flexible approach for 
their use in certification and upgrading certified Complete EHRs and 
certified EHR Modules. Readers should also review Sec.  170.555, which 
specifies the certification processes for ``minimum standards'' code 
sets. In response to the commenters' suggestion that we permit the use 
of the ``most recent version'' of the implementation guide for 
certification, we refer the commenters to section III.A.5 found earlier 
in this preamble. This section explains why we cannot take such an 
approach.
    Comments. A commenter expressed concern about the ongoing 
volatility of the LOINC[supreg] and SNOMED CT[supreg] code sets and the 
burden that will be placed on laboratory staff. The commenter further 
stated that the failure to adopt national standards for that coding may 
result in less than optimal interstate sharing of laboratory results. 
Another commenter noted that the mapping of local codes to our standard 
codes is needed but little guidance is provided.
    Response. We are not familiar with the ``volatility'' that the 
commenter references and believe that LOINC[supreg] and SNOMED 
CT[supreg] constitute consensus-based national standards. The CDC has 
published the Reportable Condition Mapping Table (RCMT) that provides a 
subset of LOINC[supreg] and SNOMED CT[supreg] codes associated with 
reportable conditions. RCMT can be obtained from CDC vocabulary server 
PHIN VADS (https://phinvads.cdc.gov). The CDC vocabulary team provides 
guidance to implementers regarding the implementation of RCMT and 
mapping of LOINC[supreg] and SNOMED CT[supreg] codes to local lab 
tests. CDC vocabulary team can be reached directly via email at 
phinvs@cdc.gov or through the CDC Meaningful Use technical assistance 
team (meaningfuluse@cdc.gov). In addition, the LOINC[supreg] SDO has 
created a tool known as ``RELMA,'' which helps to map the local tests 
to standard LOINC[supreg] laboratory tests. LOINC[supreg] SDO provides 
RELMA training twice a year and, through a partnership with 
LOINC[supreg] SDO, the CDC provides RELMA training to the public health 
community at least twice a year with a special focus on microbiology 
lab tests.
    Comments. Commenters pointed to what they believed to be an 
inconsistency between the Proposed Rule and the Stage 2 proposed rule. 
Commenters stated that the Stage 2 proposed rule stated that ``Public 
Health Agencies may specify the means of transport as long as it does 
not go above and beyond what is required in ONC's certification 
criteria.'' These commenters further stated that we only required the 
Direct Protocol for transport.
    One commenter strongly recommended the inclusion of PHIN-MS as a 
required transport mechanism for hospital EHR systems and further noted 
that leaving ``other transport mechanisms'' undefined or defined by 
state will likely result in EHR vendor implementation variance. Another 
commenter suggested the use of the NwHIN query-and-response protocol to 
share reportable laboratory tests and values/results. Conversely, other 
commenters strongly supported the requirement that transport method or 
methods supported by the public health agency should be used for MU.
    Response. We want to make clear that we do not require EHR 
technology to be certified to any transport standard, including Direct, 
to meet this certification criterion. There is no consensus transport 
standard that states and public health agencies use for the reporting 
of laboratory test and values/results. Therefore, we believe that it is 
appropriate for EHR technology developers to have the flexibility to 
include in their EHR technology and implement the transport standards 
that permit EPs, EHs, and CAHs to report in their states and to local 
public health agencies.
    Comments. Some commenters stated that the MU objective related to 
these certification criteria describes a function of a laboratory 
information system rather than EHRs. A commenter stated that if 
standards we propose for this certification criterion are mandated, 
then state-level programs must also be amended to support the 
standards. Other commenters stated that early adopters that support 
only HL7 2.3.1, common among public health systems, should not be 
penalized in MU Stage 2. One commenter requested clarification that 
ongoing submission means that all relevant data is transmitted in a 
timely fashion as required by the agency. Another commenter suggested 
that we clarify that ``reportable laboratory tests'' means only those 
whose transmission is required under state and local law.
    Response. We appreciate the submission of these comments, but they 
are outside the scope of this rulemaking. We direct commenters to the 
Stage 2 final rule found elsewhere in this issue of the Federal 
Register for a discussion of the MU objective and measure and responses 
to these comments.
    Comments. A commenter stated that is important that public health 
authorities have the prerogative to prioritize which submitters are 
moved in to production first.
    Response. This certification criterion and certification in general 
does not

[[Page 54248]]

address or regulate these decisions made by public health agencies.
11. Unchanged Certification Criteria
    In the Proposed Rule, we described the certification criteria that 
we considered ``unchanged.'' We noted the following factors in 
determining whether a certification criterion would be ``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 explained 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 adopted at 
Sec.  170.314(d)(1) meets this description. Additionally, as we 
specified in the Proposed Rule, 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 adopted at Sec.  170.314(d)(8) meets this 
description. We discussed in the Proposed Rule and in the description 
of revised certification criteria in this final rule that 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 if it were 
subsequently adopted for both settings.
    Comments. We did not receive comments questioning our description 
of unchanged certification criteria.
    Response. Therefore, we continue to use this description of 
unchanged certification criteria to categorize the following 
certification criteria we have adopted as part of the 2014 Edition EHR 
certification criteria. For clarity, we have adopted these unchanged 
certification criteria in addition to the unchanged certification 
criteria previously discussed in this preamble (``immunization 
information'' Sec.  170.314(f)(1) and ``receive laboratory test and 
values/results'' Sec.  170.314(b)(5)--inpatient setting only).
a. Refinements to Unchanged Certification Criteria
    In the Proposed Rule, we proposed refinements to the following 
unchanged certification criteria. We received public comments on all of 
the certification criteria. We discuss the public comments received and 
the adoption of these unchanged certification criteria as part of the 
2014 Edition EHR certification criteria 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 proposed a CPOE certification criterion that merged the separate 
ambulatory and inpatient CPOE certification criteria in the 2011 
Edition EHR certification criteria into one criterion because they 
those certification criteria are identical. We proposed to replace the 
terms ``modify'' and ``retrieve'' with ``change'' and ``access,'' 
respectively. We also proposed to remove the term ``store'' from the 
criterion because it is redundant with our interpretation of the term 
``record.'' Finally, we proposed to move the phrase ``at a minimum'' in 
the certification criterion to eliminate any possible ambiguity as to 
what the phrase modifies. As proposed, the certification criterion made 
clear that the phrase modifies the order types and not the terms 
``record,'' ``change,'' and ``access.''
    Comments. Many commenters expressed general support for this 
certification criterion as proposed. We also received many comments 
requesting further clarification of the CPOE denominator, including 
clarifying what orders count, what providers may enter the orders, and 
how current MU EHR users should report measures when transitioning to 
EHR technology certified to the 2014 Edition EHR certification criteria 
during an EHR reporting period in 2013. One commenter requested 
clarification as to whether the change in the CMS measure definition 
would require ``re-certification'' to this certification criterion or 
if it would only affect certification to the automated measure 
calculation certification criterion.
    A commenter recommended that this certification criterion include 
the capability to send the order information in an electronic format 
consistent with the content exchange standard identified in the 
Proposed Rule at section 170.205(k) (HL7 2.5.1 and the HL7 Version 
2.5.1 Implementation Guide: Standards and Interoperability Framework 
Lab Results Interface, Release 1 (US Realm)). Another commenter 
recommended that this certification criterion should be amended to 
require some notation about a patient's predominant race when multiple 
races are identified.
    One commenter recommended that CPOE of radiology be separated into 
its own certification criterion. The commenter stated that the new 
``radiology'' certification criterion should require that CPOE of 
radiology have integrated CDS tied to national physician association-
developed appropriateness criteria guidelines. The commenter reasoned 
that appropriateness criteria-guided CDS at the point-of-order will 
inform referring physicians and their patients as to the most 
clinically appropriate imaging examinations for the given indications.
    Response. We appreciate the support for the certification criterion 
as proposed and are adopting this certification criterion as an 
unchanged certification criterion for the 2014 Edition EHR 
certification criterion at Sec.  170.314(a)(1). The comments requesting 
clarification related to the denominator and the reporting of the CPOE 
measure during 2013 are outside the scope of this rulemaking. We direct 
commenters to the Stage 2 final rule for a discussion of these issues. 
However, we do clarify that the change in the CPOE denominator affects 
the ``automated measure calculation'' certification criterion (Sec.  
170.314(g)(2)), which is a revised certification criterion for the 2014 
Edition EHR certification criteria.
    This certification criterion focuses on enabling a user to 
electronically record, change, and access, at a minimum, medication, 
laboratory and radiology/imaging orders. It does not focus on the 
transmission of these orders.

[[Page 54249]]

Additionally, the standard recommended by the commenter is incorrect 
because it focuses on the receipt of laboratory tests results, not the 
outbound transmission of laboratory orders. Therefore, we decline, as 
recommended by the commenter, to include the standard. We also do not 
believe that the recording of race should be associated with this 
certification criterion as recommended by a commenter because such an 
action would dictate workflow and the recording of race is already 
required by the ``demographics'' certification criterion (Sec.  
170.313(a)(3)). Last, we decline to separate out radiology orders into 
a separate certification criterion. While we appreciate the enhanced 
clinical functionality presented in the commenter's recommendation, 
this certification criterion is focused on the general CPOE capability 
for various types of orders and supporting the associated MU objective 
and measure. Additionally, as structured, this certification criterion 
contemplates the general functionality applying to more than just 
radiology or the other two types of orders specified.
     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).
------------------------------------------------------------------------

    We proposed to merge the ``access control'' certification criterion 
at Sec.  170.302(o) and the ``authentication'' certification criterion 
at Sec.  170.302(t) into one certification criterion for the 2014 
Edition EHR certification criteria. We reasoned that since the two test 
procedures developed for these certification criteria were similar and 
that the capabilities included in the certification criteria go hand-
in-hand, it was best to merge the two certification criteria into one 
certification criteria. We stated that this would allow for more 
efficient testing and was consistent with EHR technology development.
    In combination with this proposal, we proposed to adopt part of the 
HITSC's recommendation related to person/user authentication, which was 
reflected in the proposed certification criterion. We 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 stated 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 within an EP, EH, or CAH's organization 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. We further stated that 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 acknowledged in the Proposed Rule's preamble, as recommended by 
the HITSC, example standards and implementation specifications which 
could be followed in designing EHR technology to meet this 
certification criterion. In particular, we specified that these example 
standards and implementation specifications could include, but were not 
limited to: NIST Special Publication 800-63, Level 2 (single-factor 
authentication) and ASTM, E1986-09 (Information Access Privileges to 
Health Information).
    Comments. A majority of comments on the proposed certification 
criterion supported it as proposed and without any changes for the 
final rule. One commenter voiced its appreciation for the consolidation 
of the two prior 2011 Edition EHR certification criteria. Another 
commenter requested that we clarify whether the certification criterion 
applies to: internal system and/or human users; external system and/or 
human users that are recipients of ``push'' type health information 
exchanges such as those required for in the Stage 2 proposed rule; or 
excludes all external system and/or human users. The commenter went on 
to note that this certification criterion does not include standards to 
consistently specify electronic health information as distinguishable 
security objects; specify whether the access is at a coarse or fine 
grain level as would likely be required for data segmentation for 
privacy; encode the ``actions'' in a consistent and meaningful manner 
using standard data operations vocabulary; and specify an interoperable 
value set of standard structural and functional roles. Further, 
commenters noted that we should clarify the users to which the 
certification criteria apply; and require adoption of the privacy and 
security standard vocabularies such as those established by HL7 and 
ASTM. Other commenters noted that the test procedure would need to be 
updated for this certification criterion. Last, a commenter stated that 
we should revise the requirement for single factor level of assurance 
(LOA) 2 authentication and increase it to LOA 3, 2-factor 
authentication. The commenter reasoned that by the time the final rule 
goes into effect, additional LOA 3, 2-factor credential form factors 
will be available to the general public and that these credentials will 
be readily available from multiple commercial sources.
    Response. We appreciate commenters support for this certification 
criterion and have adopted it in this final rule as proposed. As we 
stated in the Proposed Rule, 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 
within an EP, EH, or CAH's organization 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. With respect to the 
other points raised in comments, we have purposefully left this 
certification criterion flexible to accommodate for different 
implementations, deployments, and organizational policy decisions. 
Ultimately, this certification criterion sets a minimum requirement and 
provides assurance that an EP, EH, and CAH's CEHRT includes 
capabilities that can perform authentication, access control, and 
authorization. Contrary to a commenter's suggestion, the certification 
criterion does not specify an LOA, which in turn permits EHR technology 
developers to satisfy it in a number of different ways. Practically 
speaking, however, one-factor authentication would, at a minimum, be 
needed to satisfy the certification criterion. Finally, we appreciate 
the commenters' suggestions about specific security vocabulary 
standards. We did not propose to include any of these standards and 
believe that it would be prudent to first have the HITSC consider their 
inclusion and whether it would be necessary to specify them in a 
certification criterion or in guidance or some other type of 
educational material.
     Automatic log-off

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

[[Page 54250]]

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

    In the Proposed Rule, we proposed to adopt the automatic log-off 
certification criterion from the 2011 Edition EHR certification 
criteria (i.e., as unchanged). We did, however, seek to clarify what 
``terminate'' in the certification criterion conveyed. We stated that 
terminating a session should not be confused with locking a session, 
where access to an active session is permitted after re-authentication. 
We then indicated that EHR technology must have the capability to 
terminate the session, including terminating the network connection.
    Comments. Many commenters supported our proposal and agreed that 
the certification criterion should remain unchanged for the 2014 
Edition EHR certification criteria. Several commenters, though, took 
issue with our clarification. One commenter noted that our proposal 
does not describe what impact termination has on documentation in 
progress at the time termination occurs. The commenter stated that this 
would create the potential for information loss and give clinicians a 
false sense that information entered into the patient's medical record 
had been saved. Another commenter disagreed with our clarification 
because it would draw a distinction between a session ``termination'' 
and a session ``lock.'' The commenter contended that any attempt to 
draw such a distinction is purely subjective. The commenter stated 
that, for example, an application's session state may persist in local 
memory or in a centralized data store and that both of these could be 
used to reconstitute a session which has been suspended by various 
means. In the latter case, where a centralized data store is used for 
the persistence of session state, the user may terminate the 
application, reboot the workstation, restart the application and pick 
up where they left off during their previous session. In the end, the 
commenter proposed that any application state which: (a) Renders 
application information completely inaccessible; (b) requires login 
authentication to access the application; and (c) requires the same 
credentials to access previous session state should qualify as a 
termination. Further, they stated that this definition should apply 
regardless of whether the application is physically terminated or not, 
and regardless of whether the ability to reconstitute a previous 
session is implemented through a centralized data store, or through in-
memory persistence of session state. Another comment sought 
clarification that automatic log-off of an application does not lead to 
automatically terminated network connections of other applications 
active on, e.g., the desktop or server. Similarly, another commenter 
stated that multiple applications may be running and concurrently using 
the network connection on the same device. The commenter stated that 
the proposed language implies that all network connections from the 
end-user device are terminated automatically when the application shuts 
down. They suggested that the termination of network connections be 
limited to those used by the application being shut down. Once 
commenter believed that we should clarify that it is the user's session 
within the EHR that should be terminated.
    Response. We appreciate the thoughtful and detailed responses 
provided by commenters. In considering the prior response we issued in 
the S&CC July 2010 Final Rule (75 FR 44617-618), our clarification in 
the Proposed Rule, and the comments received on the Proposed Rule, we 
believe that additional clarity is necessary regarding the capability 
expressed by this certification criterion. Given the scenarios 
identified by commenters, we believe that EHR technology developers 
should interpret this certification criterion to require (as one 
commenter described) that after a period of inactivity the EHR 
technology must make a user's session inaccessible and subsequently 
require the user to re-authenticate using the same credentials used to 
begin or resume the session. To make the capability expressed by this 
certification criterion clearer to EHR technology developers, we have 
replaced ``Terminate'' with ``Prevent a user from gaining further 
access to * * *.'' Although this may be longer phrasing toward the same 
meaning, we believe it less ambiguous than ``terminate,'' is more plain 
language, and that it is also consistent with the language used for the 
``session lock'' security control specified in NIST 800-53 rev3. 
Additionally, we clarify that this certification criterion is not meant 
to result in the termination of network connections, especially network 
connections that are not in use by the EHR technology, but by other 
applications.
     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).
------------------------------------------------------------------------

    In the Proposed Rule, we proposed to include in the 2014 Edition 
EHR certification criteria a refined version of the 2011 Edition EHR 
certification criterion for emergency access codified at Sec.  
170.302(p). We proposed to remove the parenthetical ``who are 
authorized for emergency situations'' from the certification criterion 
and include the phrase ``identified set of users.'' We stated that 
these refinements would more clearly convey the capabilities included 
in this certification criterion and align with our consistent use of 
the phrase ``identified set of users'' in every certification criterion 
where we intend for the same capability to be available. We explained 
that the purpose of this certification criterion is to provide certain 
users (``identified set of users'') with the ability to override normal 
access controls in the case of an emergency.
    Comments. Almost all commenters that commented on this 
certification criterion expressed their support for the certification 
criterion as an unchanged certification criterion. One commenter 
recommended that organizations be afforded the opportunity to define 
their solution for emergency access based on their organizational 
security policy, which may differ from the certification criterion and 
testing procedures for emergency access. Another commenter suggested 
that we create a more specific requirement because the current 
requirements are ambiguous and do not provide enough guidance to EHR 
technology developers.
    Response. We appreciate the support expressed by many commenters 
and are finalizing this certification criterion as proposed. With 
respect to the two comments expressing alternative options for 
certification, we believe these comments represent the opposite ends of 
the continuum we seek to balance and manage when we adopt a 
certification criterion. If the certification criterion was too 
specific, the capability provided by a Complete EHR or EHR Module may 
not be able to accommodate various organizational implementations. If 
not specific enough, EHR technology developers could include 
significantly different capabilities. The clarifying language provided 
in the Proposed Rule and recited above as well as our prior responses 
to comments included in the

[[Page 54251]]

S&CC July 2010 Final Rule (75 FR 44617) for the 2011 Edition version of 
this certification criterion provide ample specificity for EHR 
technology developers. They also include for the benefit of commenters 
the citation to the HIPAA Security Rule requirement on which this 
certification criterion is modeled (68 FR 8355).
     Integrity

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

    We proposed an ``integrity'' certification criterion at Sec.  
170.314(d)(8) that was consistent with the HITSC's recommendation. We 
also proposed to remove the capability to detect changes to an audit 
log because we proposed to add that capability to the proposed 
certification criterion for ``auditable events and tamper resistance'' 
at Sec.  170.314(d)(2). The 2011 Edition EHR certification criterion 
adopted 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.'' We stated in the Proposed Rule 
that, after consultation with NIST, we understood 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 stated 
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. Therefore, we requested public comment on whether we 
should leave the standard as SHA-1 or replaces it with SHA-2.
    Comments. Many commenters expressed support for the certification 
criterion as proposed. These commenters also recommended retaining the 
SHA-1 standard as a baseline because it is still relied upon in many 
instances. One commenter noted that the use of SHA-1 and its security 
strength is sufficient until digital signatures are broadly required in 
the industry. Other commenters supported moving to SHA-2 as a better 
long-term alternative.
    One commenter did not support the use of ``message logs'' as the 
only method of protecting health information during transmission. The 
commenter contended that this certification criterion accounts for a 
single-vendor system and does not address self-developed systems that 
may use multiple platforms and internally-developed systems that are 
interfaced together. The commenter further contended that there are 
available methods to provide for secure and accurate exchange without 
limiting the solution to message logs. As such, the commenter suggested 
that this certification criterion should be modified to account for 
internal versus external transmissions.
    Response. We thank commenters for their support. We are finalizing 
this certification criterion and its associated standard as proposed. 
We agree with commenters that EHR technology developers should migrate 
towards the use of SHA-2 because of its increased security strength, 
but only where possible and voluntarily. The SHA-1 standard included in 
this certification criterion serves as a floor and permits EHR 
technology to be certified if it includes hashing algorithms with 
security strengths equal to or greater than SHA-1. As expressed by many 
commenters, the use of SHA-1 is still relied upon in many instances. 
For example, the Applicability Statement for Secure Health Transport 
standard that we have adopted in other certification criteria requires 
that SHA-1 must be supported in addition to SAH-256. We decline to 
accept the commenter's recommendation to have the certification 
criterion differentiate between internal and external transmissions as 
that distinction is not necessary for the purposes of certification and 
determining whether EHR technology can perform this capability 
according to the adopted standard. The capability's subsequent use for 
internal and/or external transmissions, as the commenter advocates, is 
up to the EP, EH, and CAH to determine in accordance with its 
organizational policies. As a final note, we seek to call to readers' 
attention that NIST has superseded FIPS 180-3 with FIPS 180-4. The 
changes in FIPS 180-4 are limited in scope and do not affect the 
approach we have expressed in the standard we adopted for this 
certification. Therefore, in order keep the regulation current with 
this recent publication we have modified the regulation text to refer 
to FIPS 180-4 instead of 180-3.
b. Unchanged Certification Criteria Without Refinements
    We proposed to include the following unchanged certification 
criteria in the 2014 Edition EHR certification criteria without any 
substantial refinements, except, where appropriate, replacing the terms 
``generate,'' ``modify,'' and ``retrieve'' with ``create,'' ``change,'' 
and ``access,'' respectively. For the ``accounting of disclosures'' 
certification criterion, we specifically requested comments whether we 
should revise the criterion. We received public comments on all of the 
certification criteria. We discuss the public comments received and the 
adoption of these certification criteria as part of the 2014 Edition 
EHR certification criteria below.
     Accounting of Disclosures

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
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)(9) (optional--accounting of disclosures).
------------------------------------------------------------------------

    We proposed to adopt the same optional ``accounting of 
disclosures'' certification criterion included in the 2011 Edition EHR 
certification criteria (Sec.  170.302(w)) as an optional certification 
criterion for the 2014 Edition EHR certification criteria (Sec.  
170.314(d)(9)). We did, however, specifically request public comment on 
whether we should adopt a revised certification criterion. We noted 
that since publication of the S&CC July 2010 final rule, the HHS Office 
for Civil Rights (OCR) 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.\33\ We expressed interest in knowing whether commenters 
believed that the 2014 Edition EHR certification criterion for 
``accounting of disclosures'' should be revised to be a mandatory 
certification criterion. We also expressed interest in knowing whether 
commenters thought 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.

[[Page 54252]]

Additionally, we expressed interest 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 believed revisions were appropriate, we asked 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 and the rationale for including 
those capabilities.
---------------------------------------------------------------------------

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

    Comments. Commenters overwhelmingly supported keeping this 
certification criterion as optional and without revision. Many 
commenters pointed to the significant amount of comments that were 
submitted on the ``accounting of disclosures'' proposed rule (76 FR 
31426) issued by OCR, particularly the comments they characterized as 
expressing significant concern with the proposals in the proposed rule. 
Most commenters stated that this certification criterion must be fully 
aligned with the specifics of the ``accounting of disclosures'' final 
rule and suggested that ONC and OCR work together in this regard. A few 
commenters even suggested that we remove the certification criterion 
until a ``accounting of disclosures'' final rule is issued. A few 
commenters recommended that this certification criterion become 
mandatory and generally stated that it 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. One commenter recommended that the specific 
capabilities that the ``accounting of disclosures'' certification 
criterion should be revised to include are: (1) The access report 
capability set forth in the proposed rule proposing to modify the HIPAA 
Privacy Rule's accounting for disclosures requirements; and (2) the 
universal accessibility of accounting of disclosures. Another commenter 
recommended that the certification criterion include a requirement to 
account for disclosures of protected health information, including 
release of information to third parties for care coordination, data-
sharing and research purposes. Along these lines, a commenter 
recommended that EHR technology have the capability to document whether 
a patient has accepted or denied a disclosure agreement (e.g., for 
research purposes).
    A commenter requested clarification regarding whether the data 
elements required to be recorded for accounting of disclosures be in 
structured format or free text. One commenter asked whether the part of 
the ASTM E2147-01 standard that deals with disclosures has 
applicability to this certification criterion and suggested that it 
should be applicable to this certification criterion.
    Response. We thank commenters for their feedback. We are adopting 
this certification criterion as an unchanged certification criterion 
for the 2014 Edition EHR certification criterion at Sec.  170.314(d)(9) 
and have continued to designate it as ``optional.'' After consideration 
of the comments received, we agree with those commenters that 
recommended we wait and consider how best to align this certification 
criterion with the provisions of an ``accounting of disclosures'' final 
rule issued by OCR. We appreciate the suggested revisions offered by 
commenters, but believe that alignment with an ``accounting of 
disclosures'' final rule will provide the most certainty and useful 
functionality for EPs, EHs, and CAHs, while also mitigating any EHR 
technology development and implementation burdens that may accrue 
through compliance with potential multiple adopted versions of this 
certification criterion.
    We clarify for commenters that each disclosure that has been 
recorded must be done so in accordance with the standard at Sec.  
170.210(d) and must include the date, time, patient identification, 
user identification and the description of each disclosure. As to the 
commenter's question about whether this information could be captured 
in free text, we expect that date, time, patient identification, and 
user identification would be automatically recorded only by EHR 
technology. With respect to the description of each disclosure, we 
reiterate what we stated in the S&CC July 2010 Final Rule in response 
to this question (75 FR 44624). ``As we discussed in the Interim Final 
Rule, we intended to leave Complete EHR and EHR Module developers with 
the flexibility to innovate in this area and to develop new solutions 
to address the needs of their customers. We anticipated that a 
`description of the disclosure' would, at the present time, be a free 
text field that would have included any information that could be 
readily and electronically associated with the disclosure. For example, 
we envisioned that some descriptive information could be included such 
as the words `treatment,' `payment,' or `health care operations' 
separately or together as a general category.''
    The ASTM E2147-01 standard has not been adopted in whole or in part 
for this certification criterion and we decline to adopt any part of 
the ASTM E2147-01 standard for this certification criterion at this 
time. Consistent with our rationale above, we believe it is most 
appropriate to wait and consider the provisions of an ``accounting of 
disclosures'' final rule to be issued by OCR before making any 
revisions to this certification criterion.
     Advance Directives

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Record whether a patient 65 years old or older has an advance directive.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(a)(17) (Inpatient setting only--advance directives).
------------------------------------------------------------------------

    Comments. The majority of commenters expressed support for this 
certification criterion as an unchanged certification criterion. More 
specifically, commenters stated that this certification criterion 
should include the capability to record whether a patient has an 
advance directive, but not require the EHR technology to demonstrate 
that the actual advance directive document is recorded as an electronic 
document in the EHR technology. A commenter recommended that this 
requirement be included for the ambulatory setting as well so that this 
data could be easily exchanged between EPs, EHs, and CAHs. One 
commenter suggested that EHR technology be required to provide user 
access to the advance directive. Another commenter suggested that EHR 
technology should provide patients with access to their advance 
directives and provide patients the capability to change the advance 
directive.
    Some commenters recommended that the certification criterion be 
modified to accommodate scanned copies of advance directives as well as 
reconciliation and version control capabilities. Other commenters 
suggested that standard vocabulary was needed to describe and capture 
an advance directive, including in the Consolidated CDA. A few 
commenters suggested that we consider requiring EHR technology be 
capable of recording the type of advance directive (e.g., Intubation, 
Tube Feedings, Life Support) and the effective date/time periods for 
the advance directive. The commenters reasoned that, while the 
indication of an advance directive is not part of the summary of care 
record for

[[Page 54253]]

MU, the Consolidated CDA that will be used for the 2014 Edition EHR 
certification criteria calls for an indication of the type of advance 
directive. Therefore, these commenters suggested this was an 
opportunity to encourage EHR technology developers to implement such 
functionality in conjunction with the Consolidated CDA functionality. 
Conversely, some commenters stated that it is not necessary to require 
specific codes for ``types'' of advance directives because they are not 
often collected and may vary from state to state.
    A few commenters requested clarification on whether ``yes'' and 
``no'' data fields constituted ``structured'' data. Another commenter 
requested clarification on whether structured data implied a Boolean 
indicator.
    Response. We appreciate the support for the certification criterion 
as proposed and are adopting this certification criterion as an 
unchanged certification criterion for the 2014 Edition EHR 
certification criterion at Sec.  170.314(a)(17). This certification 
criterion's scope focuses on the capabilities necessary to support MU, 
which requires the recording of whether a patient 65 years old or older 
has an advance directive. A patient's advance directive is not required 
to be available or accessible with EHR technology. Under MU, advance 
directive information is also not included in the summary care record, 
required to be provided after a patient's office visit, or required to 
be available for online viewing or downloading by a patient. 
Accordingly, while we appreciate the commenters' suggested 
modifications and inclusion of additional capabilities for this 
certification criterion (i.e., requiring this capability for the 
ambulatory setting, making the actual advance directive available in 
scanned or structured format, noting the type of advance directive, 
providing user or patient access to the advance directive and the 
ability to change the advance directive), we decline to make any 
revisions to this certification criterion at this time since such 
additional capabilities would be beyond those needed to support MU.
    We clarify that EHR technology would only need to demonstrate that 
it can include an advance directive indicator and that the indicator is 
stored in the patient's record. The use of ``yes'' and ``no'' data 
fields may be one method for EHR technology to meet this certification 
criterion. A Boolean search capability based on patients with advance 
directives is not a requirement to meet this certification criterion.
     Medication List

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Maintain active medication list.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(a)(6) (Medication list).
------------------------------------------------------------------------

    Comments. The majority of commenters recommended that this 
certification criterion remain unchanged. Commenters reasoned that it 
is appropriate to be non-prescriptive related to standards for internal 
EHR functionality, while requiring the use of standards for health 
information exchange. Conversely, a few commenters suggested that we 
evaluate the applicability of standards for this certification 
criterion with one commenter suggesting the use of the RxNorm standard. 
These commenters suggested that this would lead to EPs, EHs, and CAHs 
having the capability of providing this information as structured data 
in an interoperable format. One commenter suggested that this 
certification criterion be modified to require that EHR technology be 
capable of providing a description of each medication's class and 
intended purpose. One commenter stated that EHR technology should 
support the import of medication lists from external sources, such as 
an HIE, for true longitudinal care across providers.
    Response. We appreciate the support for the certification criterion 
as proposed and are adopting this certification criterion as an 
unchanged certification criterion for the 2014 Edition EHR 
certification criterion at Sec.  170.314(a)(6). We believe that this 
certification criterion as adopted supports MU. Therefore, requiring 
EHR technology to be capable of providing a description of each 
medication's class and intended purpose is not necessary for 
certification. However, as we state elsewhere, EHR technology 
developers are free to include capabilities that go beyond 
certification requirements.
    As discussed in other certification criteria, we have required the 
use of RxNorm in instances where EHR technology would be used to 
perform external transmissions (e.g., for a transition of care (Sec.  
170.314(b)(2)). Additionally, we require the capability to reconcile a 
patient's medication list as part of the adopted ``clinical information 
reconciliation'' certification criterion at Sec.  170.314(b)(4) and the 
receipt of RxNorm codes in a transition of care/referral summary should 
greatly facilitate this process. Thus, at this juncture, we do not 
believe it is necessary to require as a condition of certification that 
EHR technology natively record medications directly into RxNorm 
although such an approach may be more efficient and expeditious for 
some. We continue to remain cognizant of the potential burden that 
requiring a standard for this certification criterion could cause and 
continue to believe it is appropriate to provide EPs, EHs, and CAHs 
with the flexibility to internally record such information in a manner 
that includes the medication vocabularies with which they are familiar.
    We note that in response to comments received on our use of the 
term ``longitudinal care'' in this certification criterion and in other 
certification criteria, we have replaced the term with the meaning we 
gave the term for the ambulatory and inpatient settings in the Proposed 
Rule. We refer readers to our discussion of the revised ``problem 
list'' certification criterion earlier in this preamble.
     Medication Allergy List

------------------------------------------------------------------------
 
-------------------------------------------------------------------------
MU Objective
Maintain active medication allergy list.
------------------------------------------------------------------------
2014 Edition EHR Certification Criterion
Sec.   170.314(a)(7) (Medication allergy list).
------------------------------------------------------------------------

    Comments. The majority of commenters recommended that this 
certification criterion remain unchanged. A couple of commenters 
suggested expanding to include all allergies, including food and 
substance allergies. The commenters reasoned that it was important to 
maintain lists of these allergies to prevent adverse reactions and 
other patient-safety events. These commenters also suggested 
referencing a standard such as RxNorm or UNII as applicable for these 
additional types of allergens. Another commenter specifically suggested 
that we require the use of RxNorm for this certification criterion. One 
commenter stated that EHR technology should support the import of 
medication allergy lists from external sources, such as an HIE, for 
true longitudinal care across providers.
    Response. We appreciate the support for the certification criterion 
as proposed and are adopting this certification criterion as an 
unchanged certification criterion for the 2014 Edition EHR 
certification criterion at Sec.  170.314(a)(7). While we appreciate the 
commenters' suggestion to expand the capabilities included in this 
certification criterion to cover additional types of allergens and 
patient safety is one our utmost concerns, such additional capabilities 
would be beyond those needed to support MU. Therefore, although we 
decline to adopt this recommendation, we continue to encourage EHR 
technology developers

[[Page 54254]]

to include capabilities that may go beyond certification requirements, 
particularly where that may improve patient safety. Similar to the 
rationale provided in our response above regarding the ``medication 
list'' certification criterion, we decline to require as a condition of 
certification that EHR technology natively record medication allergies 
directly into RxNorm. We have however, in response to these comments 
and other comments received on the other certification criteria that 
reference medication allergies, adopted RxNorm for instances where this 
data would be included in a CCDA formatted document.
    We note that in response to comments received on our use of the 
term ``longitudinal care'' in this certification criterion and in other 
certification criteria, we have replaced the term with the meaning we 
gave the term for the ambulatory and inpatient settings in the Proposed 
Rule. We refer readers to our discussion of the revised ``problem 
list'' certification criterion earlier in this preamble.
12. Gap Certification
    ``Gap certification'' is ``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 in the Permanent Certification Program final 
rule (76 FR 1307) and reiterated in the Proposed Rule that gap 
certification will focus on the difference between certification 
criteria that are adopted through rulemaking at different points in 
time. We discuss in section III.A of this preamble, as we did in the 
Proposed Rule, the factors we would consider in determining whether a 
2014 Edition EHR certification criterion is ``new'' or ``revised.'' 
Examples of new certification criteria are the ``secure messaging'' 
certification criterion at Sec.  170.314(e)(3) and the ``electronic 
medication administration record'' certification criterion at Sec.  
170.314(a)(17). An example of a revised certification criterion is the 
``CDS'' certification criterion at Sec.  170.314(a)(8). This 
certification criterion is ``revised'' because it 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 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.
    We stated in the Proposed Rule that 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. For the certification criteria 
that we identified as unchanged in the Proposed Rule, we stated that 
test results that were used previously to certify a Complete EHR or EHR 
Module to the 2011 Edition EHR certification criteria could be used to 
certify the Complete EHR or EHR Module to the corresponding 2014 
Edition EHR certification criteria that we identified. We provided an 
illustration of how gap certification would work with our proposed 2014 
Edition EHR certification criteria. 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 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 the ``drug-drug, drug-allergy interaction 
checks'' certification criterion at Sec.  170.314(a)(2) has been 
identified as a revised certification criterion as part of the 2014 
Edition of EHR certification criteria.
    Comments. Multiple comments expressed support for our gap 
certification policy and the identification of unchanged certification 
criteria for the purposes of gap certification. Commenters noted that 
gap certification would increase the efficiency of the certification 
process and reduce costs for EHR technology developers and EPs, EHs and 
CAHs. A commenter requested clarification about whether a Complete EHR 
or EHR Module previously certified to the 2011 Edition EHR 
certification criteria would need to maintain the same scope of 
certification to be able to be ``gap-certified'' to the 2014 Edition 
EHR certification criteria, and whether pursuing a different scope of 
certification would require a ``new'' certification even if the same 
criteria are part of the scope of the 2014 Edition certification. This 
same commenter also noted that for some Complete EHRs and EHR Modules 
certified to unchanged certification criteria, they would still need to 
be tested to Sec.  170.314(g)(2). Another commenter requested that ONC 
provide ONC-ACBs with gap certification guidance so that there is 
consistency in the implementation of the policy.
    Response. We appreciate commenters support for gap certification. 
We agree with commenters that gap certification would be a less costly 
and more efficient certification option for EHR technology developers. 
We assume that by ``same scope of certification,'' the commenter meant 
whether a Complete EHR or EHR Module previously certified to the 2011 
Edition EHR certification criteria could only be certified to the 
corresponding 2014 Edition EHR certification criteria. We clarify that 
a previously certified Complete EHR or EHR Module would not need to 
maintain the same scope of certification to be gap certified. For 
example, it would be impossible for a Complete EHR designed for the 
ambulatory setting presented for certification to the 2014 Edition EHR 
certification criteria to be the same in scope as a Complete EHR 
previously certified to the 2011 Edition EHR certification criteria 
because the 2014 Edition EHR certification criteria applicable to the 
ambulatory setting include new certification criteria adopted by the 
Secretary. Similarly, an EHR Module presented for certification to the 
2014 Edition EHR certification criteria may be certified to more 
certification criteria than it was previously certified to the 2011 
Edition EHR certification criteria and still be gap certified to the 
unchanged certification criteria it includes. Along these lines, as 
referenced by a commenter, EHR Modules certified to the 2014 Edition 
EHR certification criteria that include a capability that supports a MU 
percentage-based measure will need to be certified to either the new 
certification criterion at Sec.  170.314(g)(1) or the revised 
certification criterion at Sec.  170.314(g)(2) independent of the 
designation (i.e., new, revised, or unchanged) of the certification 
criterion that includes the capability that supports a MU percentage-
based measure (to note, Complete EHRs would need to be certified to 
Sec.  170.314(g)(2)). As stated in the Permanent Certification Program 
final rule (76 FR 1308), in all of these

[[Page 54255]]

examples, an ONC-ACB would issue a certification to the entire Complete 
EHR or EHR Module it certifies to the 2014 Edition EHR certification 
criteria. We also provided a detailed explanation of gap certification 
and initial guidance in the Permanent Certification Program final rule 
(76 FR 1307-08) and intend to provide additional guidance as necessary 
to facilitate a consistent implementation of gap certification by ONC-
ACBs.
    For the purposes of gap certification, table 3 below provides a 
crosswalk of unchanged 2014 Edition EHR certification criteria to the 
corresponding 2011 Edition EHR certification criteria. This table has 
been revised compared to the table included in the Proposed Rule (77 FR 
13860-61). We have removed from the table both the certification 
criteria that have now been adopted as revised certification criteria 
and those that were not adopted as part of the 2014 Edition EHR 
certification criteria. The proposed unchanged certification criteria 
that have been adopted as revised certification criteria are: ``drug-
formulary checks'' (Sec.  170.314(a)(10)); ``vital signs, body mass 
index, and growth charts'' (Sec.  170.314(a)(4)); ``smoking status'' 
(Sec.  170.314(a)(11)); ``patient lists'' (Sec.  170.314(a)(14)); and 
``patient reminders'' (Sec.  170.314(a)(15))[now combined and 
collectively referred to as ``patient list creation'' (Sec.  
170.314(a)(14)) in this final rule]. The certification criteria that 
were proposed as part of the 2014 Edition EHR certification criteria, 
but were not adopted are ``public health surveillance'' (Sec.  
170.314(f)(3)) and ``reportable laboratory tests and values/results'' 
(Sec.  170.314(f)(5)). We also note, as identified in table 3, that for 
the 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 such EHR technology must 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)(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(b)(5)...................  Incorporate            170.302(h)......................  Incorporate
                                   laboratory tests and                                     laboratory test
                                   values/results                                           results.
                                   (inpatient setting
                                   only).
170.314(f)(1)...................  Immunization           170.302(k)......................  Submission to
                                   information.                                             immunization
                                                                                            registries.
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)...................  Optional-accounting    170.302(w)......................  Accounting of
                                   of disclosures.                                          disclosures.
170.314(a)(1)...................  Computerized provider  170. 304(a).....................  Computerized provider
                                   order entry.          170. 306(a).....................   order entry.
170.314(a)(17)..................  Inpatient setting      170.306(h)......................  Advance directives.
                                   only-advance
                                   directives.
----------------------------------------------------------------------------------------------------------------

13. Disability Status
    In the Proposed Rule, we solicited comments on whether 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''). We stated that 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 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. The recording of 
disability status could also help monitor disparities between the 
``disabled'' and ``nondisabled'' population.
    We asked commenters whether there exists a standard(s) that would 
be appropriate for recording disability status in EHR technology. We 
pointed commenters to the standard for disability status approved by 
the Secretary for use in population health surveys sponsored by HHS 
\34\ and standards under development as part of the Standards and 
Interoperability Framework and the Continuity Assessment Record and 
Evaluation (CARE) assessment tool.\35\ We asked commenters whether 
these standards or any other standards would be appropriate for 
recording disability status in EHR technology.
---------------------------------------------------------------------------

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

    We requested 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 requested that commenters consider 
whether the recording of disability status should be part of a Base EHR 
definition and included in a separate certification criterion or 
possibly the ``demographics'' certification criterion (Sec.  
170.314(a)(3)). Last, we requested that commenters 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)).
    Comments. Commenters stated that there could be many benefits from 
the recording of disability status, such as

[[Page 54256]]

the ones we described in the Proposed Rule. Commenters, however, 
expressed a significant lack of consensus on how to define disability 
status. Some commenters stated that ``functional status,'' is a more 
precise, comprehensive, and objective measure for describing the 
patient's clinical status. Other commenters stated that functional, 
cognitive, and disability status were distinct. One commenter suggested 
that we use the definition for ``disability'' identified in the 
Americans with Disabilities Act Amendments Act. A couple of commenters 
stated that there is no commonly accepted definition that could be used 
for our purposes.
    Commenters also expressed concern over disability status being 
improperly defined, accurately recorded for a patient, and shared with 
others. A few commenters stated that there may be legal ramifications 
for patients or providers if the term ``disability'' is erroneously 
applied to a patient record as benefit determinations, entitlement to 
protected class status, and/or reimbursement could be affected. Another 
commenter noted concerns that the accuracy of the data could differ if 
the definition has subjective components and information is entered by 
multiple providers. A couple of commenters noted that disability status 
is not required for all patients or all specialties and should not be 
required in any reports (they noted that when needed, it will be sent 
as part of existing information). A couple of other commenters noted 
privacy and security concerns with sharing and reporting patient 
disabilities.
    Commenters made a variety of recommendations regarding how 
``disability status'' should be incorporated into the 2014 Edition EHR 
certification criteria. Commenters suggested including it as its own 
certification criterion, in and not in the ``demographics'' 
certification criterion, in all the certification criteria we mentioned 
in the Proposed Rule, and in the Base EHR definition. A few commenters 
also suggested that disability status could be captured in patient 
problem lists. One commenter suggested that if the recording of 
disability status is part of certification, then its recording should 
be optional.
    Commenters gave varying views on the availability of appropriate 
standards and tools for capturing disability standards. Many commenters 
also expressed views that standards were not mature enough. Commenters 
suggested the Consolidated CDA be used for capturing cognitive and 
functional status, but noted that it was not yet mature enough for 
capturing other kinds of disabilities in a structured way. Some of 
these commenters suggested that the Consolidate CDA could serve as a 
``stepping stone.'' A commenter suggested the collection of disability 
status data using the American Community Survey (ACS) questions on 
disability (these constitute the 6-question data collection disability 
standard used for population health surveys sponsored by HHS). Another 
commenter noted that the World Health Organization created an entire 
framework and vocabulary standard--the International Classification of 
Functioning, Health and Disability (ICF)--to capture and record 
functional and disability status. A commenter also suggested SNOMED 
CT[supreg] (used in the SSA CCD) or ICD-10-CM/PCS could have potential 
for use in recording disability status. Multiple commenters suggested 
that the CARE assessment tool should be used. However, one commenter 
stated that the CARE tool in its current form will not accurately 
document medical severity, functional status, and other factors related 
to outcomes as the questions lack sensitivity and, therefore, the type 
of information about the patient needed to measure outcomes and 
severity is not being collected by this instrument. A few other 
commenters stated that there is no current standard(s) appropriate for 
recording disability status in EHR technology at this time. These 
comments suggested a new standard be developed using the CARE 
assessment tool and ICF Core Sets to help guide the development of the 
standard. Another commenter suggested that new standards could be 
developed for including this as a separate section such as ``disability 
history'' (alongside ``social history'').
    Response. We appreciate the responses and various recommendations 
from commenters. Although commenters did not express consensus around a 
single definition or standard for recording or transmitting 
``disability status,'' commenters generally provided a framework from 
which forward progress on this topic can be made. Commenters noted that 
benefits could be realized when such information is captured. 
Commenters were also clear that we should not use a single term, such 
as ``disability status,'' to capture both demographics (i.e., 
impairments that are generally permanent and do not change over time) 
and clinical information (i.e., clinically assessed impairments that 
may improve, worsen, or go away over time). Commenters did suggest that 
functional and cognitive status be used for clinical information and 
that standards were available to use for both capture and transmission.
    We acknowledge that the Proposed Rule's use of a single term, 
``disability status,'' was too imprecise to represent at least the two 
different concepts expressed by commenters. As shown by the diversity 
in commenters' views and considering that, in most cases, a standard 
defines the information that must be recorded, we believe that further 
stakeholder input is necessary before EHR technology is required as a 
condition of certification to be capable of recording a patient's 
disability(ies) in a specific standard. As a starting point, we ask 
that stakeholders consider whether the recently developed 6-question 
``data standard for disability status'' adopted for population health 
surveys sponsored by HHS or any other standard would be appropriate for 
requiring the recording of the types of impairments identified in the 
6-question survey standard (e.g., ``are you deaf or do you have serious 
difficulty hearing''). Unlike clinical cognitive or functional status 
assessments, this information can be used by health care providers to 
better accommodate and respond to individual patient needs. In turn, we 
will ask the HITPC and HITSC to consider during their deliberations on 
recommendations for MU Stage 3 that they review the 6-question ``data 
standard for disability status'' and any other relevant standard for 
the recording of disabilities.
    As a current means of moving forward, we believe we can build on 
commenters' recommendations for transmitting cognitive and functional 
status. We agree with commenters that we should consider ``disability 
status,'' at minimum, in terms of functional and cognitive status. We 
also agree with commenters that the Consolidated CDA can serve as a 
``stepping stone.'' The Consolidated CDA can capture functional and 
cognitive status as well as other ``disability statuses.'' Therefore, 
considering that the ``transitions of care'' certification criteria 
already require that EHR technology be capable of using the 
Consolidated CDA, we are also requiring that EHR technology be capable 
of including patient data on functional and cognitive status in order 
to align with inclusion of this information by CMS for transitions of 
care/referrals in the Stage 2 final rule.
    Overall, we believe these initial steps will put us on a path 
forward using EHR technology to improve the quality of care for those 
patients with disabilities.

[[Page 54257]]

B. Redefining Certified EHR Technology and Related Terms

1. Proposed Revisions to the Definition of Certified EHR Technology
    Based on feedback ONC and CMS received on the CEHRT definition from 
numerous stakeholders, including EPs, EHs, CAHs, EHR technology 
developers, and multiple associations representing these and other 
stakeholders and the recommendations \36\ of the HITSC, we proposed a 
more flexible CEHRT definition. Overall, a majority of stakeholders and 
the HITSC recommended a definition that would provide EPs, EHs, and 
CAHs the flexibility to have or possess only the EHR technology 
certified to adopted certification criteria that they would need/use to 
demonstrate MU. 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 proposed to revise the CEHRT definition at Sec.  
170.102. The proposed revised CEHRT definition was broken into two 
parts based on years of applicability.
---------------------------------------------------------------------------

    \36\ HITSC recommendations dated November 16, 2011 and 
transmitted to ONC on January 17, 2012. https://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_0_6014_1818_17828_43/http%3B/wci-pubcontent/publish/onc/public_communities/_content/files/011712_iwg_transmittalmemo.pdf.
---------------------------------------------------------------------------

For FYs/CYs Up to and Including 2013
    For the first part of the revised definition of CEHRT that would 
apply for the FYs/CYs up to and including 2013, we proposed two 
specific changes. The first was 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. We stated that this 
clarification was necessary because with the adoption of the 2014 
Edition EHR certification criteria in this 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 we proposed 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 stated that 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 further clarity, we provided a cross-walk between 2011 
Edition EHR certification criteria and what we considered equivalent 
proposed 2014 Edition EHR certification criteria (77 FR 13863). We 
stated that this revision was necessary to permit 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. With respect to CQMs, however, 
we noted that 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 did not propose to change the 
set of CQMs on which EPs, EHs, and CAHs would need to report until FY/
CY 2014. Therefore, we clarified that 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 encouraged 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.
For FY and CY 2014 and Subsequent Years
    We stated that 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 for EHR technology by requiring all CEHRT to have, at a 
minimum, the capabilities included the Base EHR definition.
    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 reminded stakeholders in the Proposed Rule 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.
    We affirmed in the Proposed Rule that only two types of EHR 
technology, Complete EHRs and EHR Modules, can be certified under the 
``ONC HIT Certification Program.'' However, we pointed out that under 
the revised definition of CEHRT that we proposed 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.
    We provided the following scenarios in the Proposed Rule to 
demonstrate the added flexibility the proposed revised CEHRT definition 
could provide EPs, EHs, and CAHs. One scenario of added flexibility 
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

[[Page 54258]]

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 would be responsible for 
ensuring that they have the necessary EHR technology to meet the Base 
EHR definition 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.
    Having offered these examples of the added flexibility the proposed 
revised definition of CEHRT for FY/CY 2014 and subsequent years could 
provide, we also emphasized that under the proposed revised definition, 
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 Base EHR definition as defined in the Proposed 
Rule. 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 the Base EHR definition.
    After consultation with CMS, we determined that it would be least 
confusing and burdensome for EPs, EHs, CAHs, and EHR technology 
developers if our revised definition would apply beginning with the EHR 
reporting periods that will occur in FY/CY 2014. We stated that 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 Base EHR 
definition; 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 
requested public comment on alternative approaches 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.
    We clarified and emphasized in the Proposed Rule that 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 Base EHR definition).
    Comments. Commenters expressed appreciation and agreement with the 
added flexibility the proposed revised CEHRT definition provided EPs, 
EHs, and CAHs. The majority of commenters, however, expressed concern 
that the time available between the publication of this final rule and 
the proposed compliance dates (October 1, 2013 for EHs and CAHs and 
January 1, 2014 for EPs) for the revised CEHRT definition that would 
apply beginning with FY/CY 2014 would be insufficient. Commenters 
stated that there would not be sufficient time for developing, testing, 
and certifying EHR technologies to the 2014 Edition EHR certification 
criteria and subsequently implementing these EHR technologies in the 
healthcare environments of all EPs, EHs, and CAHs that intend to 
participate in the EHR Incentive Programs in FY/CY 2014. EHR technology 
developers suggested a minimum of 15 months is necessary from the 
availability of testing and certification for EHR technology to the 
2014 Edition EHR certification criteria if all EHs must have CEHRT that 
meets the CEHRT definition for FY/CY 2014 on October 1, 2013.
    Commenters suggested various alternatives to our proposed revised 
CEHRT definition and the CMS proposed EHR reporting periods in FY/CY 
2014. These alternative proposals suggested ways to provide additional 
flexibility and reduce burden for EHR technology developers, EPs, EHs, 
and CAHs in complying with the proposed revised CEHRT and meaningful 
use requirements. Some commenters suggested permitting EPs, EHs, and 
CAHs to meet the revised CEHRT definition for FY/CY 2014 at any time 
during their Stage 2 EHR reporting period in 2014. This would 
essentially give EHs and CAHs until September 30, 2014, and EPs until 
December 31, 2014. Other commenters suggested a shorter EHR reporting 
period for EPs, EHs, and CAHs in their first year of MU Stage 2, such 
as a 90-day or 180-day EHR reporting period. Commenters stated this 
would be similar to how MU Stage 1 was implemented. Some commenters 
suggested permitting EPs, EHs, and CAHs to use EHR technology certified 
to the 2011 Edition EHR certification criteria until at least FY/CY 
2015. A few commenters suggested that we directly correlate the 
definition of CEHRT with the MU stage. The commenters suggested that an 
EP, EH, or CAH would only need to have EHR technology that could 
support the MU stage they were attempting to achieve, such as EHR 
technology certified to the 2011 Edition if they were attempting to 
achieve MU Stage 1. The commenters also suggested that it should be 
optional for EPs, EHs, and CAHs to use EHR technology certified to the 
2014 Edition in Stage 1.
    A few commenters suggested an approach within the framework of our 
proposed revised CEHRT definition. These commenters suggested making 
the flexibility provided by our proposed revised CEHRT definition for 
FY/CY 2014 and subsequent years available during FY/CY 2012 and 2013. 
In particular, one commenter suggested that we revise the first part of 
the proposed CEHRT definition (applicable through FY/CY 2013) to 
provide EPs, EHs, and CAHs with the option of meeting a CEHRT 
definition similar to the definition for FY/CY 2014 and subsequent 
years. The commenter suggested this could be achieved by revising the 
CEHRT definition for FY/CY 2013 to include a Base EHR definition based 
on the 2011 Edition EHR certification criteria or by permitting the use 
of EHR technology in FY/CY 2013 that meets the CEHRT definition for FY/
CY 2014 and subsequent years. The commenter stated

[[Page 54259]]

that we could add flexibility by permitting an EP, EH, or CAH to use 
either option in lieu of our proposal that would limit them to only 
being able to use EHR technology certified to all of the applicable 
2011 Edition EHR certification criteria or equivalent 2014 Edition EHR 
certification criteria. The commenter identified, however, that if we 
adopt an approach allowing EPs, EHs, and CAHs to meet the proposed 
revised CEHRT definition for FY/CY 2014 and subsequent years in FY/CY 
2013, it would create a potential inconsistency with respect to CQMs. 
More specifically, the commenter stated that such an approach would 
require an EP, EH, or CAH who wanted to adopt only 2014 Edition EHR 
technology to still have 2011 Edition EHR technology that could 
calculate the CQMs required for the EHR reporting periods in 2013. To 
address this alignment issue, the commenter recommended that EPs, EHs, 
and CAHs be permitted to use 2014 Edition EHR technology and attest in 
FY/CY 2013 using the CQMs designated for the 2014 EHR reporting period 
(and that would be part of their 2014 Edition EHR technology) in lieu 
of the other CQM reporting requirements for FY/CY 2013.
    Response. We appreciate commenters' support for our proposed 
revised CEHRT definition. We understand the concerns expressed by 
commenters regarding time constraints and the steps needed for EPs, 
EHs, and CAHs to achieve compliance with the proposed revised CEHRT 
definition for FY/CY 2014. We believe with the timely publication of 
this final rule and the steps taken by CMS to add flexibility to the 
EHR reporting periods in FY/CY 2014, there will be sufficient time for 
all EPs, EHs, and CAHs that intend to participate in the EHR Incentive 
Programs in FY/CY 2014 to adopt and implement EHR technology that meets 
the CEHRT definition. The recommendations commenters made related to MU 
Stage 2 timing fall within the purview of CMS and the EHR Incentive 
Programs (i.e., length of EHR reporting periods and when EPs, EHs, and 
CAHs must possess CEHRT in relation to the EHR reporting periods). 
However, we have discussed the recommendations related to the length of 
EHR reporting periods with CMS, and CMS has determined to adopt three-
month quarter EHR reporting periods in FY/CY 2014. This will provide 
additional time for EHR technology developers as well as give EPs, EHs, 
and CAHs up to an additional 9 months to adopt EHR technology that 
meets the revised CEHRT definition for FY/CY 2014.
    We decline to accept commenters' suggestions about correlating 
``editions'' of certification criteria with MU stages (i.e., 2011 
Edition with Stage 1 and 2014 Edition with Stage 2), permitting the use 
of EHR technology certified to the 2011 Edition EHR technology through 
FY/CY 2015, or making the use of EHR technology certified to the 2014 
Edition EHR certification criteria optional for those EPs, EHs, or CAHs 
participating in MU Stage 1. While these approaches could assuage 
commenters' timing concerns, they do not account for the fact that such 
a policy decision would have significant long-term consequences with 
respect to accelerating electronic health information exchange and 
interoperability. For example, as CMS illustrated in the Stage 2 
proposed rule (77 FR 13703) and again in the Stage 2 final rule 
published elsewhere in this issue of the Federal Register, its policy 
remains that an EP, EH, and CAH will begin demonstrating meaningful use 
according to the Stage 1 criteria. Thus, if we implemented an approach 
of certifying EHR technology to MU stages (without a cutoff date), an 
EP, EH, and CAH could participate in MU Stage 1 well into the future 
with EHR technology certified to the 2011 Edition EHR certification 
criteria. Similarly, in a scenario where all three anticipated MU 
stages are in effect at the same time, EPs, EHs, and CAHs would all 
have different EHR technologies certified to different functional and 
interoperability capabilities. Such an outcome could potentially create 
a disparity among meaningful EHR users just because of the EHR 
technology they used to demonstrate MU and would serve as a limiting 
step for the adoption of more advanced capabilities for patient care, 
engagement, and safety. Moreover, this suggestion does not account for 
how confusing or challenging it could potentially be in the scenario 
where different EPs in a group practice are meeting different MU stages 
during an EHR reporting period nor does it appear to account for how 
feasible it would be for EHR technology developers to simultaneously 
support EHR technologies certified to different functional and 
interoperability capabilities for the time spans necessary. 
Alternatively, we believe, as we have finalized, that it is simpler for 
EPs, EHs, and CAHs, as well as their EHR technology developers, to have 
a single EHR technology edition upon which to reference and rely that 
can support any MU stage an EP, EH, or CAH seeks to achieve.
    We agree with the commenter's detailed suggestion that we provide 
EPs, EHs, and CAHs with the option of using EHR technology that meets 
the proposed revised definition of CEHRT for FY/CY 2014 and subsequent 
years as soon as practicable. We are therefore modifying the first part 
of the proposed revised CEHRT definition to include this flexibility. 
In other words, for the EHR reporting periods in CY/FY 2012 and 2013, 
EPs, EHs, and CAHs may use technology that satisfies the CEHRT 
definition that will apply in FY/CY 2014 and subsequent years. We 
believe this is a better approach than retrospectively creating a CEHRT 
definition for FY/CY 2012 and 2013 based on the 2011 Edition EHR 
certification criteria, which would include a ``2011 Edition'' Base EHR 
definition. A revised CEHRT definition based on 2011 Edition EHR 
certification criteria for FY/CY 2012 and 2013 would only be effective 
for about a year and during a period of time when most EHR technology 
developers will be focused on designing and upgrading their EHR 
technology to meet the 2014 Edition EHR certification criteria and not 
on meeting a new ``2011 Edition'' Base EHR definition. More 
importantly, providing such flexibility earlier will support continued 
forward momentum towards increased electronic health information 
exchange and interoperability, as well as avoid the potentially 
unnecessary and duplicative adoption of 2011 Edition and 2014 Edition 
CEHRT in the same year. To this last point and to emphasize, if an EP, 
EH, or CAH does not take advantage of this new flexibility, then to 
meet the CEHRT definition for FY/CY 2012 and 2013, the EP, EH, or CAH 
will need to have EHR technology certified to all of the mandatory 2011 
Edition EHR certification criteria (or equivalent 2014 Edition EHR 
certification criteria) for either the ambulatory or inpatient setting, 
as applicable. Last, with respect to the potential CQM misalignment the 
commenter raised, we understand CMS is adopting a policy to accommodate 
EPs, EHs, and CAHs that choose to use only 2014 Edition CEHRT in FY/CY 
2013. For further explanation, we refer readers to CMS's final rule 
published elsewhere in this issue of the Federal Register.
    Consistent with EO 13563, this additional flexibility and the 
original flexibility we proposed in the revised CEHRT definition should 
create additional regulatory efficiencies for EPs, EHs, and CAHs. 
Accordingly, the CEHRT definition will be revised at Sec.  170.102 to 
reflect our proposal in the

[[Page 54260]]

Proposed Rule with the additional modification to the first part of the 
definition discussed above. Table 4 below provides a crosswalk between 
the 2011 Edition EHR certification criteria and the 2014 Edition EHR 
certification criteria that we consider equivalent for the purposes of 
revised CEHRT definition for any Federal FY or CY up to and including 
2013. Table 5 below provides a general overview of the revised CEHRT 
definition in relation to the stages of MU and the EHR reporting 
periods in FY/CY 2011 through 2014.

[[Page 54261]]

[GRAPHIC] [TIFF OMITTED] TR04SE12.000


[[Page 54262]]



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

    Comments. Some commenters expressed confusion about the impact of 
our proposed revised CEHRT definition on our ``possession'' policy.
    Response. In FAQs 9-10-017-2 \37\ and 12-10-021-1,\38\ we describe 
our ``possession'' policy. We consider ``possessing'' (or ``having'') 
Certified EHR Technology to include either the physical possession of 
medium on which a certified Complete EHR or combination of certified 
EHR Modules resides, or a legally enforceable right by an eligible 
health care provider to access and use, at its discretion, the 
capabilities a certified Complete EHR or combination of certified EHR 
Modules includes. An eligible health care provider may determine the 
extent to which it will implement or use these capabilities, which will 
not affect the provider's ``possession'' of Certified EHR Technology. 
In sum, prior to our revised CEHRT definition, an EP would need to 
possess EHR technology certified to all mandatory certification 
criteria for an ambulatory setting, and an EH or CAH would need to 
possess EHR technology certified to all mandatory certification 
criteria for an inpatient setting. As discussed above, this would still 
hold true for FY/CY 2012 and 2013, unless an EP, EH, or CAH chooses to 
use EHR technology that satisfies the FY/CY 2014 revised CEHRT 
definition for those years. As also noted in our discussion above, our 
revised CEHRT definition for FY/CY 2014 and subsequent years does limit 
the potential quantity of EHR technology EPs, EHs, and CAHs would need 
to ``possess'' to meet the CEHRT definition by requiring EPs, EHs, and 
CAHs to have only EHR technology that meets the Base EHR definition and 
would support the objectives and measures, and their ability to 
successfully submit the CQMs, for the MU stage that they seek to 
achieve.
---------------------------------------------------------------------------

    \37\ https://healthit.hhs.gov/portal/server.pt/community/onc_regulations_faqs/3163/faq_17/20779.
    \38\ https://healthit.hhs.gov/portal/server.pt/community/onc_regulations_faqs/3163/faq_21/21597.
---------------------------------------------------------------------------

    We reiterate that an EP, EH, or CAH must continue to possess all of 
a certified Complete EHR or certified EHR Module (i.e., the 
capabilities for which certification is required) in order to receive 
the benefit of such certification. An EP, EH, or CAH cannot purchase or 
possess only ``components'' of a certified Complete EHR or certified 
EHR Module for the purposes of meeting the CEHRT definition. That is, 
unless independently certified, those ``components'' could not be used 
to meet the CEHRT definition. We refer commenters to our discussion in 
section III.B.4 of this preamble for further discussion related to 
certifications issued to Complete EHRs and EHR Modules. Also, we seek 
to make clear that the possession policy does not apply to those 
capabilities that an EHR technology developer may include with those 
that constitute a certified Complete EHR or certified EHR Module but 
for which certification is not required. In those instances, because 
these other included capabilities are not required for certification, 
an EP, EH, or CAH, would not necessarily need to possess them if the 
EHR technology developer would separately sell them. For more on this 
point, we refer commenters to our ``EHR Technology Price Transparency'' 
discussion in section IV.F of this preamble.
2. Base EHR Definition
    In the Proposed Rule, we proposed to add to Sec.  170.102 a new 
defined term, ``Base EHR,'' which would essentially serve as a 
substitute for the term ``Qualified EHR'' in the definition of CEHRT. 
We stated that the Base EHR definition would reflect all of the 
capabilities specified in the Qualified EHR statutory definition (that 
is, in section 3000(13) of the PHSA) plus the additional capabilities 
we proposed. We stated our intention to use the term ``Qualified EHR'' 
only as necessary and that its use would refer to the statutory 
definition unless otherwise indicated. We stated that the term ``Base 
EHR'' is more intuitive and conveys a plain language meaning. Moreover, 
we noted that the term ``Qualified EHR'' does not inherently convey the 
kinds of capabilities it includes. The term ``Base EHR,'' though, 
conveys that EHR technology includes certain fundamental capabilities. 
We also noted that the terms ``qualified EHR'' and ``qualified EHR 
products'' have been used by CMS in other programs and with a different 
meaning. Therefore, we concluded that the term ``Base EHR'' would be 
more easily understood and readily accepted by stakeholders.
    We proposed that the Base EHR definition would include all the 
capabilities specified in the definition of a ``Qualified EHR'' under 
section 3000(13) of the PHSA. We also proposed that it would include an 
``extra'' privacy and security capacity beyond what the Qualified EHR 
statutory definition required. Last, for clarity, we expressly listed 
the certification criteria to which an EP, EH, or CAH would need to 
make sure they had EHR technology certified in order to meet the Base 
EHR definition.
    With respect to CQMs, we proposed that the Base EHR definition 
would include the certification criteria proposed at Sec.  
170.314(c)(1) and (2). We stated that 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 stated that we anticipate that EHR technology 
developers will design EHR technology to incorporate the data elements 
for, and calculate, those CQMs

[[Page 54263]]

they believe their EHR technology would need to include in order to 
support the providers to which they market their EHR technology. We 
acknowledged, however, that this approach could 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 
sought comments on whether we should require certification to a set 
number of CQMs as part of certification to Sec.  170.314(c)(2) and 
provided potential options for such as an approach.
    For one option, we stated that we could require EHR technology 
designed for the ambulatory setting 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 rule. For 
EHR technology designed for the inpatient setting, we stated that we 
could require that the EHR technology 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). Conversely, we noted 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 their customers, but 
nonetheless are necessary for the EHR technology to be certified.
    We also requested 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 Base EHR definition's proposed capacity to protect 
the confidentiality, integrity, and availability of health information 
stored and exchanged, we proposed that the certification criteria 
should apply equally to both the ambulatory and inpatient settings. We 
specifically requested public comment on whether there should be a 
distinction between the ambulatory and inpatient settings for EHR 
technology certification to the privacy and security certification 
criteria.
    Comments. Commenters expressed support for the Base EHR definition 
and how it serves as the foundation of the CEHRT definition. However, 
it was also evident from comments that many commenters misunderstood 
the proposed Base EHR concept. That is, they interpreted the Base EHR 
as a singular, independent type of EHR technology that could or would 
be separately certified.
    One commenter suggested adding a capacity to the Base EHR 
definition, including the ability to produce a health record for legal, 
business, and disclosure purposes. Other commenters suggested including 
additional certification criteria in the Base EHR definition, such as 
new certification criteria addressing nutrition, diet, and allergies, 
or proposed certification criteria such as family health history, 
electronic notes, and automated measure calculation. Conversely, other 
commenters suggested removing certification criteria from the Base EHR 
definition. One of these commenters suggested limiting the 
certification criteria included in the Base EHR definition to the 
minimum number of certification criteria that would still be consistent 
and compliant with the HITECH Act. Multiple commenters suggested not 
including certification criteria with capabilities that would not be 
needed by all EPs, EHs, and CAHs to attempt to achieve MU. These 
commenters contended that this would increase flexibility for EPs, EHs, 
and CAHs as well as prevent them from incurring unnecessary costs by 
being required to purchase unwanted and unwarranted EHR technology. 
More specifically, commenters suggested removing the ``vital signs'' 
certification criterion (Sec.  170.314(a)(4)), the ``drug-drug, drug-
allergy interaction check'' certification criterion (Sec.  
170.314(a)(2)), and the ``view, download, and transmit to 3rd party'' 
certification criterion (Sec.  170.314(e)(1)). Commenters did, however, 
express support for keeping the privacy and security certification 
criteria in the Base EHR definition.
    Commenters suggested that certification for privacy and security 
should be consistent across both ambulatory and inpatient settings. 
Commenters did, however, express confusion over how privacy and 
security certification criteria correlated with other certification 
criteria included in the Base EHR definition as well as other 
certification criteria in general. In particular, commenters asked 
whether the privacy and security capabilities needed to integrate with 
the capabilities included in the other certification criteria that are 
part of the Base EHR definition. If such integration is not required, 
commenters suggested that we consider requiring integration 
certification, particularly where the capabilities do not share a 
common security architecture. One commenter asked for confirmation as 
to whether EPs, EHs, and CAHs bear the responsibility for appropriately 
implementing the privacy and security capabilities included in the Base 
EHR definition, including with other capabilities of their CEHRT they 
use to attempt to achieve MU.
    Commenters expressed concern about the proposed CQM certification 
criteria included, or considered for inclusion, in the Base EHR 
definition. In response to our specific request for comment, many 
commenters strongly recommended that, as part of the Base EHR 
definition, we require certification to all CQMs by the setting the EHR 
technology is designed to meet. As an alternative approach, commenters 
suggested establishing a list of CQMs for certification by practice 
setting (e.g., cardiology, pediatrics, etc.) and that the list(s) be 
part of the Base EHR definition. One commenter suggested that the ``CQM 
reporting'' certification criterion (Sec.  170.314(c)(3)) be included 
in the Base EHR definition as a means of providing additional 
flexibility for those wishing to contain the measures within their 
local data warehouse infrastructure. Conversely, another commenter 
stated that not all EPs, EHs, and CAHs will need the CQM reporting 
capability and that it should not be a certification criterion that is 
part of the Base EHR definition.
    Response. We appreciate the support expressed for the Base EHR 
definition. First, we would like to make clear that the Base EHR 
definition must be satisfied in order to meet the CEHRT definition. 
Stated another way, EPs, EHs, and CAHs should treat the Base EHR 
definition like a checklist. In order to ultimately have EHR technology 
that meets the CEHRT definition, an EP, EH, or CAH must ensure that the 
EHR technology it has first meets the Base EHR definition. We also want 
to make clear that the Base EHR definition is not meant to convey our 
expectation that EHR technology must be separately certified as ``a 
Base EHR.'' Nor should it be interpreted to mean that EHR technology 
presented for certification must include all the certification criteria 
included in the Base EHR definition. Rather, similar to the revised 
CEHRT definition, the Base EHR definition can be satisfied through a 
number of ways: (1) A certified Complete EHR; (2) a single certified 
EHR Module; (3) a combination of separately certified EHR Modules; or 
(4) a combination of 1 through 3.
    As stated above and in the Proposed Rule, we believe that the Base 
EHR

[[Page 54264]]

definition should include the fundamental capabilities that any EP, EH, 
or CAH must have to demonstrate MU. Therefore, we are revising the 
proposed Base EHR definition to be more consistent with this approach.
    First, we agree with commenters that certain certification criteria 
should be removed from the Base EHR definition. In particular, we have 
removed the certification criteria for ``vital signs'' (Sec.  
170.314(a)(4)), ``drug-drug, drug-allergy interaction check'' (Sec.  
170.314(a)(2)), and ``view, download, and transmit to 3rd party'' 
(Sec.  170.314(e)(1)). The capabilities specified by these three 
certification criteria are not necessarily needed by all EPs, EHs, and 
CAHs to support their achievement of MU.
    Second, based on public comments, we have added one new 
certification criterion to the Base EHR definition. In response to our 
request for comments in the Proposed Rule and as discussed in section 
III.A.8 of this preamble, we received overwhelming feedback from EPs, 
EHs, and CAHs recommending that steps be taken to improve data 
portability. In response, we have adopted an initial data portability 
certification criterion and have included it in the Base EHR 
definition. We believe this initial data portability certification 
criterion directly aligns with the statutory capacity specified in the 
PHSA ``Qualified EHR'' definition ``to exchange electronic health 
information with, and integrate such information from other sources.'' 
We believe that by including this certification criterion in the Base 
EHR definition it will provide EPs, EHs, and CAHs with a mechanism to 
potentially expedite and enhance the migration of data from one EHR 
technology to another.
    As noted above, the capabilities to capture (Sec.  170.314(c)(1)) 
and calculate (Sec.  170.314(c)(2)) CQMs remain part of the Base EHR 
definition. The ability to capture information relevant to health care 
quality aligns with statutory requirements for the Base EHR definition 
and we believe the ability to calculate CQMs through EHR technology is 
a fundamental capability all EPs, EHs, and CAHs should have to support 
their achievement of MU and their own continuous quality improvement. 
We have also amended our proposed Base EHR definition to require 
certification to no fewer than the minimum number of CQMs that an EP, 
EH, or CAH must report under the EHR Incentive Programs beginning in 
FY/CY 2014. Additionally, in light of the fact that CMS identified for 
EPs a subset of CQMs as a ``recommended core,'' we are separately 
requiring that to meet the Base EHR definition EPs must have EHR 
technology that has been certified to Sec.  170.314(c)(1) and Sec.  
170.314(c)(2) for at least 6 CQMs from the ``recommended core.'' This 
final rule provision is meant to complement CMS' reporting 
requirements. We included this additional provision to support and 
highlight the ``recommended core'' CQMs prioritized by CMS. Further, we 
believe that by including this requirement in the Base EHR definition, 
EHR technology developers will seek to be certified to those 
``recommended core'' CQMs that are most relevant to their customer 
base. As a result, EPs will then have the ability to report on some 
portion of the ``recommended core'' CQMs in support of CMS' CQM policy 
priorities.
    In order for an EP to have EHR technology that meets the Base EHR 
definition, he or she would need to have EHR technology certified to 
Sec.  170.314(c)(1) and Sec.  170.314(c)(2) for no fewer than 9 CQMs 
that in total cover at least 3 domains and include at least 6 CQMs from 
the recommended ``core set'' for adult and pediatric populations as 
identified in the Stage 2 final rule published elsewhere in this issue 
of the Federal Register. In other words, of the minimum of 9 CQMs 
necessary to meet the Base EHR definition, at least 6 CQMs must be from 
the recommended core set identified by CMS, and altogether the 9 CQMs 
must cover at least 3 domains. In support of the Million Hearts \39\ 
initiative, we strongly urge EHR technology developers that serve 
customers for which NQF 0018 (Controlling High Blood Pressure) and NQF 
0028 (Preventive Care and Screening: Tobacco Use: Screening and 
Cessation Intervention) would be applicable to include these two CQMs 
as part of the 6 recommended core set CQMs selected for certification. 
These two CQMs support this HHS priority and will be broadly leveraged 
through many Federal quality measurement programs.
---------------------------------------------------------------------------

    \39\ https://millionhearts.hhs.gov/.
---------------------------------------------------------------------------

    Similarly, in order for an EH or CAH to have EHR technology that 
meets the Base EHR definition, it would need to have EHR technology 
certified to Sec.  170.314(c)(1) and Sec.  170.314(c)(2) for no fewer 
than 16 CQMs that cover at least 3 domains as identified in the Stage 2 
final rule published elsewhere in this issue of the Federal Register. 
Additionally, by setting this minimum requirement, EHR technology 
developers will now need to ensure that their EHR technology includes 
the appropriate amount of CQMs if they seek to market their EHR 
technology as meeting the Base EHR definition.
    We decline to establish a list of CQMs by practice specialty for 
certification. Considering the evolving nature of CQM specification and 
development, the applicability and availability of CQMs for different 
scopes of practice, and the varied customer bases of EHR technology 
developers, we believe that this option would be both infeasible and 
impractical at the present time. We also decline to include as part of 
the Base EHR definition, even for the inpatient setting, a requirement 
that EHR technology must be certified to all of the CQMs selected by 
CMS for the EHR Incentive Programs because of instances where this type 
of policy approach would require EPs (because of scope of practice) and 
EHs and CAHs (e.g., children's hospitals and hospitals without an 
emergency department) to have EHR technology certified for CQMs on 
which they would have no information relevant to health quality to 
report. We believe the policy we have established minimizes this type 
of situation from occurring. It also seeks to balance the potential 
burden faced by EHR technology developers to include and get their EHR 
technology certified to CQMs on which their customers would not 
necessarily have information relevant to health quality to report. We 
acknowledge that EHR technology developers get to choose the CQMs to 
which their EHR technology is certified and that those CQMs may not 
necessarily meet the needs of every EP, EH or CAH. We continue to 
believe, however, that EHR technology developers will be cognizant of 
their customers' needs and will in most cases select CQMs for 
certification that can broadly support their customer base. EPs, EHs, 
and CAHs can also consult the CMS MU Stage 2 final rule to determine 
whether the EHR technology they intend to purchase has the necessary 
CQM capabilities. Last, we have included in the Base EHR definition the 
capability to electronically submit CQMs as specified by the 
certification criterion at Sec.  170.314(c)(3). As noted under the 
discussion of CQM submission earlier in this preamble, EHR technology 
certified to Sec.  170.314(c)(3) is required to enable the electronic 
submission of CQM data to CMS according to adopted standards. We 
believe that this capability will be useful to all EPs, EHs, and CAHs 
because it is now structured to support the electronic submission of 
CQMs for MU or as applicable under PQRS. Accordingly, we believe that 
it is appropriate and beneficial to include

[[Page 54265]]

this capability and certification criterion in the Base EHR definition.
    Last, we decline to expand the Base EHR definition beyond those 
capabilities already proposed and the one addition we discuss above 
because requiring the additional capabilities and certification 
criteria suggested by some commenters would be inconsistent with our 
stated approach of only requiring in the Base EHR definition 
capabilities that are as universally applicable as possible.
    With these revisions to the proposed Base EHR definition, we now 
limit the definition to those certification criteria that most closely 
align with the capacities specified in the definition of a ``Qualified 
EHR'' under section 3000(13) of the PHSA and, as supported by 
commenters, improve data portability and protect the confidentiality, 
integrity and availability of patient health information. We see this 
as the most appropriate starting point from which to potentially expand 
(as necessary) the Base EHR definition in future rulemakings. 
Furthermore, this modified Base EHR definition gives EPs, EHs, and CAHs 
even more flexibility than we had proposed and could potentially 
further reduce CEHRT adoption costs.
    We agree with commenters that, as proposed, certification for 
privacy and security should be consistent across both ambulatory and 
inpatient settings. The privacy and security certification criteria 
included in the Base EHR definition are designed to provide EPs, EHs, 
and CAHs with basic technical capabilities that can support compliance 
with parts of the HIPAA Privacy and Security Rules. As we stated in the 
Proposed Rule, EPs, EHs, and CAHs are responsible for implementing 
their CEHRT in ways that meet applicable privacy and security 
requirements under Federal law (such as the HIPAA Privacy Rule and 
Security Rule and 42 CFR Part 2) and applicable state law. The Base EHR 
definition gives EPs, EHs, and CAHs the flexibility to implement and 
combine EHR technology capabilities (particularly those capabilities 
used for MU) in their healthcare environment in ways that they 
determine are the most functional (e.g., with various different 
certified EHR Modules), efficient, and cost effective.
    ``Integration certification'' is not currently part of the 
temporary certification program nor is it included in the ONC HIT 
Certification Program. We responded to similar comments in a prior 
rulemaking (76 FR 1273) that integration certification was impractical 
because of technical and logistical concerns (e.g., the integrated 
healthcare environment of a hospital) as well as financial costs (e.g., 
bringing certified EHR Modules from different EHR technology developers 
together for additional certification after being separately 
certified). For these reasons, we continue to believe that such 
certification should not be part of the ONC HIT Certification Program 
at this time, even for only privacy and security. We reiterate, 
however, our position stated in the Permanent Certification Program 
final rule (76 FR 1273) that nothing precludes an ONC-ACB or other 
entity from offering a service to certify EHR Module-to-EHR Module 
integration. To be clear, although we do not require or specifically 
preclude an ONC-ACB from certifying EHR Module-to-EHR Module 
integration, any EHR Module-to-EHR Module certification performed by an 
ONC-ACB or other entity will be done without specific authorization 
from the National Coordinator and will not be considered part of the 
ONC HIT Certification Program.
    The Base EHR definition is included at Sec.  170.102 and has been 
revised to remove the certification criteria referenced in the 
discussion above, to add in a minimum number of CQMs for the ambulatory 
and inpatient settings, and to add the certification criterion at Sec.  
170.314(c)(3). Table 6 below specifies the 2014 Edition EHR 
certification criteria included in the Base EHR definition and the Base 
EHR capacities they support. To note, as mentioned under section 
III.B.1 ``Revisions to the Definition of Certified EHR Technology,'' 
the Base EHR definition will now be one part of an optional means for 
meeting the definition of CEHRT for any FY or CY up to and including 
2013.

    Table 6--Certification Criteria Required To Satisfy the Base EHR
                               Definition
------------------------------------------------------------------------
          EHR technology that:                Certification criteria
------------------------------------------------------------------------
Includes patient demographic and         Demographics Sec.
 clinical health information, such as     170.314(a)(3).
 medical history and problem lists.      Problem List Sec.
                                          170.314(a)(5).
                                         Medication List Sec.
                                          170.314(a)(6).
                                         Medication Allergy List Sec.
                                          170.314(a)(7)
Has the capacity to provide clinical     Clinical Decision Support Sec.
 decision support.                         170.314(a)(8).
Has the capacity to support physician    Computerized Provider Order
 order entry.                             Entry Sec.   170.314(a)(1).
Has the capacity to capture and query    Clinical Quality Measures Sec.
 information relevant to health care       170.314(c)(1) through (3).
 quality.
Has the capacity to exchange electronic  Transitions of Care Sec.
 health information with, and integrate   170.314(b)(1) and (2) Data
 such information from other sources.     Portability Sec.
                                          170.314(b)(7).
Has the capacity to protect the          Privacy and Security Sec.
 confidentiality, integrity, and          170.314(d)(1) through (8).
 availability of health information
 stored and exchanged.
------------------------------------------------------------------------

3. Complete EHR Definition
    We stated in the Proposed Rule that we intended to maintain the 
concept of a Complete EHR and permit EHR technology developers to seek 
Complete EHR certifications for their EHR technology. We proposed, 
however, to revise the Complete EHR definition for clarity to 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.''
    Comments. We received a few comments expressing support for our 
proposed revised Complete EHR definition.
    Response. We are revising our approach to the Complete EHR 
definition based on modifications we have made to the Base EHR 
definition and to clarify the applicability of the revised CEHRT 
definition for any FY or CY up to and including 2013 to a Complete EHR. 
In our proposal, a Complete EHR would have inherently met the Base EHR 
definition because it would have required certification to all the 
certification criteria included in the proposed Base EHR definition. We 
have, however, modified the Base EHR definition to require that EHR 
technology be certified to a minimum

[[Page 54266]]

number of CQMs per the ambulatory or inpatient setting in order to meet 
the Base EHR definition, which will require certification to Sec.  
170.314(c)(1) and (2) for more than one CQM. To ensure that a Complete 
EHR encompasses the Base EHR definition, we are establishing two 
separate Complete EHR definitions, one for the 2011 Edition EHR 
certification criteria and one for the 2014 Edition EHR certification 
criteria. As stated in the Proposed Rule, for certification to the 2011 
Edition EHR certification criteria, a Complete EHR designed for an 
ambulatory setting must meet the mandatory certification criteria 
adopted at Sec. Sec.  170.302 and 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. For 
certification of a Complete EHR to the 2014 Edition EHR certification 
criteria, EHR technology must meet the Base EHR definition and all 
mandatory certification criteria for either the ambulatory or inpatient 
setting. Our addition of paragraph (d) to Sec.  170.300 and the use of 
``ambulatory setting only'' and ``inpatient setting only'' headings 
within Sec.  170.314 clarifies which certification criteria have 
general applicability (apply to both ambulatory and inpatient settings) 
or apply only to an inpatient setting or an ambulatory setting. 
Additionally, we have made a guidance document available on our Web 
site that clearly specifies the 2014 Edition EHR certification criteria 
that apply to a Complete EHR designed for the ambulatory setting and a 
Complete EHR designed for an inpatient setting.
    Our revised CEHRT definition for any FY or CY up to and including 
2013 states that a Complete EHR meets the definition if it ``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.'' We want to make clear that, although the 
``equivalency option'' permits EPs, EHs, and CAHs to use a combination 
of EHR technology certified to the 2011 Edition and 2014 Edition EHR 
certification criteria to meet the revised CEHRT definition, a 
certification cannot be issued for a Complete EHR based on a 
combination of 2011 Edition and 2014 Edition EHR certification 
criteria. This would be inconsistent with how we described a Complete 
EHR in the Proposed Rule and with our ``representation requirement'' 
for Complete EHRs and EHR Modules certified under the ONC HIT 
Certification Program at Sec.  170.523(k)(1)(i) (i.e., 2011 Edition or 
2014 Edition compliant). Further, we believe a Complete EHR certified 
to a combination of 2011 Edition and 2014 Edition EHR certification 
criteria would cause confusion for EPs, EHs, and CAHs, particularly 
when transitioning to meet the CEHRT definition for FY/CY 2014 and 
subsequent years, which only permits EPs, EHs, and CAHs to use of EHR 
technology certified to the 2014 Edition EHR certification criteria to 
meet the definition. Accordingly, we are replacing the Complete EHR 
definition at Sec.  170.102 with the 2011 Edition Complete EHR 
definition described above and adding the 2014 Edition Complete EHR 
definition also as described above.
4. Certifications Issued for Complete EHRs and EHR Modules
    We restated frequently asked question (FAQ) 9-10-005-1 \40\ and its 
supporting policy rationale in the Proposed Rule. FAQ 9-10-005-1 
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. We noted that 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.
---------------------------------------------------------------------------

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

    Comments. We received two comments that supported our policy and a 
comment that criticized it. The commenter that offered criticism stated 
that EHR technology developers have been inclined to only get their EHR 
technology certified as Complete EHRs and have not obtained 
certification for their EHR technologies in the form of EHR Modules 
that would best benefit EPs, EHs, and CAHs. The commenter stated that 
as a consequence, EPs, EHs, and CAHs must possess more EHR technology 
than they need or want from a particular EHR technology developer. The 
commenter further stated that the option of EHR technology self-
developer certification to address such situations was not a viable 
option because of the costs and complexity to pursue such an approach 
was too daunting for most EPs, EHs, and CAHs. The commenter suggested 
that as an alternative that we require that every Complete EHR 
presented for certification also be certified as individual EHR 
Modules.
    Response. After consideration of the comments received, we reaffirm 
our policy incorporated in FAQ 9-10-005-1. 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. As stated in the Proposed 
Rule, 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. Furthermore, 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, as 
we look forward towards the development and introduction of combined 
and/or workflow-based test procedures, 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.
    In regard to the commenter's specific suggestion that we require 
Complete EHR technology developers to have their Complete EHR also 
certified as EHR Modules, we reiterate that, in accordance with PHSA 
section 3001(c)(5), the act of seeking certification is voluntary. More 
importantly, in some cases it may not be practicable (from an EHR 
technology design and functionality perspective or financially or 
otherwise) for an EHR technology developer to seek separate 
certifications for its EHR technology (Complete EHR or EHR Module) as a 
more limited EHR Module or even in a manner that meets the needs of a 
particular EP, EH, or CAH. Further, we question whether such an 
approach could be equitably operationalized. There does not readily 
appear to be an objective, non-arbitrary and practical way to identify 
the make-up of each potentially smaller EHR Module that would need to 
be certified from a Complete EHR or large EHR Module. With these 
considerations in mind, we strongly encourage EHR technology developers 
to seek, where possible,

[[Page 54267]]

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. Additionally, from a practical perspective, we 
believe our more flexible CEHRT definition will spur EHR technology 
developers to move in this direction at a much more rapid pace.
5. Adaptations of Certified Complete EHRs or Certified EHR Modules
    We stated in the Proposed Rule 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 went on to say that 
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. As an 
example, we indicated that 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, we specified that 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 
noted 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 and security vulnerabilities into the certified Complete EHR or 
certified EHR Module. We further noted that, 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.
    Comments. Many commenters supported our approach to adaptations. 
Some commenters did not, however, support extending a Complete EHR's or 
EHR Module's certification to adaptations without further evaluation by 
ONC-ACBs. These commenters expressed concern about an adaptation's 
privacy and security capabilities, noting that such capabilities will 
be fundamentally different from device to device. Commenters also 
requested that we further clarify the term ``full and exact same 
capabilities.'' Some commenters suggested a strict interpretation of 
the term so that EPs, EHs, and CAHs could be confident that their 
adapted EHR technology performs and interoperates as seamlessly as the 
certified Complete EHR or certified EHR Module. Last, commenters 
inquired about how this process would be monitored. For example, 
commenters asked whether EHR technology developers needed to seek 
formal inclusion of adaptations in their original certification and/or 
attest that the adaptation has the ``exact same capabilities'' as the 
certified Complete EHR or certified EHR Module.
    Response. We are implementing our adaptation policy as explained in 
the Proposed Rule and supplemented by the additional guidance provided 
here in this final rule. As noted in the Proposed Rule, we believe 
adaptations can serve as innovative ways to facilitate efficient 
workflows and user interactions. While we believe our example recited 
above and in the Proposed Rule specifies what constitutes ``full and 
exact same capabilities,'' we provide the following as additional 
clarification. In order for a software application to be treated as an 
adaptation (and not as a unique, stand-alone EHR Module or Complete EHR 
for which a separate certification would be required) it must include 
the full and exact same capabilities required by the certification 
criteria to which the EHR technology it is serving as an adaptation of 
was certified. Stated another way, an adaptation cannot partially 
address the capabilities required by a certification criterion. To 
illustrate this simply, an adaptation of a certified Complete EHR would 
need to enable a user to record all of the demographics specified at 
Sec.  170.314(a)(3) and would not be in compliance with this policy if 
it only provided a user the ability to record a patient's race and 
ethnicity. Further, we acknowledge that adaptations will naturally 
require the certified Complete EHR or certified EHR Module's user 
interface and other design features to be changed in order to perform 
efficiently on mobile platforms. Again, our concern is that the 
capabilities included in the adaptation and available to a user are a 
one-for-one match with the capabilities that have been adapted from the 
certified Complete EHR or certified EHR Module. In other words, an 
adaptation may include less overall capabilities than the certified 
Complete EHR or certified EHR Module, but for those capabilities it 
does include they must be the full and exact same capabilities for 
which certification is required. For example, it would be acceptable 
for an adaptation to include the full and exact same capabilities 
specified by 3 of the 10 certification criteria to which an EHR Module 
was certified.
    We appreciate the concerns expressed by commenters related to 
privacy and security, but remind commenters of certification's 
limitations. Certification is not a substitute for, or guarantee of, 
compliance with the HIPAA Privacy and Security Rules. Certification is 
designed to provide EPs, EHs, and CAHs with basic technical 
capabilities that can support compliance with parts of the HIPAA 
Privacy and Security Rules. EPs, EHs, and CAHs remain responsible for 
implementing their CEHRT in ways that meet applicable privacy and 
security requirements under Federal law (such as the HIPAA Privacy Rule 
and Security Rule and 42 CFR Part 2) and applicable state law. We would 
expect that EHR technology developers would include the relevant 
privacy and security capabilities in their adaptations where 
appropriate. For example, we would expect that an adaptation designed 
to run on a mobile device would employ authentication, access control, 
and authorization capabilities consistent with those specified in the 
certification criterion adopted at Sec.  170.314(d)(1). Similarly, we 
could see scenarios where electronic health information used or 
processed by an adaptation could be protected in accordance with the 
``end-user device encryption'' certification criterion adopted at Sec.  
170.314(d)(7)(i). As noted above and in the Proposed Rule, an EP, EH, 
or CAH should take steps to ensure, perhaps through contractual 
assurances from the EHR technology developer that provides such 
adaptation, that privacy and security capabilities are implemented 
appropriately and that the adaptation does not introduce privacy and 
security vulnerabilities into the certified Complete EHR or certified 
EHR Module. An EP, EH, and CAH should also take independent steps, or 
again through contractual assurances from the EHR technology developer 
that provides such adaptation, to address any privacy and security 
vulnerabilities that may be introduced by the different medium(s) on 
which the adaptation runs.

[[Page 54268]]

    An adaptation would need to be based on an already certified 
Complete EHR or certified EHR Module in order to be treated as being 
part of the certification issued to these EHR technologies. In this 
regard, an EHR technology developer would not need to obtain an 
additional certification for an adaptation nor have to attest to the 
functionality, capabilities, or otherwise for an adaptation. We believe 
that contractual relationships with customers and compliance with 
certifications issued by ONC-ATCBs and ONC-ACBs should be sufficient 
measures to ensure the integrity of adaptations, while eliminating the 
burden and costs of certification and attestation on EHR technology 
vendors and their customers (EPs, EHs, and CAHs). EPs, EHs, and CAHs 
should take note that absent an EHR technology developer actively 
seeking a separate certification for an adaptation (which would not be 
required under our policy), the adaptation itself would not be 
independently listed on the CHPL because it is considered part of the 
certification of a previously certified Complete EHR or certified EHR 
Module. Thus, an EP, EH, and CAH would need to select as part of its 
attestation process the certified Complete EHR or certified EHR Module 
from which the adaptation was created. Last, we seek to make clear that 
an EHR technology developer can always seek certification for its 
adaptation. Certification of the adaptation would lead to its listing 
on the CHPL and would permit the EHR technology developer to openly 
sell the adaptation to all potential purchasers since it would be 
separately certified.

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

A. Program Name Change

    As explained in the Proposed Rule, 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). We noted in the Proposed Rule that we 
expected that the permanent certification program would replace the 
temporary certification program upon the effective date of this final 
rule. As we discussed, at that time, there would no longer be a need to 
continue to differentiate between the certification programs based on 
their expected duration. Therefore, we proposed to replace all 
references in Part 170 of the Code of Federal Regulations to the 
permanent certification program with ``ONC HIT Certification Program.''
    Comments. A few comments expressed agreement with our proposal to 
change the program name. A commenter noted that having two names was 
somewhat confusing and that shifting to one name would be desirable.
    Response. We thank these commenters for their support and have 
finalized our proposal. We are revising subpart E of Part 170, Title 
45, Subtitle A, Subchapter D of the Code of Federal Regulations to 
replace all references 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 future HIT certification activities. We also note that, as 
we indicated in the Proposed Rule and in our notice published in the 
Federal Register on November 3, 2011 (76 FR 68192), the temporary 
certification program will officially sunset upon the effective date of 
this final rule and will be replaced with the ONC HIT Certification 
Program. When the temporary certification program sunsets, ONC-
Authorized Testing and Certification Bodies (ONC-ATCBs) will be 
prohibited from accepting new requests to test and certify EHR 
technology and will be permitted up to six months after the sunset date 
to complete all testing and certification activities associated with 
requests received prior to the sunset date. If these activities are not 
completed within the 6-month period, the EHR technology would have to 
be resubmitted for testing and certification under the ONC HIT 
Certification Program.

B. ``Minimum Standards'' Code Sets

    In the Proposed Rule, we described the current process for the 
Secretary to identify and accept newer versions of ``minimum 
standards'' code sets. Section 170.555 allows 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 of EHR technology. We explained that, based on our 
experience, newer versions of the ``minimum standards'' code sets that 
we have adopted are issued more frequently than our current process can 
reasonably accommodate. We also stated, based on the ``minimum 
standards'' code sets we have previously adopted and the ones proposed, 
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. Therefore, we proposed to revise Sec.  170.555 such that, 
unless the Secretary prohibits the use of a newer version of a 
``minimum standards'' 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. In consideration of this proposed new approach, we clarified 
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 outlined a process for determining when to prohibit the use of a 
newer version of a ``minimum standards'' code set that was similar to 
the process we used for accepting newer versions of ``minimum 
standards'' code sets. 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 indicated our 
expectation 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 stated that we would issue guidance indicating that the 
newer version of the adopted ``minimum standards'' 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 specified that, 
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 
standards'' code set. Instances could arise where the use of a newer 
version of a ``minimum standards'' code set may have an immediate 
negative effect on

[[Page 54269]]

interoperability, cause an obvious unintended consequence, or pose an 
undue burden on the HIT industry. Therefore, under such circumstances, 
we specified that the Secretary may choose to prohibit the use of a 
newer version of a ``minimum standards'' code set for purposes of 
certification and upgrading certified EHR technology without seeking a 
recommendation from the HITSC in advance.
    To provide additional clarity and consistency, we proposed 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.''
    Comments. Most commenters supported our proposal to revise the 
process for permitting the use of new versions of ``minimum standards'' 
code sets. Several commenters commended our proposed approach and 
indicated it would reduce regulatory complexity and burden by providing 
the industry with the flexibility to quickly utilize newer versions of 
adopted ``minimum standards'' code sets. A few of the commenters that 
agreed also expressed concern that it may be difficult for EPs, EHs, 
and CAHs to reconcile different code set releases if one EHR technology 
developer rolls them out faster than another. A few other commenters 
recommended that we should require backward compatibility as a 
condition for Secretary acceptance of newer versions of code sets. 
These commenters stated this would serve as a means of mitigating the 
challenges associated with different code set releases. A couple of 
commenters also recommended that providing technical support for 
previous versions should be a condition of certification of EHR 
technology to newer versions of ``minimum standards'' code sets. One 
commenter specifically suggested that support for the previous version 
be offered for at least 12 to 18 months unless otherwise abandoned due 
to extenuating circumstances (e.g., security or patient safety 
concerns). One commenter suggested that when a newer version release is 
available and accepted by the Secretary (with or without a 
recommendation from the HITSC) that there be a period of 180 days when 
vendors may test to either the previous or newer versions of the 
standard. Another commenter recommended that a regular and rational 
strategy be established to refresh the ``minimum standards'' called for 
in MU.
    Response. We appreciate the comments submitted in support of our 
proposal and are revising Sec.  170.555 such that, unless the Secretary 
prohibits the use of a newer version of a ``minimum standards'' 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 certified EHR Module without 
adversely affecting the EHR technology's certified status. We believe 
this approach reduces regulatory complexity and provides the industry 
with the flexibility to utilize newer versions of adopted ``minimum 
standards'' code sets without regulatory interference. We are also 
finalizing our proposal to make the minor text changes to Sec.  
170.555, as well as the process we outlined in the Proposed Rule for 
determining when to prohibit the use of a newer version of a ``minimum 
standards'' code set and the exception to that process.
    With respect to the comments regarding the additional condition of 
certification for technical support, timing for when new versions of 
the code sets are released, and a schedule to refresh the ``minimum 
standards'' that would be required as part of MU, we believe that these 
commenters may have misinterpreted the flexibility and approach offered 
by our proposal and the way in which newer versions of ``minimum 
standards'' code sets would be treated by the final rule. Therefore, we 
offer this additional explanation. In general, we understand that the 
code sets we have identified as ``minimum standards'' code sets are 
frequently updated to keep pace with industry needs. For example, when 
a new medication becomes available, a new code for that medication 
would be added to the next release of RxNorm. As finalized, our 
revision to Sec.  170.555 permits an EHR technology developer to, for 
example, immediately include that newer version of RxNorm when 
presenting its Complete EHR or EHR Module for certification rather than 
having to use the older version adopted in the Code of Federal 
Regulations in order to get certified. As we explained, inclusion of 
the newer version would be voluntary, and the developer would still 
have the option for its EHR technology to be certified to the version 
specified in regulation. It also permits certified Complete EHRs and 
certified EHR Modules to be voluntarily upgraded to these newer 
versions without adversely affecting the EHR technology's certified 
status. With respect to comments about EPs, EHs, and CAHs reconciling 
different releases and requiring backwards compatibility, we do not 
believe that these are acute concerns with respect to the code sets we 
have designated as ``minimum standards'' code sets because newer 
releases should subsume or include the codes that were in a prior 
version (subject to the natural retirement/deprecation of no longer 
useful codes). As stated in the Proposed Rule, based on the ``minimum 
standards'' code sets we have previously adopted and proposed, 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. In limited circumstances where the use of 
newer versions of a ``minimum standards'' code set may have an 
immediate negative effect, we can use the process we described above 
for the Secretary to prohibit the use of a newer version of a ``minimum 
standards'' code set for purposes of certification and upgrading 
certified Complete EHRs and certified EHR Modules. Accordingly, we do 
not believe that it is necessary to establish a backwards compatibility 
condition for ``minimum standards'' code sets as suggested. Further, we 
believe that the process we have in place for prohibiting the use of 
newer versions will mitigate any potential adverse affect for EPs, EHs, 
or CAHs should a major change to an adopted minimum standard occur. 
With respect to the comment about the refresh cycles for ``minimum 
standards'' code sets, we intend to make such updates as part of the 
normal rulemaking cycle that we engage in to adopt new certification 
criteria editions. Thus, we expect that regulatory updates to newer 
versions of ``minimum standards'' code sets will be on predictable 
schedule.

C. Revisions to EHR Module Certification Requirements

1. Privacy and Security Certification
    In the Proposed Rule, we proposed that EPs, EHs, and CAHs must have 
EHR technology that meets the proposed Base EHR definition. The 
proposed Base EHR definition referenced all of the proposed privacy and 
security certification criteria at Sec.  170.314(d) except the optional 
``accounting of disclosure'' certification criterion at Sec.  
170.314(d)(9). Based on the policy expressed by the proposed Base EHR 
definition and stakeholder feedback received since the S&CC July 2010 
final rule, we proposed to eliminate the current privacy and security 
certification requirements in Sec.  170.550(e) for EHR Modules starting

[[Page 54270]]

with the 2014 Edition EHR certification criteria.
    Comments. Several commenters supported our proposed revisions to 
EHR Module certification and expressed agreement that it would reduce 
regulatory burden and enable greater flexibility. A few commenters 
disagreed with our position and contended that we should continue our 
existing approach to the privacy and security certification of EHR 
Modules as specified in Sec.  170.550(e) with the 2014 Edition EHR 
certification criteria. A couple of commenters expressed concern that 
our approach could lead to certain negative effects if, as a result of 
this proposed change, the EHR technology certified and used by an EP, 
EH, or CAH to satisfy the Base EHR definition could not be configured 
to also apply those privacy and security capabilities to other 
separately certified EHR Modules an EP, EH, or CAH may choose to 
implement. Along those lines, some commenters requested greater clarity 
regarding our proposed EHR Module certification change and how it 
interacts with the Base EHR definition. One commenter suggested that if 
ONC finalizes this proposal that we should evaluate its effect to 
determine if additional requirements would subsequently be necessary. 
Another commenter recommended that remote components providing services 
to a Complete EHR or EHR Module should be secured with Transport Layer 
Security (TLS) and should not be required to be separately certified to 
the privacy and security requirements.
    Response. In consideration of comments received, we are revising 
Sec.  170.550(e) as proposed. Upon this final rule's effective date, 
EHR Modules presented for certification to the 2014 Edition EHR 
certification criteria will not be required to be certified to the 
privacy and security certification criteria adopted at Sec.  
170.314(d). We continue to believe, as echoed by many commenters, that 
our proposed change would reduce regulatory burden on EHR technology 
developers and the potential for EPs, EHs, and CAHs to purchase EHR 
Modules that have redundant or conflicting privacy and security 
capabilities.
    With respect to the concern identified by some commenters, we 
reiterate what we stated in the Proposed Rule. EPs, EHs, and CAHs 
ultimately 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). Certification is in no way a 
substitute or proxy for compliance with these legal requirements. Per 
the commenters' scenario and the other request for greater 
clarification on the Base EHR definition, we acknowledge it could be 
possible for an EP, EH, or CAH to adopt, for example, a certified EHR 
Module (certified EHR Module 1) that satisfies the Base EHR 
definition as well as other certified EHR Modules, and that those other 
certified EHR Modules might not be able to utilize or leverage the 
privacy and security capabilities included in certified EHR Module 
1. Therefore, we strongly encourage EPs, EHs, and CAHs 
(presumably as they would with any other EHR technology necessary to 
meet MU or not) to carefully evaluate as part of their ongoing risk 
analysis processes whether the implementation of an additional separate 
certified EHR Module could pose new risks to privacy and security. As 
suggested by these commenters, we intend to monitor the effects of 
these changes to determine whether alternative requirements would be 
necessary as part of future rulemaking. For a more detailed discussion 
of the Base EHR definition, its requirements and relationship to CEHRT 
and certified EHR Modules, and our response to comments, we refer 
readers to section III.B.2 of this final rule. Finally, with respect to 
the commenter's two-part recommendation related to remote components 
providing services to a certified Complete EHR or certified EHR Module, 
we find the commenter's scenario and limited description of a ``remote 
component'' too ambiguous to issue a definitive response. In the 
Proposed Rule, we proposed that EHR technology presented for 
certification as an EHR Module would no longer need to be separately 
certified to the adopted privacy and security criteria--a proposal we 
have finalized. In general, we agree that TLS could be an appropriate 
standard in this situation, but, again, do not believe that the 
commenter provided sufficient detail on which to respond.
2. Certification to Certain New Certification Criteria
    We proposed to revise Sec.  170.550 to ensure certification of EHR 
Modules to the following 2014 Edition EHR certification criteria, as 
applicable: (1) Electronic recording of the numerator for each MU 
objective with a percentage-based measure (Sec.  170.314(g)(1) 
``automated numerator recording''); (2) electronic recording of 
activities related to non-percentage-based measures (Sec.  
170.314(g)(3) ``non-percentage-based measure use report''); and (3) 
user-centered design processes to be applied to EHR technology that 
includes certain capabilities (Sec.  170.314(g)(4) ``safety-enhanced 
design''). More specifically, we proposed to revise Sec.  170.550 to 
ensure that EHR Modules that are presented for certification to 
certification criteria that include capabilities for supporting a MU 
objective with a percentage-based measure are certified to Sec.  
170.314(g)(1). However, we also proposed 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 proposed 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 non-
percentage-based measure are certified to Sec.  170.314(g)(3). Last, we 
proposed to revise Sec.  170.550 to ensure that EHR Modules that are 
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 proposed to include these revisions at Sec.  
170.550(f).
    Comments. We received a few comments expressing support for 
requiring certification to these certification criteria.
    Response. We appreciate the support expressed by commenters and are 
finalizing our proposals to have ONC-ACBs ensure EHR Modules are 
certified to these certification criteria, except for our proposal 
concerning the ``non-percentage-based measure use report'' 
certification criterion at Sec.  170.314(g)(3). As discussed earlier in 
this preamble, we are not finalizing the proposed ``non-percentage-
based measure use report'' certification criterion as part of the 2014 
Edition EHR certification criteria. Therefore, ONC-ACBs would not need 
to ensure that EHR Modules were certified to the certification 
criterion. We also note that, because we are not finalizing the 
proposed ``non-percentage-based measure use report'' certification 
criterion, we have re-designated the ``safety-enhanced design'' 
certification criterion to Sec.  170.314(g)(3).
    After consideration of comments received on our proposal to adopt a 
certification criterion related to quality management processes for EHR 
technology, we have adopted a ``quality management system'' 
certification criterion at Sec.  170.314(g)(4). This certification 
criterion applies to all EHR technology certified to the 2014 Edition 
EHR certification criteria. Therefore, to ensure ONC-ACBs certify all 
EHR Modules presented for certification to the 2014 Edition EHR 
certification

[[Page 54271]]

criteria to this new certification criterion, we have revised Sec.  
170.550(f) to require that EHR Modules are certified to Sec.  
170.314(g)(4).

D. ONC-ACB Reporting Requirements

    We proposed to revise Sec.  170.523(f) to require ONC-ACBs to 
include an additional data element in the data set they must provide to 
ONC for the Complete EHRs and/or EHR Modules they certify. 
Specifically, we proposed that an ONC-ACB would need to provide ONC a 
hyperlink for each 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 ONC-ACBs are 
required to report to ONC about certified Complete EHRs and certified 
EHR Modules, we proposed to make the hyperlink available on the CHPL 
with the respective certified Complete EHR or certified EHR Module. As 
noted in the Proposed Rule, 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, we stated 
that the ONC-ACB would no longer need to ensure the functionality of 
the hyperlink, although retention of the test results would be 
required.
    Comments. Many commenters supported our proposal. Some commenters, 
however, opposed publicly posting test results. Commenters that 
supported our proposal stated that publicly posting the test results 
would improve transparency. Some of these same commenters also 
indicated that the public availability of test results would empower 
customers. Specifically, they stated that customers could review and 
compare the test results against expected performance as a way to 
troubleshoot any implementation challenges posed by a certified 
Complete EHR or certified EHR Module. Conversely, commenters that 
expressed opposition to publicly posting test results stated that doing 
so could compromise EHR technology developers' intellectual property 
rights. These commenters expressed concern about the publication of 
source code as well as the publication of copyrighted materials that 
may be present in testing screenshots. A few commenters also argued 
that there was little value in publicly posting test results because 
the true value for consumers was in knowing whether the EHR technology 
was certified. As alternatives to, or rationale against, publicly 
posting test results, commenters suggested that test results could be 
obtained by consumers (e.g., EPs, EHs, and CAHs) during purchase 
negotiations and that ONC could post information about the testing and 
certification processes in lieu of posting test results. Commenters 
also noted that a standardized format for test results does not 
currently exist under the temporary certification program and suggested 
that such a format was necessary for testing results to be equitably 
treated and for any analysis or comparison of test results.
    Response. We have considered the comments received on this 
proposal. We strongly believe that transparency should be an integral 
component of the ONC HIT Certification Program. Transparency can 
provide for additional access to and scrutiny of the ONC HIT 
Certification Program as well as improve program performance and 
increase public confidence in the EHR technology certified under the 
program.
    We believe that an appropriate balance can be struck that supports 
transparency, protects EHR technology developers' potential 
intellectual property rights, and provides testing results in a 
consistent and identifiable manner. We have finalized our proposal and 
will require that ONC-ACBs submit a hyperlink of the test results used 
to issue a certification to a Complete EHR or EHR Module, which can be 
accessed by the public. In light of the concern expressed by some 
commenters, we intend to provide guidance to ONC-ACBs regarding the 
test results information that should be excluded from the publicly 
accessible hyperlink they submit to ONC. As an example, we expect ONC-
ACBs would exclude from the publicly available hyperlink any 
screenshots produced as part of the testing process. Although we do not 
anticipate that source code would be visible in a test result report, 
if it is visible, we expect ONC-ACBs would exclude it from the 
information made available through the hyperlink. We would also expect 
any negative test results to be excluded from publicly posted test 
results because only passed test results would be necessary for 
obtaining certification of a Complete EHR or EHR Module from an ONC-
ACB. We believe this should mitigate the concerns identified by 
commenters, and we will provide additional guidance to ONC-ACBs in the 
future if other unique circumstances not discussed here arise. We also 
intend, as suggested by commenters, to work closely with NVLAP to 
develop a standardized format for test results that can be used by all 
accredited testing laboratories and submitted to any ONC-ACB to be used 
for certification.

E. Continuation and Representation of Certified Status

1. 2011 or 2014 Edition EHR Certification Criteria Compliant
    To align with our proposal to designate the certification criteria 
adopted in Sec. Sec.  170.302, 170.304, and 170.306 collectively as the 
``2011 Edition EHR certification criteria'' and to designate the 
certification criteria proposed in the Proposed Rule at Sec.  170.314 
as the ``2014 Edition EHR certification criteria,'' we proposed to 
revise Sec.  170.523(k). The proposed revision to Sec.  170.523(k) 
would require ONC-ACBs to ensure as part of certification that a 
developer of a Complete EHR or EHR Module would indicate in all 
marketing materials, communications, statements, and other assertions 
the certification criteria edition to which it had been certified 
rather than the compliance years the certification issued to the 
Complete EHR or EHR Module represented. We proposed that this revision 
would apply to all certifications issued after the effective date of 
this final rule.
    As noted in the Proposed Rule, we considered multiple options to 
address certified Complete EHRs and certified EHR Modules already 
designated as ``2011/2012'' compliant and concluded that the best 
approach was to not require any changes to the ``2011/2012'' 
designation. Rather, we stated that 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 requested public comment on this 
approach and any other approach that would present the least burden for 
EHR technology developers and the least confusion for the market.
    We also proposed to revise Sec.  170.523(k)(1)(i) by removing the 
following statement: ``* * * 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.
    Comments. Commenters supported the concept of ``editions'' of 
certification criteria and stated that identifying EHR technology's 
compliance with editions of certification criteria would be less 
confusing than using multiple years as a means of identifying an EHR 
technology's certified status and validity.
    Response. We thank the commenters for their support and are 
revising

[[Page 54272]]

Sec.  170.523(k) as proposed. When an ONC-ACB issues a certification it 
must require that the EHR technology developer include on its Web 
site(s) and in all marketing materials, communications, statements, and 
other assertions, the certification criteria edition to which the 
Complete EHR or EHR Module was certified. This revision applies to all 
certifications issued after the effective date of this final rule and 
means that EHR technology certified to the 2011 Edition EHR 
certification criteria will be designated as ``2011 Edition EHR 
certification criteria compliant'' and EHR technology certified to the 
2014 Edition EHR certification criteria will be designated as ``2014 
Edition EHR certification criteria compliant.'' We believe this 
revision will assist in eliminating confusion about the ``expiration'' 
of certifications, align with our revised definition of CEHRT, and 
provide the market with greater clarity regarding the capabilities 
certified Complete EHRs and certified EHR Modules include. As stated 
above and in the Proposed Rule, EHR technology that has already been 
designated as ``2011/2012 compliant'' does not need to be re-designated 
as ``2011 Edition EHR certification criteria complaint.'' Finally, 
consistent with our proposal, we are removing the statement: ``* * * or 
guarantee the receipt of incentive payments'' from Sec.  
170.523(k)(1)(i) to prevent confusion about the parameters of the EHR 
Incentive Programs.
2. Updating a Certification
    To ensure that the information required by Sec.  170.523(k)(1)(i) 
remains accurate and reflects the correct EHR certification criteria 
edition, 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 in the Proposed Rule to no longer 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 proposed to revise the definition of ``providing or 
provide an updated certification'' at Sec.  170.502. The proposed 
revised definition would eliminate the requirement that ONC-ACBs must 
verify whether any new privacy and security certification criteria 
apply when they issue an updated certification to an EHR Module.
    We also noted in the Proposed Rule that 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 stated that we can provide 
the best guidance to stakeholders on when ``updating'' a certification 
would be permitted with each rulemaking for a certification criteria 
edition. For the 2014 Edition EHR certification criteria, we stated 
that if we were to adopt in a final rule the proposed certification 
criteria at Sec.  170.314(g)(1) (automated numerator recording) and 
Sec.  170.314(g)(3) (non-percentage-based measure use report), then no 
previously certified EHR Module could have its certification 
``updated'' to the 2014 Edition EHR certification criteria because it 
would need to be certified to one of the above certification criteria 
(with the option of an EHR Module being certified to Sec.  
170.314(g)(2) in lieu of being certified to Sec.  170.314(g)(1)).
    Comments. We received no comments on this proposal.
    Response. We are finalizing the proposed revisions to the 
definition ``providing or provide an updated certification'' at Sec.  
170.502. We also specify that ``updating'' an EHR Module's 
certification to the 2014 Edition EHR certification criteria will not 
be available. As noted previously in this preamble, we have adopted a 
``quality management system'' certification criterion (Sec.  
170.314(g)(4)) that applies to all EHR technology certified to the 2014 
Edition EHR certification criteria. Therefore, when certifying EHR 
Modules to the 2014 Edition EHR certification criteria, ONC-ACBs must 
certify EHR Modules to this new certification criterion. Additionally, 
we have finalized the proposed new certification criteria ``automated 
numerator recording'' (Sec.  170.314(g)(1)) and ``safety-enhanced 
design'' (now designated as Sec.  170.314(g)(3)). ONC-ACBs must also 
ensure that EHR Modules presented for certification to the 2014 Edition 
EHR certification criteria are, as applicable, certified to these new 
certification criteria. Consequently, an ONC-ACB may not issue 
``updated'' certifications to previously certified EHR Modules for the 
2014 Edition EHR certification criteria. As we noted in the Proposed 
Rule, ``updating'' a certification may still be a viable option under 
certain conditions when the Secretary adopts another edition of 
certification criteria in the future.
3. Representation of Meeting the Base EHR Definition
    With respect to the Base EHR definition, we explained in the 
Proposed Rule that EPs, EHs, and CAHs would benefit from knowing which 
certified EHR technologies on the market meet the Base EHR definition 
because they would need to have EHR technology that meets the Base EHR 
definition to satisfy the proposed revised definition of CEHRT 
beginning with FY/CY 2014. We stated that it was unnecessary to 
expressly propose a requirement for ONC-ACBs to identify EHR technology 
that meets the Base EHR definition because EHR technology developers, 
in order to gain a competitive advantage in the market, would likely 
identify on their Web sites and in marketing materials, communications, 
statements, and other assertions whether their certified Complete EHR 
or certified EHR Module(s) also met the Base EHR definition (designed 
for either the ambulatory or inpatient setting). We did, however, 
consider (as a potential alternative and complementary approach) 
permitting ONC-ACBs when issuing certifications to Complete EHRs and 
EHR Modules that meet the Base EHR definition 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 Base EHR definition. We 
requested public comment our approach and whether there was any other 
potential approach that we had not identified.
    Comments. Many commenters supported the Base EHR concept and 
suggested that EHR technologies meeting the Base EHR definition should 
be listed as such, and searchable, on the Certified HIT Products List 
(CHPL). Commenters stated that specifically listing EHR technologies 
that meet the Base EHR definition on the CHPL would provide the most 
purchasing clarity for EPs, EHs, and CAHs. Some commenters also stated 
that leaving it up to the EHR technology developers to identify whether 
their EHR technologies met the Base EHR definition could be misleading 
to purchasers.
    Response. We believe, as indicated in the Proposed Rule, that EHR 
technology

[[Page 54273]]

developers will be able to identify on their Web sites and in marketing 
materials, communications, statements, and other assertions whether 
their certified Complete EHR or certified EHR Module(s) meet the Base 
EHR definition (designed for either the ambulatory or inpatient 
setting). This will enable EHR technology developers to market the 
post-certification combination of multiple certified EHR Modules as 
meeting the Base EHR definition. We believe this is the best way to 
address situations where an EHR technology developer has EHR Modules 
certified at different times, but those EHR Modules together meet the 
Base EHR definition. This approach will also permit multiple affiliated 
EHR technology developers to market the post-certification combination 
of their certified EHR Modules if together they meet the Base EHR 
definition.
    We do not believe that purchasers should be concerned about 
misleading practices related to the identification of certified 
Complete EHRs and certified EHR Modules as meeting the Base EHR 
definition. First, a certified Complete EHR by definition meets the 
Base EHR definition. Second, ONC-ACBs oversee the certifications they 
issue to Complete EHRs and EHR Modules. When ONC-ACBs are accredited, 
their conformance to ISO/IEC Guide 65:1996 (Guide 65) is verified. 
Section 14.3 of Guide 65 states that ``incorrect references to the 
certification system or misleading use of licenses, certificates or 
marks, found in advertisement, catalogues, etc., shall be dealt with by 
suitable action.'' Based on this provision, we are confident that any 
misleading practices by EHR technology developers as they relate to 
their certified EHR Modules will be dealt with appropriately by ONC-
ACBs.
    We understand the commenters' desire to have EHR technology listed 
on the CHPL designated as whether it meets the Base EHR definition. We 
believe, however, that it would be impractical and administratively 
burdensome to prospectively list or designate all EHR technologies that 
could be combined post-certification to meet the Base EHR definition. 
Rather, a more efficient and less burdensome approach will be to enable 
the CHPL Web site to identify whether EHR technologies selected from 
the CHPL meet the Base EHR definition. For example, if an EP, EH, or 
CAH selected on the CHPL EHR technology developer A's certified EHR 
Module and EHR technology developer B's certified EHR Module, we expect 
that the CHPL would be able to identify whether the certified EHR 
Modules together meet the Base EHR definition (i.e., have been 
certified to all of the certification criteria specified in the Base 
EHR definition and the requisite number of CQMs). This approach would 
permit EPs, EHs, and CAHs to determine whether they have EHR technology 
that meets the Base EHR definition and also limits inefficiencies and 
burdens associated with EHR technology developers having ONC-ACBs 
verify that their EHR technologies meet the Base EHR definition 
(potentially post certification), reporting this information to the 
CHPL, and/or having the CHPL attempt to prospectively identify all EHR 
technologies (and combinations) that meet the Base EHR definition.

F. EHR Technology Price Transparency

    In response to stakeholder feedback, the Proposed Rule described 
our belief that the EHR technology marketplace could benefit from price 
transparency associated with certified Complete EHRs and certified EHR 
Modules. We further stated that price transparency could be achieved by 
requiring ONC-ACBs to ensure that EHR technology developers include 
clear pricing of the full cost to purchasers 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. In other 
words, ONC-ACBs could require EHR technology developers to disclose a 
purchaser's full cost (a single price) for all of the capabilities for 
which certification was required and that were included in a certified 
Complete EHR or certified EHR Module. We noted in the Proposed Rule, 
however, that in no way would this requirement dictate the price an EHR 
technology developer could assign to its EHR technology. We requested 
comment on the feasibility and value of price transparency for 
certified Complete EHRs and certified EHR Modules in the manner 
described.
    Comments. EHR technology developers and organizations representing 
EHR technology developers opposed this proposal. Providers and provider 
organizations supported the concept of price transparency, but not 
necessarily as proposed. Commenters questioned our proposed form of 
price transparency and stated that its anticipated value to purchasers 
was unclear because of the complexity and multiple costs associated 
with purchasing EHR technology. Alternatively, commenters stated that 
knowing a certified Complete EHR or certified EHR Module's ``total cost 
of ownership'' would be more valuable than just the price associated 
with the capabilities that the certification assigned to a Complete EHR 
or EHR Module represented. For commenters, total ownership costs 
included: Implementation costs (e.g., local implementation, 
subscription to an ASP, or web-based service); customization/
configuration (e.g., configurations of interfaces); training; and 
maintenance. Commenters also suggested that price transparency should 
mean that, in a multiple EHR technology developer scenario, the amount 
paid to each EHR technology developer would be identified. Other 
commenters noted that our proposed price transparency approach added 
little benefit because EHR technology developers could offer a low 
initial cost for the acquisition of a certified Complete EHR or 
certified EHR Module and then charge additional costs for other 
essential components of total ownership, such as implementation. 
Commenters also pointed out that a single price could give a false 
impression of equality. They cited, for example, that two certified 
Complete EHRs may have the same price, but offer substantially 
different capabilities and services in addition to those capabilities 
for which certification is required.
    Commenters stated that our proposal could hinder innovation and 
flexibility in product development, pricing, and market strategies. 
Some commenters stated, for example, that many products are not sold or 
licensed with only the capabilities for which certification is required 
and that our proposal could negatively alter current practices by 
confusing customers familiar with customary pricing and purchasing 
practices. A few commenters were also concerned about the proposal's 
impact on confidential, competitive and, some thought, proprietary 
marketing strategies. These commenters also noted that they were 
unaware of any other industry with the type of pricing dimensions and 
complexities as the HIT market and in which the Federal government 
required prices to be publicly available.
    Commenters stated that it would be burdensome to include prices on 
all materials as proposed, particularly if prices change. A few EHR 
technology self-developers requested that we exempt them from the price 
transparency proposal because they would not be selling their certified 
Complete EHR or certified EHR Module on the open market. Commenters 
noted that Regional Extension Centers have taken extensive steps to 
identify the true cost of EHR technologies inclusive of software (in-
house vs. hosted), services, training, maintenance, and other factors

[[Page 54274]]

in an effort to help their constituents properly compare certified 
Complete EHRs and certified EHR Modules. Last, commenters sought 
clarification regarding how EHR technology developers would be held 
accountable to this requirement (i.e., what would be the consequences 
for EHR technology developers).
    Response. We appreciate the variety and specificity of comments 
issued in response to this proposal. For the reasons stated in the 
Proposed Rule as well as those raised by commenters in favor of this 
proposal, we continue to believe that there is value in requiring ONC-
ACBs to ensure that EHR technology developers are transparent about the 
costs associated with certified Complete EHRs and certified EHR 
Modules. Further, we believe that such transparency can provide greater 
purchasing clarity for EPs, EHs, and CAHs. In considering that almost 
all commenters found fault with our proposal to list a purchaser's full 
cost or single price for a certified Complete EHR or certified EHR 
Module (for the various reasons identified in the comments above), we 
have finalized a modified approach based on those same comments and 
their suggestions for what would be helpful. This modified approach 
focuses on an EHR technology developer's responsibility to notify EPs, 
EHs, and CAHs about additional types of costs (i.e., one-time, ongoing, 
or both) that may affect a certified Complete EHR or certified EHR 
Module's total cost of ownership for the purposes of achieving MU.
    We noted in the Proposed Rule that stakeholder feedback on unclear 
pricing prompted us to offer the proposal to require ONC-ACBs to ensure 
that EHR technology developers to specify the purchaser's full cost of 
a certified Complete EHR or certified EHR Module. We identified that 
stakeholders had conveyed to us that EHR technology developers were 
specifying prices for multiple groupings of capabilities even though 
the groupings did not correlate to the entire certified Complete EHR or 
certified EHR Module. Further, as commenters reinforced, EHR 
technologies that may be certified under the ONC HIT Certification 
Program could be sold or licensed with capabilities that are in 
addition to those that fall under the scope of certification.
    We acknowledge that many factors, such as those mentioned by 
commenters (e.g., costs from purchasing EHR technology from multiple 
EHR technology developers, maintenance of the EHR technology, and 
training of staff on the EHR technology), go into a purchaser's total 
ownership cost for a certified Complete EHR or certified EHR Module(s). 
Our proposal sought, however, to clearly identify for purchasers the 
cost associated with the capabilities that the certification assigned 
to a Complete EHR or EHR Module represented, separate and apart from 
those capabilities and services that are not required for certification 
but are sold by EHR technology developers with the purchase of a 
certified Complete EHR or certified EHR Module. On balance, we believe 
that the best approach to address the concerns that prompted our 
proposal, as well as those received in response, is to amend Sec.  
170.523(k)(1) to add a third provision related to price transparency. 
Section Sec.  170.523(k)(1) requires an ONC-ACB to ensure that a 
Complete EHR or EHR Module developer conspicuously includes on its Web 
site and in all marketing materials, communications statements, and 
other assertions related to the Complete EHR or EHR Module's 
certification the information specified in paragraphs (k)(1)(i) and 
(k)(1)(ii). This new provision, finalized at Sec.  170.523(k)(1)(iii), 
requires an ONC-ACB to ensure that a Complete EHR or EHR Module 
developer discloses any additional types of costs that an EP, EH, or 
CAH would pay to implement the capabilities a certified Complete EHR or 
certified EHR Module includes in order to attempt to meet MU objectives 
and measures. We clarify that these types of costs are in addition to 
those costs that an EP, EH, or CAH would pay to purchase (or upgrade 
to) the EHR technology capabilities for which certification is 
required. These may be one-time or recurring costs, or both. We also 
clarify that ONC-ACBs would only be required to ensure that EHR 
technology developers disclose the types of additional costs, and not 
the actual dollar amounts of such costs.
    For example, if EHR technology is certified to the ``view, 
download, and transmit to a 3rd party'' certification criterion, and an 
EP would be expected to pay an ``ongoing'' monthly service fee to the 
EHR technology developer for it to host/administer this capability in 
order for the EP to meet the correlated MU objective and measure, the 
existence of this potential ``ongoing'' cost would need to be disclosed 
by the EHR technology developer. As another example, an EHR Module 
certified to the public health electronic lab reporting certification 
criterion (Sec.  170.314(f)(4)) would be able to create a valid HL7 
message for electronic submission. However, for the purposes of 
achieving MU, a hospital may be expected to pay their EHR technology 
developer a separate ``one-time'' and/or ``ongoing'' interface 
development and configuration fee to establish connectivity between 
their certified EHR Module and a public health authority. In such a 
situation, the potential costs of the interface development and 
configuration fee would need to be disclosed. A final example would be 
where an EHR technology developer charges a ``one-time'' fee to 
integrate its certified EHR technology with a hospital's other 
certified EHR Modules or a health information exchange organization. 
Again, just like the other examples, the potential for this fee would 
need to be disclosed by the EHR technology developer. Building off 
these examples, we would expect that an EHR technology developer could 
satisfy Sec.  170.523(k)(1)(iii) by disclosing: 1) the type(s) of 
additional cost; and 2) to what the cost is attributed. In reference to 
the first example above, an EHR technology might state that ``an 
additional ongoing fee may apply to implement XYZ online patient 
service.'' In situations where the same types of cost apply to 
different services, listing each as part of one sentence would be 
acceptable, such as ``a one-time fee is required to establish 
interfaces for reporting to immunization registries, cancer registries, 
and public health agencies.''
    We believe that the limited scope required by this new disclosure 
will not hinder innovation and flexibility in product development 
pricing, and marketing strategies, nor is it likely to implicate 
confidential or proprietary information. We remind commenters that 
certification already requires certain transparency provisions. Under 
the ONC HIT Certification Program, ONC-ACBs must ensure that EHR 
technology developers specify certain information about their certified 
Complete EHR or certified EHR Module on their Web sites, in all 
marketing materials, communication statements, and other assertions 
(see Sec.  170.523(k)(1)(i) and (ii)). This information conveys all of 
the capabilities that the certification issued to the Complete EHR or 
EHR Module represents and what must be provided to an EP, EH, or CAH in 
order for the EHR technology developer to properly convey the benefit 
(i.e., certification) assigned to the certified Complete EHR or 
certified EHR Module. Further, this information also notifies the 
customer of any additional software that the EHR technology developer 
relied on to meet certain certification criteria. In cases where 
additional software is relied on, it is also encompassed by the

[[Page 54275]]

certification issued to the certified Complete EHR or certified EHR 
Module. From a transparency perspective, this new requirement will 
provide clarity to purchasers regarding the potential additional types 
of costs they may face when implementing a certified Complete EHR or 
certified EHR Module. It may also help prevent purchasers from being 
surprised by additional costs beyond those associated with the adoption 
and implementation of the capabilities that comprise their CEHRT.
    We described ``self-developed'' EHR technology in the Permanent 
Certification Program final rule (76 FR 1300-1301). We described self-
developed EHR technology to mean a Complete EHR or EHR Module that has 
been designed, modified, or created by, or under contract for, a person 
or entity that will assume the total costs for its testing and 
certification and will be a primary user of the Complete EHR or EHR 
Module. We further noted that this distinction served to distinguish 
between those Complete EHRs and EHR Modules that would be created once 
and most likely sold to many EPs, EHs, and CAHs from those that would 
be certified once and used primarily by the person or entity who paid 
for testing and certification. On the developer level, we used the 
terms ``self-developer'' and commercial vendor to distinguish between 
the two types of developers. As requested by commenters, EHR technology 
self-developers would be exempt from the new requirement because they 
will not be marketing or making their certified Complete EHRs or 
certified EHR Modules commercially available for sale. To obtain this 
exemption, EHR technology self-developers will need to provide written 
notification to the ONC-ACB when presenting their EHR technology for 
certification that they are an EHR technology self-developer and their 
EHR technology will not be marketed or made commercially available for 
sale to health care providers.
    ONC-ACBs are responsible for ensuring compliance with Sec.  
170.523(k)(1) and will determine appropriate consequences if EHR 
technology developers fail to disclose the information specified in 
Sec.  170.523(k)(1).

G. 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, in the Proposed Rule, we noted that the certification 
criteria proposed for adoption focused 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. We discussed, however, the National Coordinator's statutory 
authority to establish a voluntary certification program or programs 
for other types of HIT besides the EHR technology that could be used to 
demonstrate meaningful use. We explained that 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. With this consideration, we sought public comment on whether 
we should focus any certification efforts towards the HIT used by 
health care providers that are ineligible to receive incentives under 
the EHR Incentive Programs.
    In particular, we requested comments 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. We asked that commenters specify the certification criteria 
that would be appropriate as well as the benefits they believe a 
regulatory approach would provide. Last, we asked that the public 
consider whether the private sector could alternatively address any 
perceived need or demand for such certification and specifically 
mentioned 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.\41\
---------------------------------------------------------------------------

    \41\ https://www.cchit.org/get_certified/cchit-certified-2011.
---------------------------------------------------------------------------

    Comments. Commenters strongly supported certification for other 
health care settings. A few commenters suggested that we develop 
certification criteria for other health care settings. However, the 
majority of commenters also noted that the lack of financial incentives 
for other health care settings (e.g., long term, post acute, home 
health, hospice, and behavioral settings) was a significant barrier and 
would render attempts to adopt certification or certification criteria 
for other health care settings infeasible. Multiple commenters noted 
that voluntary certification programs for other health care settings 
have been developed by the private sector with industry-wide 
stakeholder input. Commenters specifically pointed to the certification 
programs run by the CCHIT, which cover long-term and post-acute care, 
skilled nursing facilities, and home health. Comments stated that 
private sector certification programs provide for greater flexibility, 
such as being able to revise and develop standards more in line with 
the pace of technology development. Commenters also noted that these 
programs are synchronized with applicable standards adopted to support 
MU, such as standards for transitions of care and privacy and security.
    Commenters recommended that we focus on interoperability and health 
information exchange among all health care settings. Specifically, 
commenters suggested that we identify a subset of MU certification 
criteria and standards that support standards-based exchange of health 
information that protect the privacy and security of the health 
information being exchanged. Some commenters also suggested that we 
identify certification criteria that would support the ability of 
providers practicing in other health care settings to comply with 
federal reporting requirements. Commenters also recommended that we 
encourage EHR technology developers to obtain certification for EHR 
Modules that would specifically support these types of capabilities, 
like the exchange of a transition of care/referral summary.
    Response. We appreciate the interest in other health care settings 
expressed by commenters. We agree that it makes good policy sense to 
support interoperability and the secure electronic exchange of health 
information between all health care settings. We believe the adoption 
of EHR technology certified to a minimal amount of certification 
criteria adopted by the Secretary can support this goal. To this end, 
we encourage EHR technology developers to certify EHR Modules to the 
transitions of care certification criteria (Sec.  170.314(b)(1) and 
(2)) as well as any other certification criteria that may make it more 
effective and efficient for EPs, EHs, and CAHs to electronically 
exchange health information with health care providers in other health 
care settings. The adoption of EHR technology certified to these 
certification criteria can facilitate the secure electronic exchange of 
health information. We concur with commenters that there are currently 
private sector organizations that are addressing requests for 
certification programs for other health care settings.

VII. Collection of Information Requirements

    Under the Paperwork Reduction Act of 1995 (PRA), agencies are 
required to

[[Page 54276]]

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.
    In the Proposed Rule, published March 7, 2012 (77 FR 13832), we 
solicited public comment on each of these issues for revisions to OMB 
control number 0990-0378. We did not receive any comments on this 
collection of information. We have finalized at Sec.  170.523(f)(8) the 
requirement, as proposed, for 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 
Complete EHRs and EHR Modules. Having not obtained any information that 
would suggest we reconsider our original burden estimates, we have 
maintained those same estimates.

Abstract

    Under the ONC HIT 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. These collections of information 
were approved under OMB control number 0990-0378. In the Proposed Rule, 
we proposed to revise Sec.  170.523(f) and, correspondingly, proposed 
to revise OMB control number 0990-0378 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 proposed 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 
proposed to add this requirement at Sec.  170.523(f)(8).
    For the purposes of estimating this additional potential burden, we 
used the following assumptions. We assumed 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 assumed 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 estimated that, on average, each ONC-ACB will report 4 test results 
hyperlinks to ONC on a weekly basis.
    We believe that it will take approximately 5 minutes to report each 
hyperlink to ONC. Therefore, as reflected in the table below, we 
estimated 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 collection of information at Sec.  
170.523(f)(8), we added 103 burden hours 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
               Type of respondent                    Number of     responses per   burden hours    Total burden
                                                    respondents     respondent     per 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
----------------------------------------------------------------------------------------------------------------
Total burden hours for OMB control number 0990-0378.............................................             435
----------------------------------------------------------------------------------------------------------------


[[Page 54277]]

VII. 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. 
Collectively, the initial set is referred to as the 2011 Edition EHR 
certification criteria. This final rule adopts another edition of 
standards, implementation specifications, and certification criteria 
that we refer to as the 2014 Edition EHR certification criteria. The 
2014 Edition EHR certification criteria support the MU objectives and 
measures under the EHR Incentive Programs and will be used to test and 
certify EHR technology (Complete EHRs and EHR Modules). EPs, EHs, and 
CAHs must adopt and implement certified Complete EHRs and/or certified 
EHR Modules in order to have 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 final 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. Comment and Response
    Comments. A few other commenters stated we did not account for the 
costs that public health agencies will incur by having to meet the 
standards we adopt for certification criteria that support reporting to 
public health agencies. Some commenters stated that the regulatory 
impact analysis does not account for costs that EPs, EHs, and CAHs will 
incur in adopting and implementing CEHRT. One commenter suggested that 
we should increase our average overall hours for development and 
preparation of EHR technology for certification to the 2014 Edition EHR 
certification criteria by a multiplier of four to account for 
integration of these new features into current EHR workflows.
    Response. The information technology public health agencies use or 
would need to employ or modify in order to receive data according to 
the standards we adopt for EHR technology certification is not within 
the scope of this rulemaking. In promulgating this final rule, we have 
considered the standards adopted by public health agencies before 
including them in the relevant certification criteria.
    The costs that EPs, EHs, and CAHs will incur in adopting and 
implementing certified Complete EHRs and certified EHR Modules are not 
within the scope of this final rule. Those costs would include the 
costs of integrating new features into their EHR workflows. Those costs 
are estimated in the Stage 2 final rule published elsewhere in this 
issue of the Federal Register.
2. 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 final rule is not an economically 
significant rule because our primary estimate of the costs to prepare 
Complete EHRs and EHR Modules to be tested and certified will be less 
than $100 million in any given year. Nevertheless, because of the 
public interest in this final rule, we have prepared an RIA that to the 
best of our ability presents the costs and benefits of the final rule.
a. Costs
    This rule adopts standards, implementation specifications, and 
certification criteria that 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 final 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 be upgrade to the adopted 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 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 2014 Edition EHR certification criteria discussed in this final rule 
(i.e., new, revised, and unchanged). The numbers of Complete EHRs and 
EHR Modules that we estimate will be developed to each 2014 Edition EHR 
certification criterion are based on the statistics we obtained from 
the CHPL on July 6, 2012. We attempted to identify the total number of 
Complete EHRs and EHR Modules that were developed to the 2011 Edition 
EHR certification criteria as of July 6, 2012. By this we mean that we 
first attempted to discern how many Complete EHRs and EHR Modules were 
certified that would not constitute a newer version of the same EHR 
technology. Second, we attempted to determine how many certified 
Complete EHRs and certified EHR Modules shared much of the same 
development costs. For example, when a Complete EHR is certified first 
and then an EHR technology developer subsequently seeks one or more EHR 
Module certifications for portions of that Complete EHR in order to 
provide its customers with more options. Using this number, we adjusted 
it based on additional considerations unique to the 2014 Edition EHR 
certification criteria such as the adoption of optional certification 
criteria, certification criteria included in the Base EHR definition, 
and the revised CEHRT definition. The revised CEHRT definition will 
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 developed to meet each

[[Page 54278]]

certification criterion, we have established 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 
developed to meet the 2011 Edition EHR certification criteria that may 
not be upgraded 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.
    As noted in the Proposed Rule, 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 $44.27.\42\ 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 the 
average software developer's wage with benefits to $60 per hour.
---------------------------------------------------------------------------

    \42\ https://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 (``level of effort'' 
described above) 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 (``level of effort'' described 
above) 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.
    In comparison to the listed certification criteria in the 
regulatory impact analysis for the Proposed Rule, we note the following 
changes based on the certification criteria we adopted. We have 
included the two new adopted certification criteria: data portability 
(Sec.  170.314(b)(7); and quality management systems (Sec.  
170.414(g)(4)). We have moved the proposed unchanged certification 
criteria that have been adopted as revised certification criteria into 
the revised certification criteria section. These include: ``drug-
formulary checks'' (Sec.  170.314(a)(10)); ``vital signs, body mass 
index, and growth charts'' (Sec.  170.314(a)(4)); ``smoking status'' 
(Sec.  170.314(a)(11)); ``patient lists'' (Sec.  170.314(a)(14)); and 
``patient reminders'' (Sec.  170.314(a)(15)) [now combined and 
collectively referred to as ``patient list creation'']. Last, we have 
moved the new ``view, download, and transmit to 3rd party'' 
certification criterion (Sec.  170.314(e)(1)) from a level 3 effort 
down to a level 2 effort. We changed the level of effort because we did 
not adopt our proposals regarding images and WCAG 2.0 level AA for this 
certification criterion and because many of the EHR technologies that 
will be designed to meet this certification criterion have already met 
the 2011 Edition ``timely access'' certification criterion (Sec.  
170.304(g)).
New Certification Criteria

                      Table 7--2014 Edition New EHR Certification Criteria: Level 1 Effort
----------------------------------------------------------------------------------------------------------------
                                                                     Estimated
                                                                   number of EHR      Average         Average
                                                                   technologies     development     development
               Regulation section                  Certification       to be            and             and
                                                     criterion    developed with    preparation     preparation
                                                                       this         costs--low      costs--high
                                                                    capability         ($M)            ($M)
----------------------------------------------------------------------------------------------------------------
170.314(a)(9)...................................      Electronic         420-514            1.01            3.08
                                                           notes
170.314(a)(13)..................................   Family health         420-514            1.01            3.08
                                                         history
170.314(b)(3)...................................      Electronic         101-123             .24             .74
                                                     prescribing
                                                     (inpatient)
170.314(b)(7)...................................            Data         670-818            1.61            4.91
                                                     portability

[[Page 54279]]

 
170.314(f)(5)...................................     Cancer case         320-392             .77            2.35
                                                     information
170.314(g)(4)...................................         Quality         670-818            1.61            4.91
                                                      management
                                                         systems
                                                 ---------------------------------------------------------------
    Total.......................................  ..............  ..............            6.25           19.07
----------------------------------------------------------------------------------------------------------------


                      Table 8--2014 Edition New EHR Certification Criteria: Level 2 Effort
----------------------------------------------------------------------------------------------------------------
                                                                     Estimated
                                                                   number of EHR      Average         Average
                                                                   technologies     development     development
          Regulation section             Certification criterion       to be            and             and
                                                                  developed with    preparation     Preparation
                                                                       this         costs--low      costs--high
                                                                    capability         ($M)            ($M)
----------------------------------------------------------------------------------------------------------------
170.314(a)(12)........................  Image results...........         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)(1).........................  View, download, and              567-693            3.40           12.47
                                         transmit to 3rd party.
170.314(e)(3).........................  Secure messaging........         320-392            1.92            7.06
170.314(f)(6).........................  Transmission to cancer           320-392            1.92            7.06
                                         registries.
170.314(g)(1).........................  Automated numerator              398-486            2.39            8.75
                                         recording.
                                       -------------------------------------------------------------------------
    Total.............................  ........................  ..............           16.43           60.23
----------------------------------------------------------------------------------------------------------------


                      Table 9--2014 Edition New EHR Certification Criteria: Level 3 Effort
----------------------------------------------------------------------------------------------------------------
                                                                     Estimated
                                                                    of       Average         Average
                                                                        EHR         development     development
                                                                   technologies         and             and
          Regulation section             Certification criterion       to be        preparation     preparation
                                                                  developed with    costs--low      costs--high
                                                                       this            ($M)            ($M)
                                                                    capability
----------------------------------------------------------------------------------------------------------------
170.314(a)(16)........................  Electronic medication            101-123            1.82            2.95
                                         administration record.
170.314(g)(3).........................  Safety-enhanced design..         567-693           10.21           16.63
                                       -------------------------------------------------------------------------
Total.................................  ........................  ..............           12.03           19.58
----------------------------------------------------------------------------------------------------------------

Revised Certification Criteria

                    Table 10--2014 Edition Revised EHR Certification Criteria: Level 1 Effort
----------------------------------------------------------------------------------------------------------------
                                                                     Estimated
                                                                   number of EHR      Average         Average
                                                                   technologies     development     development
          Regulation section             Certification criterion       to be            and             and
                                                                  developed with    preparation     preparation
                                                                       this         costs--low      costs--high
                                                                    capability         ($M)            ($M)
----------------------------------------------------------------------------------------------------------------
170.314(a)(2).........................  Drug-drug, drug-allergy          484-591            1.16            3.55
                                         interaction checks.
170.314(a)(3).........................  Demographics............         530-648            1.27            3.89
170.314(a)(4).........................  Vital signs, body mass           502-613            1.20            3.68
                                         index, and growth
                                         charts.
170.314(a)(5).........................  Problem list............         504-616            1.21            3.70
170.314(a)(10)........................  Drug-formulary checks...         484-591            1.16            3.55
170.314(a)(11)........................  Smoking status..........         536-655            1.29            3.93
170.314(a)(14)........................  Patient list creation...         473-578            1.14            3.47
170.314(a)(15)........................  Patient-specific                 480-587            1.15            3.52
                                         education resources.
170.314(b)(3).........................  Electronic prescribing           445-544            1.07            3.26
                                         (ambulatory).
170.314(b)(5).........................  Incorporate laboratory           167-205             .40            1.23
                                         tests and values/
                                         results (ambulatory
                                         setting).

[[Page 54280]]

 
170.314(c)(2).........................  Clinical quality                 497-608            1.19            3.65
                                         measures--incorporate
                                         and calculate.
170.314(d)(3).........................  Audit report(s).........         670-818            1.61            4.91
170.314(e)(2).........................  Clinical summaries......         432-528            1.04            3.17
170.314(f)(2).........................  Transmission to                  456-557            1.09            3.34
                                         immunization registries.
170.314(f)(3).........................  Transmission to public           447-546            1.07            3.28
                                         health agencies--
                                         syndromic surveillance.
170.314(f)(4).........................  Transmission of                    60-74             .14             .44
                                         reportable laboratory
                                         tests and values/
                                         results.
                                       -------------------------------------------------------------------------
    Total.............................  ........................  ..............           17.19           52.57
----------------------------------------------------------------------------------------------------------------


                    Table 11--2014 Edition Revised EHR Certification Criteria: Level 2 Effort
----------------------------------------------------------------------------------------------------------------
                                                                     Estimated
                                                                   number of EHR      Average         Average
                                                                   technologies     development     development
          Regulation Section             Certification criterion       to be            and             and
                                                                  developed with    preparation     preparation
                                                                       this         costs--low      costs--high
                                                                    capability         ($M)            ($M)
----------------------------------------------------------------------------------------------------------------
170.314(b)(1).........................  Transitions of care--            514-628            3.08           11.30
                                         receive, display, and
                                         incorporate transition
                                         of care/referral
                                         summaries.
170.314(b)(4).........................  Clinical information             498-609            2.99           10.96
                                         reconciliation.
170.314(c)(3).........................  Clinical quality                 497-608            2.98           10.94
                                         measures--submission.
170.314(d)(2).........................  Auditable events and             670-818            4.02           14.72
                                         tamper resistance.
170.314(d)(7).........................  End-user device                  667-816            4.00           14.69
                                         encryption.
170.314(g)(2).........................  Automated measure                460-562            2.76           10.12
                                         calculation.
                                       -------------------------------------------------------------------------
    Total.............................  ........................  ..............           19.83           72.73
----------------------------------------------------------------------------------------------------------------


                    Table 12--2014 Edition Revised EHR Certification Criteria: Level 3 Effort
----------------------------------------------------------------------------------------------------------------
                                                                     Estimated
                                                                   number of EHR      Average         Average
                                                                   technologies     development     development
          Regulation Section             Certification criterion       to be            and             and
                                                                  developed with    preparation     preparation
                                                                       this         costs--low      costs--high
                                                                    capability         ($M)            ($M)
----------------------------------------------------------------------------------------------------------------
170.314(a)(8).........................  Clinical decision                474-580            8.53           17.40
                                         support.
170.314(b)(2).........................  Transitions of care--            514-628            9.25           18.84
                                         create and transmit
                                         transition of care/
                                         referral summaries.
170.314(c)(1).........................  Clinical quality                 497-608            8.95           18.24
                                         measures--capture and
                                         export.
                                       -------------------------------------------------------------------------
    Total.............................  ........................  ..............           26.73           54.48
----------------------------------------------------------------------------------------------------------------

Unchanged Certification Criteria

                   Table 13--2014 Edition Unchanged EHR Certification Criteria: Level 2 Effort
----------------------------------------------------------------------------------------------------------------
                                                                     Estimated
                                                                   number of EHR      Average         Average
                                                                   technologies     development     development
          Regulation Section             Certification criterion       to be            and             and
                                                                  developed with    preparation     preparation
                                                                       this         costs--low      costs--high
                                                                    capability         ($M)            ($M)
----------------------------------------------------------------------------------------------------------------
170.314(a)(1).........................  CPOE....................              62             .37            1.12
170.314(a)(6).........................  Medication list.........              57             .34            1.03
170.314(a)(7).........................  Medication allergy list.              58             .35            1.04
170.314(a)(17)........................  Advance directives......              11             .07             .20

[[Page 54281]]

 
170.314(b)(5).........................  Incorporate laboratory                19             .11             .34
                                         tests and values/
                                         results (inpatient
                                         setting).
170.314(d)(1).........................  Authentication, access                76             .46            1.37
                                         control, and
                                         authorization.
170.314(d)(5).........................  Automatic log-off.......              76             .46            1.37
170.314(d)(6).........................  Emergency access........              73             .44            1.31
170.314(d)(8).........................  Integrity...............              75             .45            1.35
170.314(d)(9).........................  Accounting of                         13             .08             .23
                                         disclosures.
170.314(f)(1).........................  Immunization information              51             .31             .92
���������������������������������������
    Total.............................  ........................  ..............            3.44           10.28
----------------------------------------------------------------------------------------------------------------

ii. Overall Development and Preparation Estimated Costs Over a 3-Year 
Period
    In total, we estimate the overall costs for a 3-year period to be 
$101.90 million to $288.94 million, with a cost mid-point of 
approximately $195.42 million. If we were to evenly distribute the 
overall estimated 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 $33.97 million to $96.31 million per year 
with an annual cost mid-point of approximately $65.14 million. We have 
used the mid-point cost as our primary annual cost estimate for this 
regulatory impact analysis.
    We do not believe that the estimated costs will be spread evenly 
over these three years due to market pressures, primarily consisting of 
EPs, EHs, and CAHs needing to adopt and implement EHR technology 
certified to the 2014 Edition EHR certification criteria in order to 
have CEHRT in FY/CY 2014. Based on this market pressure, in the 
Proposed Rule, we distributed the majority of the estimated costs in 
2012 (40%) and 2013 (50%), while only distributing 10% of the estimated 
costs in 2014. With the additional flexibility that we have adopted in 
the CEHRT definition for FY/CY 2013, namely permitting EPs, EHs, and 
CAHs to meet the CEHRT definition for FY/CY 2014 in FY/CY 2013, we 
believe that the market pressure for EHR technology certified to the 
2014 Edition EHR certification criteria to be available sooner will 
further increase. Given this consideration and the fact that we have 
issued this final rule sooner than we anticipated when publishing the 
Proposed Rule, we have revised our distribution of estimated costs to 
place more of the total estimated costs in 2012. As such, the estimated 
costs attributable to this final rule are distributed as follows: 45% 
for 2012, 45% for 2013, and 10% for 2014. This distribution of 
estimated costs for the year in which this final rule is published is 
also consistent with the distribution we used in the S&CC July 2010 
final rule (75 FR 44648) for the year in which it was published. Table 
14 below expresses the distribution of estimated costs for 2012 through 
2014 in 2012 dollars.

Table 14--Distributed Total Development and Preparation Costs for Complete EHR and EHR Module Developers (3-Year
                                             Period)--Totals Rounded
----------------------------------------------------------------------------------------------------------------
                                                                                                   Primary mid-
                                                                  Total low cost    Total high      point total
                      Year                           Ratio (%)     estimate ($M)   cost estimate   cost estimate
                                                                                       ($M)            ($M)
----------------------------------------------------------------------------------------------------------------
2012............................................              45           45.85          130.02           87.93
2013............................................              45           45.85          130.02           87.93
2014............................................              10           10.20           28.90           19.56
�������������������������������������������������
    3-Year Totals...............................  ..............          101.90          288.94          195.42
----------------------------------------------------------------------------------------------------------------

iii. Costs for Reporting Test Results Hyperlinks
Costs to ONC-ACBs
    Under Sec.  170.523(f)(8), ONC-ACBs are 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, the reporting of this information will be 
required on a weekly basis and 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 54282]]



                                     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 hourly   Total cost per
                                                                                            ACB           wage rate           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 
applicants we estimated for the purposes of the collection of 
information (i.e., six) will apply and become ONC-ACBs under the ONC 
HIT Certification Program. Therefore, we estimate the total annual 
development and reporting cost under the ONC HIT Certification Program 
to be $3,136 (rounded using a total of 103 hours).
Costs to the Federal Government
    We do not believe that the collection of information requirement of 
Sec.  170.523(f)(8), through our posting of test results hyperlinks on 
the CHPL, will require us to incur any additional costs than the costs 
we estimated for having personnel post a list of all certified Complete 
EHRs and certified 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 final rule. Foremost, EHR technology certified to the 2014 Edition 
EHR certification criteria will be capable of supporting EPs, EHs, and 
CAHs' attempts to demonstrate MU under the EHR Incentive Programs. The 
2014 Edition EHR 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. The capabilities 
specified in the 2014 Edition EHR 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 provisions in this final rule will 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 revised 
CEHRT definition, the process for approving newer versions of minimum 
standards, and the revised 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 ``splitting'' 
of certain 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, the provisions of this final rule are supportive of other 
initiatives, such as the Partnership for Patients, Medicare Shared 
Savings Program, and other quality measure programs administered by 
CMS.
3. 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 final rule most likely fall under the North American Industry 
Classification System (NAICS) code 541511 ``Custom Computer Programming 
Services'' specified at 13 CFR 121.201 where the SBA publishes ``Small 
Business Size Standards by NAICS Industry.'' The SBA size standard 
associated with this NAICS code is set at $25.5 million in annual 
receipts \43\ which ``indicates the maximum allowed for a concern and 
its affiliates to be considered small entities.''
---------------------------------------------------------------------------

    \43\ 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. https://www.sba.gov/sites/default/files/files/Size_Standards_Table.pdf.
---------------------------------------------------------------------------

    Based on our analysis, we believe that there is enough data 
generally available to establish that between 75% and 90% of entities 
that are categorized under the NAICS code 541511 are under the SBA size 
standard, but note that the available data does not show how many of 
these entities will develop a 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 final rule will have effects on Complete EHR 
and EHR Module developers, some of which may be small entities. 
However, we believe that we have established the minimum amount of 
requirements necessary to accomplish our policy goals, including a 
reduction in regulatory burden and additional flexibility for the 
regulated community; and that no additional appropriate regulatory 
alternatives could be developed to lessen the compliance burden 
associated with this final rule. 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 Stage 2 final rule, it will need to comply 
with the applicable 2014 Edition EHR certification criteria adopted by 
the Secretary. Moreover, we note that this final 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 this final rule will create 
a significant impact on a substantial number of small entities. The 
Secretary certifies that this final rule will not have a significant 
impact on a substantial number of small entities.
4. Executive Order 13132--Federalism
    Executive Order 13132 establishes certain requirements that an 
agency must meet when it promulgates a final

[[Page 54283]]

rule that imposes substantial direct requirement costs on state and 
local governments, preempts state law, or otherwise has federalism 
implications. Nothing in this final rule imposes substantial direct 
compliance costs on state and local governments, preempts state law or 
otherwise has federalism implications. We are not aware of any state 
laws or regulations that are contradicted or impeded by any of the 
standards, implementation specifications, or certification criteria 
that the Secretary has adopted.
5. 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 $139 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 final 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, is amended as follows:

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

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

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

0
2. In Sec.  170.102, remove the ``Complete EHR'' definition, add in 
alphanumeric order the definitions ``2011 Edition EHR certification 
criteria,'' ``2014 Edition EHR certification criteria,'' ``Base EHR,'' 
``Common MU Data Set,'' ``Complete EHR, 2011 Edition,'' and ``Complete 
EHR, 2014 Edition,'' and revise the definition of ``Certified EHR 
Technology'' 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) Has been certified to the certification criteria adopted by the 
Secretary at: Sec.  170.314(a)(1), (3), and (5) through (8); (b)(1), 
(2), and (7); (c)(1) through (3); (d)(1) through (8).
    (4) Has been certified to the certification criteria at Sec.  
170.314(c)(1) and (2):
    (i) For no fewer than 9 clinical quality measures covering at least 
3 domains from the set selected by CMS for eligible professionals, 
including at least 6 clinical quality measures from the recommended 
core set identified by CMS; or
    (ii) For no fewer than 16 clinical quality measures covering at 
least 3 domains from the set selected by CMS for eligible hospitals and 
critical access hospitals.
* * * * *
    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; or
    (iii) EHR technology that satisfies the definition for FY and CY 
2014 and subsequent years specified in paragraph (2);
    (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 Base EHR definition; and
    (ii) All other capabilities that are necessary to meet the 
objectives and associated measures under 42 CFR 495.6 and successfully 
report the clinical quality measures selected by CMS in the form and 
manner specified by CMS (or the States, as applicable) for the stage of 
meaningful use that an eligible professional, eligible hospital, or 
critical access hospital seeks to achieve.
    Common MU Data Set means the following data expressed, where 
indicated, according to the specified standard(s):
    (1) Patient name.
    (2) Sex.
    (3) Date of birth.
    (4) Race--the standard specified in Sec.  170.207(f).
    (5) Ethnicity--the standard specified in Sec.  170.207(f).
    (6) Preferred language--the standard specified in Sec.  170.207(g).
    (7) Smoking status--the standard specified in Sec.  170.207(h).
    (8) Problems--at a minimum, the version of the standard specified 
in Sec.  170.207(a)(3).
    (9) Medications--at a minimum, the version of the standard 
specified in Sec.  170.207(d)(2).
    (10) Medication allergies--at a minimum, the version of the 
standard specified in Sec.  170.207(d)(2).
    (11) Laboratory test(s)--at a minimum, the version of the standard 
specified in Sec.  170.207(c)(2).
    (12) Laboratory value(s)/result(s).
    (13) Vital signs--height, weight, blood pressure, BMI.
    (14) Care plan field(s), including goals and instructions.
    (15) Procedures--
    (i) At a minimum, the version of the standard specified in Sec.  
170.207(a)(3) or Sec.  170.207(b)(2).
    (ii) Optional. The standard specified at Sec.  170.207(b)(3).

[[Page 54284]]

    (iii) Optional. The standard specified at Sec.  170.207(b)(4).
    (16) Care team member(s).
    Complete EHR, 2011 Edition means EHR technology that has been 
developed to meet, at a minimum, all mandatory 2011 Edition EHR 
certification criteria for either an ambulatory setting or inpatient 
setting.
    Complete EHR, 2014 Edition means EHR technology that meets the Base 
EHR definition and has been developed to meet, at a minimum, all 
mandatory 2014 Edition EHR certification criteria for either an 
ambulatory setting or inpatient setting.
* * * * *

0
3. Add Sec.  170.202 to read as follows:


Sec.  170.202  Transport standards.

    The Secretary adopts the following transport standards:
    (a) Standard. ONC Applicability Statement for Secure Health 
Transport (incorporated by reference in Sec.  170.299).
    (b) Standard. ONC XDR and XDM for Direct Messaging Specification 
(incorporated by reference in Sec.  170.299).
    (c) Standard. ONC Transport and Security Specification 
(incorporated by reference in Sec.  170.299).

0
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 A Conformance (incorporated by reference in Sec.  
170.299).
    (b) Reference source. Standard. HL7 Version 3 Standard: Context-
Aware Retrieval Application (Infobutton) (incorporated by reference in 
Sec.  170.299). (1) Implementation specifications. HL7 Version 3 
Implementation Guide: URL-Based Implementations of the Context-Aware 
Information Retrieval (Infobutton) Domain, (incorporated by reference 
in Sec.  170.299).
    (2) Implementation specifications. HL7 Version 3 Implementation 
Guide: Context-Aware Knowledge Retrieval (Infobutton) Service-Oriented 
Architecture Implementation Guide, (incorporated by reference in Sec.  
170.299).
    (c) Clinical quality measure-by-measure data. Data Element Catalog, 
(incorporated by reference in Sec.  170.299).

0
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 
associated implementation specifications:
    (a) * * *
    (3) Standard. HL7 Implementation Guide for CDA[supreg] Release 2: 
IHE Health Story Consolidation, (incorporated by reference in Sec.  
170.299). The use of the ``unstructured document'' document-level 
template is prohibited.
* * * * *
    (d) * * *
    (3) Standard. HL7 2.5.1 (incorporated by reference in Sec.  
170.299). Implementation specifications. PHIN Messaging Guide for 
Syndromic Surveillance (incorporated by reference in Sec.  170.299) and 
Conformance Clarification for EHR Certification of Electronic Syndromic 
Surveillance, Addendum to PHIN Messaging Guide for Syndromic 
Surveillance (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.4, (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) (incorporated by reference in Sec.  170.299) with 
Errata and Clarifications, (incorporated by reference in Sec.  170.299) 
and ELR 2.5.1 Clarification Document for EHR Technology Certification, 
(incorporated by reference in Sec.  170.299).
    (h) Clinical quality measure data import, export, and electronic 
submission. Standard. HL7 Implementation Guide for CDA[supreg] Release 
2: Quality Reporting Document Architecture, (incorporated by reference 
in Sec.  170.299).
    (i) Cancer information. Standard. HL7 Clinical Document 
Architecture (CDA), Release 2.0, Normative Edition (incorporated by 
reference in Sec.  170.299). Implementation specifications. 
Implementation Guide for Ambulatory Healthcare Provider Reporting to 
Central Cancer Registries, HL7 Clinical Document Architecture (CDA), 
(incorporated by reference in Sec.  170.299).
    (j) Electronic incorporation and transmission of lab results. 
Standard. HL7 Version 2.5.1 Implementation Guide: S&I Framework Lab 
Results Interface, (incorporated by reference in Sec.  170.299).
    (k) Clinical quality measure aggregate electronic submission. 
Standard. Quality Reporting Document Architecture Category III, 
Implementation Guide for CDA Release 2 (incorporated by reference in 
Sec.  170.299).

0
6. In Sec.  170.207, republish the introductory text and add paragraphs 
(a)(3), (b)(3), (b)(4), revise paragraphs (c), (d), (e), and (f) and 
add paragraphs (g) through (j) 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. IHTSDO SNOMED CT[supreg] International Release July 
2012 (incorporated by reference in Sec.  170.299) and US Extension to 
SNOMED CT[supreg] March 2012 Release (incorporated by reference in 
Sec.  170.299).
    (b) * * *
    (3) Standard. The code set specified at 45 CFR 162.1002(a)(4).
    (4) Standard. The code set specified at 45 CFR 162.1002(c)(3) for 
the indicated procedures or other actions taken.
    (c) Laboratory tests. (1) Standard. Logical Observation Identifiers 
Names and Codes (LOINC[supreg]) version 2.27, when such codes were 
received within an electronic transaction from a laboratory 
(incorporated by reference in Sec.  170.299).
    (2) Standard. Logical Observation Identifiers Names and Codes 
(LOINC[supreg]) Database version 2.40, a universal code system for 
identifying laboratory and clinical observations produced by the 
Regenstrief Institute, Inc. (incorporated by reference in Sec.  
170.299).
    (d) Medications. (1) Standard. Any source vocabulary that is 
included in RxNorm, a standardized nomenclature for clinical drugs 
produced by the United States National Library of Medicine.
    (2) Standard. RxNorm, a standardized nomenclature for clinical 
drugs produced by the United States National Library of Medicine, 
August 6, 2012 Release (incorporated by reference in Sec.  170.299).
    (e) Immunizations. (1) Standard. HL7 Standard Code Set CVX--
Vaccines Administered, July 30, 2009 version (incorporated by reference 
in Sec.  170.299).
    (2) Standard. HL7 Standard Code Set CVX--Vaccines Administered, 
updates through July 11, 2012 (incorporated by reference in Sec.  
170.299).
    (f) Race and Ethnicity. Standard. The Office of Management and 
Budget Standards for Maintaining, Collecting, and Presenting Federal 
Data on Race

[[Page 54285]]

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 https://www.whitehouse.gov/omb/fedreg_1997standards).
    (g) Preferred language. Standard. As specified by the Library of 
Congress, ISO 639-2 alpha-3 codes limited to those that also have a 
corresponding alpha-2 code in ISO 639-1. (incorporated by reference in 
Sec.  170.299).
    (h) Smoking status. Standard. Smoking status must be coded in one 
of the following SNOMED CT[supreg] codes:
    (1) Current every day smoker. 449868002
    (2) Current some day smoker. 428041000124106
    (3) Former smoker. 8517006
    (4) Never smoker. 266919005
    (5) Smoker, current status unknown. 77176002
    (6) Unknown if ever smoked. 266927001
    (7) Heavy tobacco smoker. 428071000124103
    (8) Light tobacco smoker. 428061000124105
    (i) Encounter diagnoses. Standard. The code set specified at 45 CFR 
162.1002(c)(2) for the indicated conditions.
    (j) Family health history. HL7 Version 3 Standard: Clinical 
Genomics; Pedigree, (incorporated by reference in Sec.  170.299).

0
7. In Sec.  170.210:
0
a. Republish the introductory text;
0
b. In paragraph (a)(1), add the phrase ``, (January 27, 2010)'' after 
``140-2'';
0
c. In paragraph (c), remove ``180-3 (October, 2008))'' and add in its 
place ``180-4 (March 2012))''; and
0
d. Add paragraphs (e) through (h) 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)(i) The audit log 
must record the information specified in sections 7.2 through 7.4, 7.6, 
and 7.7 of the standard specified at Sec.  170.210(h) when EHR 
technology is in use.
    (ii) The date and time must be recorded in accordance with the 
standard specified at Sec.  170.210(g).
    (2)(i) The audit log must record the information specified in 
sections 7.2 and 7.4 of the standard specified at Sec.  170.210(h) when 
the audit log status is changed.
    (ii) The date and time each action occurs in accordance with the 
standard specified at Sec.  170.210(g).
    (3) The audit log must record the information specified in sections 
7.2 and 7.4 of the standard specified at Sec.  170.210(h) when the 
encryption status of electronic health information locally stored by 
EHR technology on end-user devices is changed. The date and time each 
action occurs in accordance with the standard specified at Sec.  
170.210(g).
    (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 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 (RFC 1305) Network 
Time Protocol, (incorporated by reference in Sec.  170.299) or (RFC 
5905) Network Time Protocol Version 4, (incorporated by reference in 
Sec.  170.299).
    (h) Audit log content. ASTM E2147-01(Reapproved 2009), 
(incorporated by reference in Sec.  170.299)

0
8. Amend Sec.  170.299 by revising paragraphs (b) through (j) and 
adding paragraphs (k) through (n) to read as follows:


Sec.  170.299  Incorporation by reference.

* * * * *
    (b) American National Standards Institute, Health Information 
Technology Standards Panel (HITSP) Secretariat, 25 West 43rd Street--
Fourth Floor, New York, NY 10036, https://www.hitsp.org.
    (1) HITSP Summary Documents Using HL7 Continuity of Care Document 
(CCD) Component, HITSP/C32, July 8, 2009, Version 2.5, IBR approved for 
Sec.  170.205.
    (2) [Reserved]
    (c) ASTM International, 100 Barr Harbor Drive, PO Box C700, West 
Conshohocken, PA, 19428-2959 USA; Telephone (610) 832-9585 or https://www.astm.org/.
    (1) ASTM E2147-01 (Reapproved 2009) Standard Specification for 
Audit and Disclosure Logs for Use in Health Information Systems, 
approved September 1, 2009, IBR approved for Sec.  170.210.
    (2) ASTM E2369-05: Standard Specification for Continuity of Care 
Record (CCR), year of adoption 2005, ASTM approved July 17, 2006, IBR 
approved for Sec.  170.205.
    (3) ASTM E2369-05 (Adjunct to E2369): Standard Specification 
Continuity of Care Record,--Final Version 1.0 (V1.0), November 7, 2005, 
IBR approved for Sec.  170.205.
    (d) Centers for Disease Control and Prevention, 2500 Century 
Parkway, Mailstop E-78, Atlanta, GA 30333, USA (800-232-4636); https://www.cdc.gov/ehrmeaningfuluse/.
    (1) HL7 Standard Code Set CVX--Vaccines Administered, July 30, 
2009, IBR approved for Sec.  170.207.
    (2) IIS: HL7 Standard Code Set CVX--Vaccines Administered, updates 
through July 11, 2012, IBR approved for Sec.  170.207.
    (3) Implementation Guide for Immunization Data Transactions using 
Version 2.3.1 of the Health Level Seven (HL7)Standard Protocol 
Implementation Guide Version 2.2, June 2006, IBR approved for Sec.  
170.205.
    (4) HL7 2.5.1 Implementation Guide for Immunization Messaging 
Release 1.0, May 1, 2010, IBR approved for Sec.  170.205.
    (5) PHIN Messaging Guide for Syndromic Surveillance: Emergency 
Department and Urgent Care Data, ADT Messages A01, A03, A04, and A08, 
HL7 Version 2.5.1 (Version 2.3.1 Compatible), Release 1.1, August 2012, 
IBR approved for Sec.  170.205.
    (6) Conformance Clarification for EHR Certification of Electronic 
Syndromic Surveillance, ADT MESSAGES A01, A03, A04, and A08, HL7 
Version 2.5.1, Addendum to PHIN Messaging Guide for Syndromic 
Surveillance: Emergency Department and Urgent Care Data (Release 1.1), 
August 2012, IBR approved for Sec.  170.205.
    (7) HL7 2.5.1 Implementation Guide for Immunization Messaging, 
Release 1.4, August 1, 2012, IBR approved for Sec.  170.205.
    (8) Implementation Guide for Ambulatory Healthcare Provider 
Reporting to Central Cancer Registries, HL7 Clinical Document 
Architecture (CDA), Release 1.0, August 2012, IBR approved for Sec.  
170.205.
    (9) ELR 2.5.1 Clarification Document for EHR Technology 
Certification, July 16, 2012, IBR approved for Sec.  170.205.
    (e) Centers for Medicare & Medicaid Services, Office of Clinical 
Standards and Quality, 7500 Security Boulevard, Baltimore, Maryland 
21244; Telephone (410) 786-3000
    (1) CMS PQRI 2009 Registry XML Specifications, IBR approved for 
Sec.  170.205.
    (2) 2009 Physician Quality Reporting Initiative Measure 
Specifications Manual for Claims and Registry, Version 3.0, December 8, 
2008 IBR approved for Sec.  170.205.

[[Page 54286]]

    (f) Health Level Seven, 3300 Washtenaw Avenue, Suite 227, Ann 
Arbor, MI 48104; Telephone (734) 677-7777 or https://www.hl7.org/
    (1) Health Level Seven Standard Version 2.3.1 (HL7 2.3.1), An 
Application Protocol for Electronic Data Exchange in Healthcare 
Environments, April 14, 1999, IBR approved for Sec.  170.205.
    (2) Health Level Seven Messaging Standard Version 2.5.1 (HL7 
2.5.1), An Application Protocol for Electronic Data Exchange in 
Healthcare Environments, February 21, 2007, IBR approved for Sec.  
170.205.
    (3) Health Level Seven Implementation Guide: Clinical Document 
Architecture (CDA) Release 2--Continuity of Care Document (CCD), April 
01, 2007, IBR approved for Sec.  170.205.
    (4) HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory 
Reporting to Public Health, Release 1 (US Realm) HL7 Version 2.5.1: 
ORU[supcaret]R01, HL7 Informative Document, February, 2010, IBR 
approved for Sec.  170.205.
    (5) HL7 Version 3 Standard: Context-Aware Retrieval Application 
(Infobutton); Release 1, July 2010, IBR approved for Sec.  170.204.
    (6) HL7 Version 3 Implementation Guide: URL-Based Implementations 
of the Context-Aware Information Retrieval (Infobutton) Domain, Release 
3, December 2010, IBR approved for Sec.  170.204.
    (7) HL7 Version 3 Implementation Guide: Context-Aware Knowledge 
Retrieval (Infobutton) Service-Oriented Architecture Implementation 
Guide, Release 1, HL7 Draft Standard for Trial Use, March 2011, IBR 
approved for Sec.  170.204.
    (8) HL7 Implementation Guide for CDA[supreg] Release 2: IHE Health 
Story Consolidation, DSTU Release 1.1 (US Realm) Draft Standard for 
Trial Use July 2012, IBR approved for Sec.  170.205.
    (9) HL7 Clinical Document Architecture, Release 2.0, Normative 
Edition, May 2005, IBR approved for Sec.  170.205.
    (10) HL7 Version 2.5.1 Implementation Guide: S&I Framework Lab 
Results Interface, Release 1--US Realm [HL7 Version 2.5.1: ORU-R01] 
Draft Standard for Trial Use, July 2012, IBR approved for Sec.  
170.205.
    (11) HL7 Version 3 Standard: Clinical Genomics; Pedigree, Release 
1, Edition 2011, March 2012, IBR approved for Sec.  170.207.
    (12) HL7 Implementation Guide for CDA[supreg] Release 2: Quality 
Reporting Document Architecture, DTSU Release 2 (Universal Realm), 
Draft Standard for Trial Use, July 2012, IBR approved for Sec.  
170.205.
    (13) HL7 v2.5.1 IG: Electronic Laboratory Reporting to Public 
Health (US Realm), Release 1 Errata and Clarifications, September, 29, 
2011, IBR approved for Sec.  170.205.
    (14) Quality Reporting Document Architecture Category III, Release 
1, Implementation Guide for CDA Release 2 (US Realm) Based on HL7 CDA 
Release 2.0, August 2012, IBR approved for Sec.  170.205.
    (g) Internet Engineering Task Force (IETF), University of Delaware, 
Newark, DE 19716, Telephone (302) 831-8247, https://www.ietf.org/rfc.html.
    (1) Network Time Protocol (Version 3) Specification, Implementation 
and Analysis, March 1992, IBR approved for Sec.  170.210.
    (2) Network Time Protocol Version 4: Protocol and Algorithms 
Specification, June 2010, IBR approved for Sec.  170.210.
    (h) Library of Congress, Network Development and MARC Standards 
Office, Washington, DC 20540-4402, Tel: (202) 707-6237 or https://www.loc.gov/standards/iso639-2/.
    (1) ISO 639-2. Codes for the Representation of Names of Languages 
Part 2: Alpha-3 Code, April 8, 2011, IBR approved for Sec.  170.207.
    (2) [Reserved]
    (i) National Council for Prescription Drug Programs, Incorporated, 
9240 E. Raintree Drive, Scottsdale, AZ 85260- 7518; Telephone (480) 
477-1000; and Facsimile (480) 767-1042 or https://www.ncpdp.org.
    (1) National Council for Prescription Drug Programs Prescriber/
Pharmacist Interface SCRIPT Standard, Implementation Guide, Version 8, 
Release 1, October 2005, IBR approved for Sec.  170.205.
    (2) SCRIPT Standard, Implementation Guide, Version 10.6, October, 
2008, (Approval date for ANSI: November 12, 2008), IBR approved for 
Sec.  170.205.
    (j) National Institute of Standards and Technology, Information 
Technology Laboratory, National Institute of Standards and Technology, 
100 Bureau Drive, Gaithersburg, MD 20899-8930, https://csrc.nist.gov/groups/STM/cmvp/standards.html.
    (1) Annex A: Approved Security Functions for FIPS PUB 140-2, 
Security Requirements for Cryptographic Modules, Draft, January 27, 
2010, IBR approved for Sec.  170.210.
    (2) Annex A: Approved Security Functions for FIPS PUB 140-2, 
Security Requirements for Cryptographic Modules, Draft, May 30, 2012, 
IBR approved for Sec.  170.210.
    (k) Office of the National Coordinator for Health Information 
Technology (ONC), 200 Independence Avenue SW., Suite 729-D, Washington, 
DC 20201, https://healthit.hhs.gov.
    (1) Applicability Statement for Secure Health Transport, Version 
1.1, July 10, 2012, IBR approved for Sec.  170.202; available at https://healthit.hhs.gov/portal/server.pt/community/healthit_hhs_gov__direct_project/3338.
    (2) XDR and XDM for Direct Messaging Specification, Version 1, 
March 9, 2011, IBR approved for Sec.  170.202; available at https://healthit.hhs.gov/portal/server.pt/community/healthit_hhs_gov__direct_project/3338.
    (3) Transport and Security Specification, Version 1.0, June 19, 
2012, IBR approved for Sec.  170.202.
    (l) Regenstrief Institute, Inc., LOINC[supreg] c/o Medical 
Informatics The Regenstrief Institute, Inc 410 West 10th Street, Suite 
2000 Indianapolis, IN 46202-3012; Telephone (317) 423-5983 or https://loinc.org/.
    (1) Logical Observation Identifiers Names and Codes (LOINC[supreg]) 
version 2.27, June 15, 2009, IBR approved for Sec.  170.207.
    (2) Logical Observation Identifiers Names and Codes (LOINC[supreg]) 
Database version 2.40, Released June 2012, IBR approved for Sec.  
170.207.
    (m) U.S. National Library of Medicine, 8600 Rockville Pike, 
Bethesda, MD 20894; Telephone (301) 594-5983 or https://www.nlm.nih.gov/.
    (1) International Health Terminology Standards Development 
Organization Systematized Nomenclature of Medicine Clinical Terms 
(SNOMED CT[supreg]), International Release, July 2009, IBR approved for 
Sec.  170.207.
    (2) International Health Terminology Standards Development 
Organisation (IHTSDO) Systematized Nomenclature of Medicine Clinical 
Terms (SNOMED CT[supreg]) International Release July 31, 2012, IBR 
approved for Sec.  170.207.
    (3) US Extension to SNOMED CT[supreg] March 2012 Release, IBR 
approved for Sec.  170.207.
    (4) RxNorm, August 6, 2012 Full Release Update, IBR approved for 
Sec.  170.207.
    (5) Data Element Catalog, Version: August 2012, IBR approved for 
Sec.  170.204.
    (n) World Wide Web Consortium (W3C)/MIT, 32 Vassar Street, Room 32-
G515, Cambridge, MA 02139 USA, https://www.w3.org/standards/
    (1) Web Content Accessibility Guidelines (WCAG) 2.0, December 11, 
2008, IBR approved for Sec.  170.204.
    (2) [Reserved]

0
9. In Sec.  170.300, republish paragraphs (a) and (b), revise paragraph 
(c) and add paragraph (d) to read as follows:

[[Page 54287]]

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

0
10. Add Sec.  170.314 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 completed and acted upon during 
computerized provider order entry (CPOE), interventions must 
automatically and electronically indicate to a user drug-drug and drug-
allergy contraindications based on a patient's medication list and 
medication allergy list.
    (ii) Adjustments. (A) Enable the severity level of interventions 
provided for drug-drug interaction checks to be adjusted.
    (B) Limit the ability to adjust severity levels to an identified 
set of users or available as a system administrative function.
    (3) Demographics. (i) Enable a user to electronically record, 
change, and access patient demographic data including preferred 
language, sex, race, ethnicity, and date of birth.
    (A) Enable race and ethnicity to be recorded in accordance with the 
standard specified in Sec.  170.207(f) and whether a patient declines 
to specify race and/or ethnicity.
    (B) Enable preferred language to be recorded in accordance with the 
standard specified in Sec.  170.207(g) 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.
    (4) Vital signs, body mass index, and growth charts. (i) Vital 
signs. Enable a user to electronically record, change, and access, at a 
minimum, a patient's height/length, weight, and blood pressure. Height/
length, weight, and blood pressure must be recorded in numerical values 
only.
    (ii) Calculate body mass index. Automatically calculate and 
electronically display body mass index based on a patient's height and 
weight.
    (iii) Optional--Plot and display growth charts. Plot and 
electronically display, upon request, growth charts for patients.
    (5) Problem list. Enable a user to electronically record, change, 
and access a patient's active problem list:
    (i) Ambulatory setting. Over multiple encounters in accordance 
with, at a minimum, the version of the standard specified in Sec.  
170.207(a)(3); or
    (ii) Inpatient setting. For the duration of an entire 
hospitalization in accordance with, at a minimum, the version of the 
standard specified in Sec.  170.207(a)(3).
    (6) Medication list. Enable a user to electronically record, 
change, and access a patient's active medication list as well as 
medication history:
    (i) Ambulatory setting. Over multiple encounters; or
    (ii) Inpatient setting. For the duration of an entire 
hospitalization.
    (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:
    (i) Ambulatory setting. Over multiple encounters; or
    (ii) Inpatient setting. For the duration of an entire 
hospitalization.
    (8) Clinical decision support. (i) Evidence-based decision support 
interventions. Enable a limited set of identified users to select 
(i.e., activate) one or more electronic clinical decision support 
interventions (in addition to drug-drug and drug-allergy 
contraindication checking) based on each one and at least one 
combination of the following data:
    (A) Problem list;
    (B) Medication list;
    (C) Medication allergy list;
    (D) Demographics;
    (E) Laboratory tests and values/results; and
    (F) Vital signs.
    (ii) Linked referential clinical decision support. (A) EHR 
technology must be able to:
    (1) Electronically identify for a user diagnostic and therapeutic 
reference information; or
    (2) Electronically identify for a user diagnostic and therapeutic 
reference information in accordance with the standard specified at 
Sec.  170.204(b) and the implementation specifications at Sec.  170.204 
(b)(1) or (2).
    (B) For paragraph (a)(8)(ii)(A) of this section, EHR technology 
must be able to electronically identify for a user diagnostic or 
therapeutic reference information based on each one and at least one 
combination of the data referenced in paragraphs (a)(8)(i)(A) through 
(F) of this section.
    (iii) Clinical decision support configuration. (A) Enable 
interventions and reference resources specified in paragraphs (a)(8)(i) 
and (ii) of this section to be configured by a limited set of 
identified users (e.g., system administrator) based on a user's role.
    (B) EHR technology must enable interventions to be electronically 
triggered:
    (1) Based on the data referenced in paragraphs (a)(8)(i)(A) through 
(F) of this section.
    (2) When a patient's medications, medication allergies, and 
problems are incorporated from a transition of care/referral summary 
received pursuant to paragraph (b)(1)(iii) of this section.
    (3) Ambulatory setting only. When a patient's laboratory tests and 
values/results are incorporated pursuant to paragraph (b)(5)(i)(A)(1) 
of this section.
    (iv) Automatically and electronically interact. Interventions 
triggered 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 as 
indicated for all clinical decision support resources:
    (A) For evidence-based decision support interventions under 
paragraph (a)(8)(i) of this section:

[[Page 54288]]

    (1) Bibliographic citation of the intervention (clinical research/
guideline);
    (2) Developer of the intervention (translation from clinical 
research/guideline);
    (3) Funding source of the intervention development technical 
implementation; and
    (4) Release and, if applicable, revision date(s) of the 
intervention or reference source.
    (B) For linked referential clinical decision support in paragraph 
(a)(8)(ii) of this section and drug-drug, drug-allergy interaction 
checks in paragraph(a)(2) of this section, the developer of the 
intervention, and where clinically indicated, the bibliographic 
citation of the intervention (clinical research/guideline).
    (9) Electronic notes. Enable a user to electronically record, 
change, access, and search electronic notes.
    (10) Drug-formulary checks. EHR technology must automatically and 
electronically check whether a drug formulary (or preferred drug list) 
exists for a given patient and medication.
    (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(h).
    (12) Image results. Electronically indicate to a user the 
availability of a patient's images and narrative interpretations 
(relating to the radiographic or other diagnostic test(s)) and enable 
electronic access to such images and narrative interpretations.
    (13) Family health history. Enable a user to electronically record, 
change, and access a patient's family health history according to:
    (i) At a minimum, the version of the standard specified in Sec.  
170.207(a)(3); or
    (ii) The standard specified in Sec.  170.207(j).
    (14)  Patient list creation. Enable a user to electronically and 
dynamically select, sort, access, and create patient lists by: date and 
time; and based on each one and at least one combination of the 
following data:
    (i) Problems;
    (ii) Medications;
    (iii) Medication allergies;
    (iv) Demographics;
    (v) Laboratory tests and values/results; and
    (vi) Ambulatory setting only. Patient communication preferences.
    (15) Patient-specific education resources. EHR technology must be 
able to electronically identify for a user patient-specific education 
resources based on data included in the patient's problem list, 
medication list, and laboratory tests and values/results:
    (i) In accordance with the standard specified at Sec.  170.204(b) 
and the implementation specifications at Sec.  170.204(b)(1) or (2); 
and
    (ii) By any means other than the method specified in paragraph 
(a)(15)(i) of this section.
    (16) 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)(16)(i)(A) through (E) of this section, enable a user to 
electronically verify the following before administering medication(s):
    (A) Right patient. The patient to whom the medication is to be 
administered matches the medication to be administered.
    (B) Right medication. The medication to be administered matches the 
medication ordered for the patient.
    (C) Right dose. The dose of the medication to be administered 
matches the dose of the medication ordered for the patient.
    (D) Right route. The route of medication delivery matches the route 
specified in the medication order.
    (E) Right time. The time that the medication was ordered to be 
administered compared to the current time.
    (ii) Right documentation. Electronically record the time and date 
in accordance with the standard specified in Sec.  170.210(g), and user 
identification when a medication is administered.
    (17) 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--receive, display, 
and incorporate transition of care/referral summaries. (i) Receive. EHR 
technology must be able to electronically receive transition of care/
referral summaries in accordance with:
    (A) The standard specified in Sec.  170.202(a).
    (B) Optional. The standards specified in Sec.  170.202(a) and (b).
    (C) Optional. The standards specified in Sec.  170.202(b) and (c).
    (ii) Display. EHR technology must be able to electronically display 
in human readable format the data included in transition of care/
referral summaries received and formatted according to any of the 
following standards (and applicable implementation specifications) 
specified in: Sec.  170.205(a)(1), Sec.  170.205(a)(2), and Sec.  
170.205(a)(3).
    (iii) Incorporate. Upon receipt of a transition of care/referral 
summary formatted according to the standard adopted at Sec.  
170.205(a)(3), EHR technology must be able to:
    (A) Correct patient. Demonstrate that the transition of care/
referral summary received is or can be properly matched to the correct 
patient.
    (B) Data incorporation. Electronically incorporate the following 
data expressed according to the specified standard(s):
    (1) Medications. At a minimum, the version of the standard 
specified in Sec.  170.207(d)(2);
    (2) Problems. At a minimum, the version of the standard specified 
in Sec.  170.207(a)(3);
    (3) Medication allergies. At a minimum, the version of the standard 
specified in Sec.  170.207(d)(2).
    (C) Section views. Extract and allow for individual display each 
additional section or sections (and the accompanying document header 
information) that were included in a transition of care/referral 
summary received and formatted in accordance with the standard adopted 
at Sec.  170.205(a)(3).
    (2) Transitions of care--create and transmit transition of care/
referral summaries. (i) Create. Enable a user to electronically create 
a transition of care/referral summary formatted according to the 
standard adopted at Sec.  170.205(a)(3) that includes, at a minimum, 
the Common MU Data Set and the following data expressed, where 
applicable, according to the specified standard(s):
    (A) Encounter diagnoses. The standard specified in Sec.  170.207(i) 
or, at a minimum, the version of the standard specified Sec.  
170.207(a)(3);
    (B) Immunizations. The standard specified in Sec.  170.207(e)(2);
    (C) Cognitive status;
    (D) Functional status; and
    (E) Ambulatory setting only. The reason for referral; and referring 
or transitioning provider's name and office contact information.
    (F) Inpatient setting only. Discharge instructions.
    (ii) Transmit. Enable a user to electronically transmit the 
transition of care/referral summary created in paragraph (b)(2)(i) of 
this section in accordance with:
    (A) The standard specified in Sec.  170.202(a).
    (B) Optional. The standards specified in Sec.  170.202(a) and (b).
    (C) Optional. The standards specified in Sec.  170.202(b) and (c).
    (3) Electronic prescribing. Enable a user to electronically create 
prescriptions and prescription-related

[[Page 54289]]

information for electronic transmission in accordance with:
    (i) The standard specified in Sec.  170.205(b)(2); and
    (ii) At a minimum, the version of the standard specified in Sec.  
170.207(d)(2).
    (4) Clinical information reconciliation. Enable a user to 
electronically reconcile the data that represent a patient's active 
medication, problem, and medication allergy list as follows. For each 
list type:
    (i) Electronically and simultaneously display (i.e., in a single 
view) the data from at least two list sources in a manner that allows a 
user to view the data and their attributes, which must include, at a 
minimum, the source and last modification date.
    (ii) Enable a user to create a single reconciled list of 
medications, medication allergies, or problems.
    (iii) Enable a user to review and validate the accuracy of a final 
set of data 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 and 
incorporate clinical laboratory tests and values/results in accordance 
with the standard specified in Sec.  170.205(j) and, at a minimum, the 
version of the standard specified in Sec.  170.207(c)(2).
    (2) Electronically display the tests and values/results received in 
human readable format.
    (B) Inpatient setting only. Electronically receive clinical 
laboratory tests and values/results in a structured format and 
electronically display such tests and values/results in human readable 
format.
    (ii) Electronically display all the information for a test report 
specified at 42 CFR 493.1291(c)(1) through (7).
    (iii) Electronically attribute, associate, or link a laboratory 
test and value/result with a laboratory order or patient record.
    (6) Inpatient setting only--transmission of electronic laboratory 
tests and values/results to ambulatory providers. EHR technology must 
be able to electronically create laboratory test reports for electronic 
transmission in accordance with the standard specified in Sec.  
170.205(j) and with laboratory tests expressed in accordance with, at a 
minimum, the version of the standard specified in Sec.  170.207(c)(2).
    (7) Data portability. Enable a user to electronically create a set 
of export summaries for all patients in EHR technology formatted 
according to the standard adopted at Sec.  170.205(a)(3) that 
represents the most current clinical information about each patient and 
includes, at a minimum, the Common MU Data Set and the following data 
expressed, where applicable, according to the specified standard(s):
    (i) Encounter diagnoses. The standard specified in Sec.  170.207(i) 
or, at a minimum, the version of the standard at Sec.  170.207(a)(3);
    (ii) Immunizations. The standard specified in Sec.  170.207(e)(2);
    (iii) Cognitive status;
    (iv) Functional status; and
    (v) Ambulatory setting only. The reason for referral; and referring 
or transitioning provider's name and office contact information.
    (vi) Inpatient setting only. Discharge instructions.
    (c) Clinical quality measures. (1) Clinical Quality Measures--
capture and export. (i) Capture. For each and every CQM for which the 
EHR technology is presented for certification, EHR technology must be 
able to electronically record all of the data identified in the 
standard specified at Sec.  170.204(c) that would be necessary to 
calculate each CQM. Data required for CQM exclusions or exceptions must 
be codified entries, which may include specific terms as defined by 
each CQM, or may include codified expressions of ``patient reason,'' 
``system reason,'' or ``medical reason.''
    (ii) Export. EHR technology must be able to electronically export a 
data file formatted in accordance with the standards specified at Sec.  
170.205(h) that includes all of the data captured for each and every 
CQM to which EHR technology was certified under paragraph (c)(1)(i) of 
this section.
    (2) Clinical quality measures--import and calculate. (i) Import. 
EHR technology must be able to electronically import a data file 
formatted in accordance with the standard specified at Sec.  170.205(h) 
and use such data to perform the capability specified in paragraph 
(c)(2)(ii) of this section. EHR technology presented for certification 
to all three of the certification criteria adopted in paragraphs (c)(1) 
through (3) of this section is not required to meet paragraph 
(c)(2)(i).
    (ii) Calculate. EHR technology must be able to electronically 
calculate each and every clinical quality measure for which it is 
presented for certification.
    (3) Clinical quality measures--electronic submission. Enable a user 
to electronically create a data file for transmission of clinical 
quality measurement data:
    (i) In accordance with the standards specified at Sec.  170.205(h) 
and (k); and
    (ii) That can be electronically accepted by CMS.
    (d) Privacy and security. (1) Authentication, access control, and 
authorization. (i) Verify against a unique identifier(s) (e.g., 
username or number) that a person seeking access to electronic health 
information is the one claimed; and
    (ii) Establish the type of access to electronic health information 
a user is permitted based on the unique identifier(s) provided in 
paragraph (d)(1)(i) of this section, and the actions the user is 
permitted to perform with the EHR technology.
    (2) Auditable events and tamper-resistance. (i) Record actions. EHR 
technology must be able to:
    (A) Record actions related to electronic health information in 
accordance with the standard specified in Sec.  170.210(e)(1);
    (B) Record the audit log status (enabled or disabled) in accordance 
with the standard specified in Sec.  170.210(e)(2) unless it cannot be 
disabled by any user; and
    (C) Record the encryption status (enabled or disabled) of 
electronic health information locally stored on end-user devices by EHR 
technology in accordance with the standard specified in Sec.  
170.210(e)(3) unless the EHR technology prevents electronic health 
information from being locally stored on end-user devices (see 
170.314(d)(7) of this section).
    (ii) Default setting. EHR technology must be set by default to 
perform the capabilities specified in paragraph (d)(2)(i)(A) of this 
section and, where applicable, paragraphs (d)(2)(i)(B) or (C), or both 
paragraphs (d)(2)(i)(B) and (C).
    (iii) When disabling the audit log is permitted. For each 
capability specified in paragraphs (d)(2)(i)(A) through (C) of this 
section that EHR technology permits to be disabled, the ability to do 
so must be restricted to a limited set of identified users.
    (iv) Audit log protection. Actions and statuses recorded in 
accordance with paragraph (d)(2)(i) of this section must not be capable 
of being changed, overwritten, or deleted by the EHR technology.
    (v) Detection. EHR technology must be able to detect whether the 
audit log has been altered.
    (3) Audit report(s). Enable a user to create an audit report for a 
specific time period and to sort entries in the audit log according to 
each of the data specified in the standards at Sec.  170.210(e).
    (4) Amendments. Enable a user to electronically select the record 
affected by a patient's request for amendment and perform the 
capabilities specified in paragraphs (d)(4)(i) or (ii) of this section.

[[Page 54290]]

    (i) Accepted amendment. For an accepted amendment, append the 
amendment to the affected record or include a link that indicates the 
amendment's location.
    (ii) Denied amendment. For a denied amendment, at a minimum, append 
the request and denial of the request to the affected record or include 
a link that indicates this information's location.
    (5) Automatic log-off. Prevent a user from gaining further access 
to an electronic session after a predetermined time of inactivity.
    (6) Emergency access. Permit an identified set of users to access 
electronic health information during an emergency.
    (7) End-user device encryption. Paragraph (d)(7)(i) or (ii) of this 
section must be met to satisfy this certification criterion.
    (i) EHR technology that is designed to locally store electronic 
health information on end-user devices must encrypt the electronic 
health information stored on such devices after use of EHR technology 
on those devices stops.
    (A) Electronic health information that is stored must be encrypted 
in accordance with the standard specified in Sec.  170.210(a)(1).
    (B) Default setting. EHR technology must be set by default to 
perform this capability and, unless this configuration cannot be 
disabled by any user, the ability to change the configuration must be 
restricted to a limited set of identified users.
    (ii) EHR technology is designed to prevent electronic health 
information from being locally stored on end-user devices after use of 
EHR technology on those devices stops.
    (8) Integrity. (i) Create a message digest in accordance with the 
standard specified in Sec.  170.210(c).
    (ii) Verify in accordance with the standard specified in Sec.  
170.210(c) upon receipt of electronically exchanged health information 
that such information has not been altered.
    (9) 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) EHR technology must provide patients (and their authorized 
representatives) with an online means to view, download, and transmit 
to a 3rd party the data specified below. Access to these capabilities 
must be through a secure channel that ensures all content is encrypted 
and integrity-protected in accordance with the standard for encryption 
and hashing algorithms specified at Sec.  170.210(f).
    (A) View. Electronically view in accordance with the standard 
adopted at Sec.  170.204(a), at a minimum, the following data:
    (1) The Common MU Data Set (which should be in their English (i.e., 
non-coded) representation if they associate with a vocabulary/code 
set).
    (2) Ambulatory setting only. Provider's name and office contact 
information.
    (3) Inpatient setting only. Admission and discharge dates and 
locations; discharge instructions; and reason(s) for hospitalization.
    (B) Download. (1) Electronically download an ambulatory summary or 
inpatient summary (as applicable to the EHR technology setting for 
which certification is requested) in human readable format or formatted 
according to the standard adopted at Sec.  170.205(a)(3) that includes, 
at a minimum, the following data (which, for the human readable 
version, should be in their English representation if they associate 
with a vocabulary/code set):
    (i) Ambulatory setting only. All of the data specified in paragraph 
(e)(1)(i)(A)(1) and (2) of this section.
    (ii) Inpatient setting only. All of the data specified in 
paragraphs (e)(1)(i)(A)(1) and (3) of this section.
    (2) Inpatient setting only. Electronically download transition of 
care/referral summaries that were created as a result of a transition 
of care (pursuant to the capability expressed in the certification 
criterion adopted at paragraph (b)(2) of this section).
    (C) Transmit to third party. (1) Electronically transmit the 
ambulatory summary or inpatient summary (as applicable to the EHR 
technology setting for which certification is requested) created in 
paragraph (e)(1)(i)(B)(1) of this section in accordance with the 
standard specified in Sec.  170.202(a).
    (2) Inpatient setting only. Electronically transmit transition of 
care/referral summaries (as a result of a transition of care/referral) 
selected by the patient (or their authorized representative) in 
accordance with the standard specified in Sec.  170.202(a).
    (ii) Activity history log. (A) When electronic health information 
is viewed, downloaded, or transmitted to a third-party using the 
capabilities included in paragraphs (e)(1)(i)(A) through (C) of this 
section, the following information must be recorded and made accessible 
to the patient:
    (1) The action(s) (i.e., view, download, transmission) that 
occurred;
    (2) The date and time each action occurred in accordance with the 
standard specified at Sec.  170.210(g); and
    (3) The user who took the action.
    (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 summary. (i) Create. Enable a 
user to create a clinical summary for a patient in human readable 
format and formatted according to the standards adopted at Sec.  
170.205(a)(3).
    (ii) Customization. Enable a user to customize the data included in 
the clinical summary.
    (iii) Minimum data from which to select. EHR technology must permit 
a user to select, at a minimum, the following data when creating a 
clinical summary:
    (A) Common MU Data Set (which, for the human readable version, 
should be in their English representation if they associate with a 
vocabulary/code set)
    (B) The provider's name and office contact information; date and 
location of visit; reason for visit; immunizations and/or medications 
administered during the visit; diagnostic tests pending; clinical 
instructions; future appointments; referrals to other providers; future 
scheduled tests; and recommended patient decision aids.
    (3) Ambulatory setting only--secure messaging. Enable a user to 
electronically send messages to, and receive messages from, a patient 
in a manner that ensures:
    (i) Both the patient (or authorized representative) and EHR 
technology user are authenticated; and
    (ii) The message content is encrypted and integrity-protected in 
accordance with the standard for encryption and hashing algorithms 
specified at Sec.  170.210(f).
    (f) Public health. (1) Immunization information. Enable a user to 
electronically record, change, and access immunization information.
    (2) Transmission to immunization registries. EHR technology must be 
able to electronically create immunization information for electronic 
transmission in accordance with:
    (i) The standard and applicable implementation specifications 
specified in Sec.  170.205(e)(3); and
    (ii) At a minimum, the version of the standard specified in Sec.  
170.207(e)(2).
    (3) Transmission to public health agencies--syndromic surveillance. 
EHR technology must be able to

[[Page 54291]]

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).
    (4) Inpatient setting only--transmission of reportable laboratory 
tests and values/results. EHR technology must be able to electronically 
create reportable laboratory tests and values/results for electronic 
transmission in accordance with:
    (i) The standard (and applicable implementation specifications) 
specified in Sec.  170.205(g); and
    (ii) At a minimum, the versions of the standards specified in Sec.  
170.207(a)(3) and (c)(2).
    (5) Optional--ambulatory setting only--cancer case information. 
Enable a user to electronically record, change, and access cancer case 
information.
    (6) Optional--ambulatory setting only--transmission to cancer 
registries. EHR technology must be able to electronically create cancer 
case information for electronic transmission in accordance with:
    (i) The standard (and applicable implementation specifications) 
specified in Sec.  170.205(i); and
    (ii) At a minimum, the versions of the standards specified in Sec.  
170.207(a)(3) and (c)(2).
    (g) Utilization. (1) Automated numerator recording. For each 
meaningful use objective with a percentage-based measure, EHR 
technology must be able to create a report or file that enables a user 
to review the patients or actions that would make the patient or action 
eligible to be included in the measure's numerator. The information in 
the report or file created must be of sufficient detail such that it 
enables a user to match those patients or actions to meet the measure's 
denominator limitations when necessary to generate an accurate 
percentage.
    (2) Automated measure calculation. For each meaningful use 
objective with a percentage-based measure that is supported by a 
capability included in an EHR technology, electronically record the 
numerator and denominator and create a report including the numerator, 
denominator, and resulting percentage associated with each applicable 
meaningful use measure.
    (3) Safety-enhanced design. User-centered design processes must be 
applied to each capability an EHR technology includes that is specified 
in the following certification criteria: Sec.  170.314(a)(1), (2), (6) 
through (8), and (16) and (b)(3) and (4).
    (4) Quality management system. For each capability that an EHR 
technology includes and for which that capability's certification is 
sought, the use of a Quality Management System (QMS) in the 
development, testing, implementation and maintenance of that capability 
must be identified.
    (i) If a single QMS was used for applicable capabilities, it would 
only need to be identified once.
    (ii) If different QMS were applied to specific capabilities, each 
QMS applied would need to be identified. This would include the 
application of a QMS to some capabilities and none to others.
    (iii) If no QMS was applied to all applicable capabilities such a 
response is acceptable to satisfy this certification criterion.


Sec. Sec.  170.500 through 170.599  [Amended]

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

0
12. 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).
* * * * *

0
13. In Sec.  170.523, republish the introductory text, add paragraph 
(f)(8), revise paragraphs (k)(1)(i) and (ii), and add paragraph 
(k)(1)(iii) 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'';
    (ii) The information an ONC-ACB is required to report to the 
National Coordinator under paragraph (f) of this section for the 
specific Complete EHR or EHR Module at issue; and
    (iii) Any additional types of costs that an EP, EH, or CAH would 
pay to implement the Complete EHR's or EHR Module's capabilities in 
order to attempt to meet meaningful use objectives and measures. EHR 
technology self-developers are excluded from this requirement.
* * * * *

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

[[Page 54292]]

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 is presented for 
certification to one or more listed certification criteria in Sec.  
170.314(g)(3); and
    (3) Section 170.314(g)(4).
* * * * *

0
15. 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: August 21, 2012.
Kathleen Sebelius,
Secretary.
[FR Doc. 2012-20982 Filed 8-23-12; 2:30 pm]
BILLING CODE 4150-45-P