Donate $25 for two DVDs of the Cryptome collection of files from June 1996 to the present

Natsios Young Architects


28 July 2010


[Federal Register: July 28, 2010 (Volume 75, Number 144)]
[Rules and Regulations]               
[Page 44589-44654]
From the Federal Register Online via GPO Access [wais.access.gpo.gov]
[DOCID:fr28jy10-23]                         


[[Page 44589]]

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

Part III





Department of Health and Human Services





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



45 CFR Part 170



Health Information Technology: Initial Set of Standards, Implementation 
Specifications, and Certification Criteria for Electronic Health Record 
Technology; Final Rule


[[Page 44590]]


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

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Office of the Secretary

45 CFR Part 170

RIN 0991-AB58

 
Health Information Technology: Initial Set of Standards, 
Implementation Specifications, and Certification Criteria for 
Electronic Health Record Technology

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

ACTION: Final rule.

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

SUMMARY: The Department of Health and Human Services (HHS) is issuing 
this final rule to complete the adoption of an initial set of 
standards, implementation specifications, and certification criteria, 
and to more closely align such standards, implementation 
specifications, and certification criteria with final meaningful use 
Stage 1 objectives and measures. Adopted certification criteria 
establish the required 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 Stage 1 by eligible professionals, 
eligible hospitals, and/or critical access hospitals (hereafter, 
references to ``eligible hospitals'' in this final rule shall mean 
``eligible hospitals and/or critical access hospitals'') under the 
Medicare and Medicaid EHR Incentive Programs. Complete EHRs and EHR 
Modules will be tested and certified according to adopted certification 
criteria to ensure that they have properly implemented adopted 
standards and implementation specifications and otherwise comply with 
the adopted certification criteria.

DATES: Effective Date: This final rule is effective August 27, 2010. 
The incorporation by reference of certain publications listed in the 
rule is approved by the Director of the Federal Register as of August 
27, 2010.

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:

Acronyms

ANSI American National Standards Institute
CAH Critical Access Hospital
CCD Continuity of Care Document
CCHIT Certification Commission for Health Information Technology
CCR Continuity of Care Record
CDA Clinical Document Architecture
CDC Centers for Disease Control and Prevention
CFR Code of Federal Regulations
CGD Certification Guidance Document
CMS Centers for Medicare & Medicaid Services
CPOE Computerized Provider Order Entry
EHR Electronic Health Record
FIPS Federal Information Processing Standards
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
HITSP Healthcare Information Technology Standards Panel
HL7 Health Level Seven
ICD International Classification of Diseases
ICD-9-CM International Classification of Diseases, 9th Revision, 
Clinical Modification
ICD-10-PCS International Classification of Diseases, 10th Revision, 
Procedure Coding System
ICD-10-CM International Classification of Diseases, 10th Revision, 
Clinical Modification
IHS Indian Health Service
LOINC Logical Observation Identifiers Names and Codes
NCPDP National Council for Prescription Drug Programs
NLM National Library of Medicine
OCR Office for Civil Rights
OMB Office of Management and Budget
ONC Office of the National Coordinator for Health Information 
Technology
PHSA Public Health Service Act
PQRI Physician Quality Reporting Initiative
REST Representational state transfer
RFA Regulatory Flexibility Act
SNOMED-CT Systematized Nomenclature of Medicine Clinical Terms
SOAP Simple Object Access Protocol
UCUM Unified Code for Units of Measure
UMLS Unified Medical Language System
XML eXtensible Markup Language

Table of Contents

I. Background
    A. Legislative History
    B. Regulatory History
    1. Initial Set of Standards, Implementation Specifications, and 
Certification Criteria for EHR Technology Interim Final Rule
    2. Interdependencies With Other HITECH Provisions and 
Relationship to Other Regulatory Requirements
II. Overview of the Final Rule
III. Section-by-Section Discussion of the Final Rule and Response to 
Comments
    A. Introduction
    B. General Comments
    C. Definitions--Sec.  170.102
    1. Definition of Disclosure
    2. Definition of Standard
    3. Definition of Implementation Specification
    4. Definition of Certification Criteria
    5. Definition of Qualified EHR
    6. Definition of Complete EHR
    7. Definition of EHR Module
    8. Definition of Certified EHR Technology
    9. Definition of Human Readable Format
    10. Definition of User
    D. Final Rule Amendments to Adopted Standards, Implementation 
Specifications, and Certification Criteria Sec. Sec.  170.202, 
170.205, 170.207, 170.210, 170.302, 170.304, 170.306
    1. Flexibility and Innovation
    2. Transport Standards
    3. Certification Criteria and Associated Standards and 
Implementation Specifications
    a. General Certification for Complete EHRs or EHR Modules--Sec.  
170.302
    b. Specific Certification for Complete EHRs or EHR Modules 
Designed for an Ambulatory Setting--Sec.  170.304
    c. Specific Certification for Complete EHRs or EHR Modules 
Designed for an Inpatient Setting--Sec.  170.306
    d. Adoption and Realignment of Certification Criteria to Support 
the Final Requirements for Meaningful Use Stage 1.
    E. Additional Comments
    F. Comments Beyond the Scope of This Final Rule
IV. Collection of Information Requirements
V. Regulatory Impact Analysis
    A. Introduction
    B. Why is this rule needed?
    C. Executive Order 12866--Regulatory Planning and Review 
Analysis
    1. Comment and Response
    2. Executive Order 12866 Final Analysis
    a. Costs
    b. Benefits
    D. Regulatory Flexibility Act Analysis
    1. Comment and Response
    2. Final RFA Analysis
    E. Executive Order 13132--Federalism Regulation Text

I. Background

A. Legislative History

    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 (ARRA) (Pub. L. 111-
5), was enacted on February 17, 2009. The HITECH Act amended the Public 
Health Service Act (PHSA) and established ``Title XXX--Health 
Information Technology and Quality'' to improve health care quality, 
safety, and efficiency through the promotion of health information 
technology (HIT) and the electronic exchange of health information. 
Section 3004(b)(1) of the PHSA requires the Secretary of Health and 
Human Services (the Secretary) to adopt an initial set of standards, 
implementation specifications, and certification criteria by December 
31, 2009 to enhance the interoperability, functionality, utility, and 
security of

[[Page 44591]]

health information technology. Section 3004(b)(1) of the PHSA also 
permits the Secretary to adopt the initial set of standards, 
implementation specifications, and certification criteria on an 
interim, final basis.

B. Regulatory History

1. Initial Set of Standards, Implementation Specifications, and 
Certification Criteria for EHR Technology Interim Final Rule
    On December 30, 2009, the Federal Register made available for 
public inspection, an interim final rule (the Interim Final Rule) with 
a request for comments, which adopted an initial set of standards, 
implementation specifications, and certification criteria. As noted in 
this rulemaking (75 FR 2014), we described how Congress fundamentally 
tied the adopted standards, implementation specifications, and 
certification criteria to the incentives available under the Medicare 
and Medicaid EHR Incentive Programs by requiring the meaningful use of 
Certified EHR Technology. Congress outlined several goals for 
meaningful use, one of which included the ``use of certified EHR 
technology in a meaningful manner.'' This means that to qualify for 
incentives, an eligible professional or eligible hospital must both 
adopt Certified EHR Technology and demonstrate meaningful use of this 
technology.
    The initial set of standards, implementation specifications, and 
certification criteria adopted in the Interim Final Rule established 
the capabilities that Certified EHR Technology would need to include 
to, at a minimum, support eligible professionals' and eligible 
hospitals' efforts to achieve what had been proposed for meaningful use 
Stage 1 under the Medicare and Medicaid EHR Incentive Programs proposed 
rule.
2. Interdependencies With Other HITECH Provisions and Relationship to 
Other Regulatory Requirements
    In addition to our discussion of how the standards, implementation 
specifications, and certification criteria adopted in the Interim Final 
Rule correlated with the Medicare and Medicaid EHR Incentive Programs 
proposed rule, we also discussed our approach to align adopted 
standards, implementation specifications, and certification criteria 
with new and pending HITECH Act regulatory actions and with other 
already established regulatory requirements. We also explained our 
approach for aligning these standards, implementation specifications, 
and certification criteria with: the adopted standard and certification 
criterion related to the Health Insurance Portability and 
Accountability Act of 1996 (HIPAA) Privacy Rule Accounting of 
Disclosures Regulation under the HITECH Act; alignment with the HIPAA 
Privacy and Security Regulations; the Medicare Part D Electronic 
Prescribing Regulations; and the HIPAA Transactions and Code Sets 
Standards Regulations.

II. Overview of the Final Rule

    We are amending part 170 of title 45 of the Code of Federal 
Regulations (CFR) to complete the adoption of the initial set of 
standards, implementation specifications, and certification criteria as 
required by section 3004(b)(1) of the PHSA and realign them with the 
final objectives and measures established for meaningful use Stage 1. 
After reviewing and considering public comments on our adopted 
standards, implementation specifications, and certification criteria, 
we have made several revisions to support the final meaningful use 
objectives and measures, clarify certain certification criteria to 
resolve identified technical challenges related to some of the 
standards and implementation specifications we adopted, and to provide 
for additional flexibility.

III. Section-by-Section Discussion of the Final Rule and Response to 
Comments

A. Introduction

    This section summarizes the nearly 400 timely comments received by 
ONC related to the Interim Final Rule. In some cases, due to the 
simultaneous publication and topical similarity of the notice of 
proposed rulemaking for meaningful use Stage 1, commenters 
inadvertently submitted comments to our regulation docket on 
regulations.gov instead of the Centers for Medicare & Medicaid Services 
(CMS) regulation docket, and vice versa. Recognizing this oversight, 
CMS and ONC shared misplaced comments between the offices and we 
included within our review all comments that could be reasonably 
identified as comments on the Interim Final Rule.
    We have organized the preamble of this final rule along the 
following lines. First, we respond to general comments, including those 
related to the scope and applicability of the final rule that we 
believe are necessary to clarify upfront. Next, we respond to comments 
regarding the definitions of certain defined terms. We then respond to 
public comments on each certification criterion, and where an adopted 
certification criterion also references standards and implementation 
specifications, we include our response to public comments on the 
related standards and implementation specifications. These concepts 
were separately discussed in the Interim Final Rule and we believe that 
discussing the certification criteria together with associated 
standards and implementation specifications will improve the clarity of 
the final rule and will allow us to more fully address public comments 
in a broader context. We include the following table at the beginning 
of the discussion of each certification criterion section to illustrate 
the final meaningful use Stage 1 objectives for eligible professionals 
and eligible hospitals and to show how we have revised adopted 
certification criteria in response to the revised meaningful use 
objectives and measures and public comments.

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Eligible Professional and/or    Eligible           Interim Final Rule
 Eligible Hospital & Critical    Professional and/  Text: Certification
 Access Hospital Objective.      or Eligible        Criterion.
                                 Hospital &        Final Rule Text:
                                 Critical Access    Certification
                                 Hospital Measure.  Criterion.
------------------------------------------------------------------------

    Finally, in considering public comments on the Interim Final Rule, 
we analyzed whether we had structured the regulation text in an optimal 
and understandable manner. For several provisions, we received comments 
requesting additional clarification and we felt that the original 
regulatory structure contributed to the commenters' confusion. Because 
of those comments and in an effort to better structure the regulation 
text for future revisions, we have revised the structure conceptually 
to group content exchange standards and associated

[[Page 44592]]

implementation specifications and vocabulary standards, and separated 
them into different sections. In line with this ``conceptual'' 
restructuring, we have determined that specifying how a Complete EHR or 
EHR Module must comply with an adopted standard should be solely 
reflected in the certification criteria. As a result, several 
certification criteria have been revised to more clearly reflect how a 
Complete EHR or EHR Module must comply with adopted standards and, 
where applicable, the relevant adopted implementation specifications.

B. General Comments

    Some commenters appear to have misinterpreted or misunderstood the 
scope of the Interim Final Rule and the applicability of the adopted 
standards, implementation specifications, and certification criteria. 
We would therefore like to clarify these concepts at the beginning of 
this final rule and are providing the following responses to the 
relevant comments.
    Comments. Some commenters seem to have construed the adoption of 
standards, implementation specifications, and certification criteria as 
including requirements that apply to the health care providers that 
will use the Certified EHR Technology, rather than as required 
capabilities of the Certified EHR Technology itself. These commenters, 
for instance, questioned whether entities using Certified EHR 
Technology must comply with adopted standards and implementation 
specifications when electronically using or transmitting health 
information within or among components of the legal entity or 
alternatively whether the standards apply solely to transmissions 
between legal entities. Other commenters specifically requested 
clarification regarding the adopted standards that are required to be 
used internally within each provider's office, institution, or closed 
system and which standards are required for purposes of electronically 
exchanging health information among such entities. Some comments 
implied that the Interim Final Rule should have specified when an 
eligible professional or eligible hospital would be required to use 
adopted standards. One commenter specifically requested that the 
adopted standards apply only to the electronic exchange of health 
information between legal entities.
    Response. As stated in Sec.  170.101, we specify that ``[t]he 
standards, implementation specifications, and certification criteria 
adopted in this part apply to Complete EHRs and EHR Modules and the 
testing and certification of such Complete EHRs and EHR Modules.'' In 
Sec. Sec.  170.200 and 170.300, we further specify that ``[t]he 
standards and implementation specifications adopted in this part apply 
with respect to Complete EHRs and EHR Modules'' and that ``[t]he 
certification criteria adopted in this subpart apply to the testing and 
certification of Complete EHRs and EHR Modules.''
    The purpose of this final rule, therefore, is to adopt standards, 
implementation specifications, and certification criteria to test and 
certify that a Complete EHR or EHR Module provides certain 
capabilities, and where applicable, to require that those capabilities 
be implemented in accordance with adopted standards and implementation 
specifications. The adopted standards, implementation specifications, 
and certification criteria were not intended to impose independent 
requirements on the entities using Certified EHR Technology. Unlike 
certain other regulatory requirements to which eligible professionals 
or eligible hospitals may be subject, it is not within the intended 
scope of this final rule to specify the requirements for entities using 
Certified EHR Technology.
    We understand the commenters' point though that an adopted standard 
and implementation specification could apply equally to electronic 
transactions between legal entities as well as to transmissions within 
an entity. This final rule, however, is not intended to specify the 
conditions under which adopted standards and implementation 
specifications must be used, only that a Complete EHR or EHR Module, in 
order to be certified, must include specified capabilities that are 
implemented in accordance with those standards, implementation 
specifications, and certification criteria. We anticipate that other 
regulations, as well as the clinical and business needs of HIT users, 
anticipated efficiencies and desired quality improvements, and 
technical, architectural, and enterprise limitations will determine 
when entities will utilize the capabilities required of Certified EHR 
Technology. Additionally, we would note that Complete EHRs and EHR 
Modules will, in many cases, be tested and certified independent of the 
environment within which they will be implemented. Consequently, 
specifying when an entity that implements Certified EHR Technology must 
utilize a particular capability in its operating environment exceeds 
the scope of this rule.
    To further demonstrate this point, Certified EHR Technology 
implemented by an eligible professional will need to possess the 
capability to generate an electronic prescription according to one of 
the standards we have adopted. To specify the contexts in which an 
electronic prescription (generated according to the adopted standard) 
must be transmitted would go beyond the scope of certification. 
Moreover, it would raise a more serious and practical consideration. 
Attempting to specify when entities must utilize the capabilities of 
Certified EHR Technology would add an unnecessary level of complexity 
to this rule and create the potential for conflicts with other 
regulations promulgated by the HHS. For instance, HHS has already 
promulgated at least two sets of regulations identifying when health 
care providers need to use specific standards and the contexts in which 
those standards must be used. Under the HIPAA Transactions and Code 
Sets Standards regulations, HHS specifies at 45 CFR 162.923(a) that 
``[e]xcept as otherwise provided in this part, if a covered entity 
conducts with another covered entity (or within the same covered 
entity), using electronic media, a transaction for which the Secretary 
has adopted a standard under this part, the covered entity must conduct 
the transaction as a standard transaction.'' (Emphasis added.) 
Consequently, in the HIPAA context, covered entities must use adopted 
transaction standards for covered transactions both within the covered 
entities and with outside entities. The Medicare Part D electronic-
prescribing (e-prescribing) regulations implement a different approach 
for certain e-prescribing transactions. Health care providers that 
electronically prescribe Part D drugs for Part D eligible individuals 
under 42 CFR 423.160(a)(3)(iii), ``may use either HL7 messages or the 
NCPDP SCRIPT Standard to transmit prescriptions or prescription-related 
information internally when the sender and the recipient are part of 
the same legal entity. If an entity sends prescriptions outside the 
entity (for example, from an HMO to a non-HMO pharmacy), it must use 
the adopted NCPDP SCRIPT Standard or other applicable adopted 
standards.'' Therefore, we believe that it is unnecessary and outside 
of the intended scope of this rule to specify the contexts or 
circumstances under which adopted standards and implementation 
specifications must be utilized.
    Moreover, we anticipate that future meaningful use objectives and 
measures will specify, as necessary and appropriate, the conditions 
under which certain health care providers will need

[[Page 44593]]

to use adopted standards and implementation specifications. The 
context, for instance, governing when a standard must be used will, in 
some cases, be directly related to whether and how an eligible 
professional or eligible hospital must meaningfully use Certified EHR 
Technology. For example, a final meaningful use Stage 1 objective 
requires that eligible professionals and eligible hospitals use 
Certified EHR Technology to record demographics including, among other 
fields, race and ethnicity. While we have adopted the race and 
ethnicity codes published by the Office of Management and Budget (OMB), 
in the context Medicare and Medicaid EHR incentive programs, the 
meaningful use of Certified EHR Technology will dictate whether such 
codes must be used ``inside'' an organization. Another example of when 
a meaningful use objective establishes the context in which a standard 
must be used is the objective that requires eligible professionals and 
eligible hospitals to use Certified EHR Technology to maintain an up-
to-date problem list of current and active diagnoses. The measure 
associated with this objective requires that entries be recorded in 
``structured data'' and in this context we adopted ICD-9 or SNOMED-
CT[reg] to provide that structure. As a result, Certified EHR 
Technology must be capable of using ICD-9 or SNOMED-CT[reg] when an 
eligible professional or eligible hospital seeks to maintain an up-to-
date problem list.
    In other instances, the Department does not specify explicitly in 
regulation the context for certain meaningful use objectives and 
whether meaningful use of Certified EHR Technology would require the 
use of a standard for electronic transactions solely between two 
different legal entities, or for all transactions, or for most 
transactions with certain exemptions.
    Comments. Several commenters requested that we provide more 
information about the standards we expect the Secretary to adopt in 
order to support future stages of meaningful use. These commenters 
noted, along with referencing the timelines for making changes to HIT, 
that it would benefit the HIT industry if we could provide a roadmap, 
framework, or more descriptive ``glide path'' for future standards 
adoption activities.
    Response. We anticipate that future stages of meaningful use will 
require us to adopt additional standards, implementation 
specifications, and certification criteria. We also expect that 
standards we have adopted will continue to be revised and updated over 
time, to reflect current technology, changing medical practice and 
regulatory requirements. We will therefore need to continue to 
harmonize those adopted standards with other standards to support 
interoperability. We anticipate that the standards required to support 
future stages of meaningful use will need a framework that supports 
harmonization across different meaningful use scenarios and that 
supports early real world testing. We plan to work closely with the HIT 
Standards Committee to develop a forward looking agenda and to make 
known in advance the types of standards, implementation specifications, 
and certification criteria on which we will seek recommendations from 
the HIT Standards Committee. We believe this will benefit the HIT 
industry by providing greater transparency of the standards adoption 
activities and will serve as an early indication for the public of 
candidate standards that are being identified for possible adoption.

C. Definitions--Sec.  170.102

    In this section, we respond to public comment on the definitions 
adopted in the Interim Final Rule. We address the definition of 
Certified EHR Technology last after we provide clarifications related 
to the definitions of Complete EHR and EHR Module.
1. Definition of Disclosure
    Comments. A few commenters noted that the definition of disclosure 
was too broad or asked that we refine the adopted definition to be more 
limited and to only apply in certain circumstances. One commenter noted 
that this was a new definition.
    Response. As we explained in the preamble of the Interim Final 
Rule, this definition repeated the text specified at 45 CFR 160.103 
(the General Provisions section for the HIPAA regulations). Because the 
Interim Final Rule created a new part in Title 45 of the CFR, the 
definition of disclosure as it is used in the HIPAA regulations would 
not necessarily have applied to our use of the term in this rule. 
Therefore, to prevent unnecessary ambiguity for the regulated 
community, we adopted the definition of the term as it is defined at 45 
CFR 160.103.
    In light of public comment and to prevent any future regulatory 
inconsistency that would require rulemaking to correct, we have 
revisited our approach of repeating the text of the definition of 
disclosure from 45 CFR 160.103 and have decided to cross reference 45 
CFR 160.103 in the definition of disclosure. The final definition will 
read: disclosure is defined as it is in 45 CFR 160.103.
2. Definition of Standard
    Comment. A commenter stated that our definition of standard was 
comprehensive from a technical perspective, but believed the definition 
was incomplete from a policy perspective. The commenter argued 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. 
For that reason, the commenter suggested, in order for the definition 
to be whole from both a technical and policy perspective, we should add 
to the definition the phrase ``developed through the use of open, 
collaborative, consensus-based processes.''
    Response. While we appreciate the commenter's point, we believe 
that the proposed language is unnecessary and potentially problematic. 
Federal agencies are already required under the National Technology 
Transfer and Advancement Act of 1995 (NTTAA) (15 U.S.C. 3701 et seq.) 
and OMB Circular A-119 \1\ 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. In drafting the Interim Final Rule, we briefly 
discussed relevant provisions of the NTTAA and OMB Circular A-119, our 
compliance with the statute and the Circular, and we requested comments 
on our approach to the selection of standards. We also explained that 
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 the Interim Final Rule, 
we identified those instances in which we had and had not adopted 
voluntary consensus standards. In the instances in which we had not 
adopted voluntary consensus standards, we provided two principal 
reasons: first, that in most cases a voluntary consensus standard that 
could meet the requisite technical goals was simply unavailable; and 
second, that to the extent a potentially equivalent voluntary consensus 
standard was available, the standard was too limiting and did not meet 
our policy goals, including allowing for greater innovation by the 
industry. In

[[Page 44594]]

this final rule, we have adopted only voluntary consensus standards, 
except for two government-unique standards (CMS Physician Quality 
Reporting Initiative (PQRI) 2009 Registry XML Specification and the 
Office of Management and Budget Standards for Maintaining, Collecting, 
and Presenting Federal Data on Race and Ethnicity), a functional 
standard relating to vocabularies included in RxNorm, and the specified 
standards to protect electronic health information. We are aware of no 
voluntary consensus standards that would serve as alternatives to these 
standards for the purposes that we have identified. We encourage the 
HIT Standards Committee to obtain public input, hold hearings on, and 
recommend to the National Coordinator standards that have been 
developed or adopted by voluntary consensus standards bodies.
---------------------------------------------------------------------------

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

3. Definition of Implementation Specification
    We did not receive any comments applicable to the definition of 
implementation specification and consequently did not make any changes 
to the definition.
4. Definition of Certification Criteria
    Comments. One commenter expressly stated its support for our 
definition of certification criteria.
    Response. We appreciate the commenter's support for our definition 
of certification criteria and have not made any changes to the 
definition in this final rule.
5. Definition of Qualified EHR
    Comments. A couple of commenters asserted that there is uncertainty 
in the industry with respect to what constitutes an EHR due both to the 
seemingly inconsistent definitions of terms in the HITECH Act and to 
the alternative definitions published by different organizations and 
associations. The commenters made specific reference to the definition 
of ``Qualified Electronic Health Record'' (``Qualified EHR'') at 
section 3000 of the PHSA and to the term ``EHR'' found in the HITECH 
Act at section 13400 of Subtitle D. The latter defines EHR as ``an 
electronic record of health-related information on an individual that 
is created, gathered, managed, and consulted by authorized clinicians 
and staff.'' The former defines Qualified EHR as ``an electronic record 
of health-related information on an individual that: (1) Includes 
patient demographic and clinical health information, such as medical 
history and problem lists; and (2) has the capacity: (i) to provide 
clinical decision support; (ii) to support physician order entry; (iii) 
to capture and query information relevant to health care quality; and 
(iv) to exchange electronic health information with, and integrate such 
information from other sources.'' Both commenters recommended that the 
definition of Qualified EHR be clarified with one commenter suggesting 
that the definition should follow the definition of EHR as it relates 
to health care providers.
    Response. We appreciate these comments and recognize that the 
existence of multiple terms that include the word ``EHR'' can be 
confusing. However, we believe that Congress intended for HHS to apply 
the definition of a Qualified EHR found in section 3000 of the PHSA to 
this regulation for specific reasons that cannot be overlooked. As a 
result, we have decided not to adopt the recommendation to follow the 
definition of the term EHR that is found in Subtitle D of the HITECH 
Act. We discuss additional responses to comments on the definition of 
Qualified EHR below.
    Comments. A few commenters requested that we expand the definition 
of Qualified EHR to include a variety of additional functionality and 
that a Qualified EHR be able to comply with business or legal 
requirements. These comments requested that we add required elements 
for an EHR to constitute a Qualified EHR, including that the EHR: Have 
a record-keeping capability for legal purposes; include certain 
requirements for usability; enable health care providers to perform 
several other actions not specified in the definition; and that certain 
elements of patient demographic information be specified.
    Response. We understand the rationale behind these commenters' 
suggestions, but we do not believe that it is necessary to add more 
prerequisite capabilities to the definition of Qualified EHR. We 
believe Congress defined Qualified EHR to include a minimum level of 
capabilities. Furthermore, to meet the definition of Certified EHR 
Technology, a Qualified EHR must be certified in accordance with a 
certification program established by the National Coordinator. As a 
result, we believe that any additional capabilities a Qualified EHR 
would need to possess to allow an eligible professional or eligible 
hospital to be in a position to qualify for incentive payments under 
the Medicare and Medicaid EHR incentive programs will be more 
appropriately addressed through the Secretary's adoption of additional 
standards, implementation specifications, and certification criteria.
    Comments. Some commenters requested that we clarify some of the 
terms in the definition of Qualified EHR such as ``capture,'' 
``query,'' ``other sources,'' and ``relevant to health care quality'' 
with respect to how they related to Certified EHR Technology. Another 
commenter expressly stated that if we only intended to repeat the 
statutory definition of Qualified EHR without modification, we should 
at least clarify the meaning of demographic information.
    Response. We do not believe that additional clarity is needed or 
desirable for such terms because the meanings are context specific. The 
intended meanings of these terms will depend significantly on the 
contexts in which the terms are used and the associated capabilities of 
the Certified EHR Technology. The terms' meanings may also be affected 
by any standards and implementation specifications that are associated 
with those capabilities and adopted. In certain circumstances, for 
instance, the meaning of the phrase ``other sources'' as used in the 
definition of Qualified EHR will depend on the specific context in 
which electronic health information is being integrated or exchanged, 
and perhaps on whether the source is external to or internal within the 
Complete EHR or the EHR Module. Similarly, the meanings of the terms or 
phrases ``capture,'' ``query,'' ``relevant to health care quality'' and 
``demographic'' information may vary according the context of the 
required capabilities of the EHR technology. In each of these 
instances, we believe that the adopted certification criteria and 
meaningful use objectives and measures will provide these contexts, 
identify the associated required capabilities, and consequently clarify 
the intended meanings of these terms.
6. Definition of Complete EHR
    Comments. Some commenters supported our definition of Complete EHR 
and believed that it was understandable, sufficient, and reasonable. 
Other commenters, however, suggested that the definition of Complete 
EHR was too narrow, because the term is tied to only those 
certification criteria adopted by the Secretary. These commenters 
argued that the Complete EHR and the adopted certification criteria 
should be more comprehensive and should include functionality that is 
not presently required for a Complete EHR to achieve certification. 
Many of these commenters referenced the Health Level Seven (HL7) EHR 
System Functional Model (EHR-S

[[Page 44595]]

FM) and contended that what we had defined as a Complete EHR did not 
align with or include all of the functionality specified in the EHR-S 
FM. One commenter requested that we clarify what we meant by ``we fully 
expect some EHRs to have capabilities beyond those addressed by 
certification criteria'' when we made this point during our discussion 
of the definition of Complete EHR in the preamble of the Interim Final 
Rule. Other commenters recommended specific wording changes to the 
definition.
    Response. In the Interim Final Rule we defined Complete EHR to mean 
``EHR technology that has been developed to meet all applicable 
certification criteria adopted by the Secretary.'' We clarified that 
the term Complete EHR is ``meant to encompass EHR technology that can 
perform all of the applicable capabilities required by certification 
criteria adopted by the Secretary and distinguish it from EHR 
technology that cannot perform those capabilities.'' We believe that 
commenters misunderstood the scope and purpose of the regulatory 
definition and believe that the definition effectively fulfills its 
regulatory purpose. We intend for the definition of Complete EHR to be 
used to clearly identify EHR technology as being able to perform, at a 
minimum, all of the applicable capabilities required by certification 
criteria adopted by the Secretary, and thereby, as providing eligible 
professionals or eligible hospitals with the technical capabilities 
they need to support their achievement of meaningful use of Certified 
EHR Technology. It is in this context that we view such EHR technology 
as ``complete.''
    We recognize that many commenters recommended a definition of 
``Complete EHR'' that would be more comprehensive than the definition 
we provided. Many commenters contended that HIT exists and is available 
for eligible professionals and eligible hospitals to implement, and 
much of it includes a myriad of capabilities far surpassing the 
capabilities required to meet the definition of Complete EHR. We do not 
dispute that point. We also understand that the capabilities included 
in a Complete EHR, as defined for the purposes of this regulation, may 
not encompass all of the capabilities a specific eligible professional 
or eligible hospital or for that matter any health care provider, may 
deem essential to meet their unique business needs and use cases.
    This definition, however, does not in any way preclude any 
additional capabilities from being included in a Complete EHR or 
implemented in a complementary fashion. The definition sets forth a 
floor, not a ceiling, and serves to signify that once tested and 
certified to all applicable certification criteria, a Complete EHR 
meets the definition of Certified EHR Technology. For this reason, we 
did not seek to craft this definition in a way that signified that a 
Complete EHR would be able to provide all of the capabilities a health 
care provider desired or deemed necessary, or that the entity's EHR 
could only include the capabilities for which the Secretary has adopted 
certification criteria. Nor did we define Complete EHR according to a 
particular functional model, because doing so would have been 
inconsistent with the regulatory purpose of the definition.
    In light of public comment and to further clarify the regulatory 
purpose of the definition of Complete EHR as well as make clear that a 
Complete EHR should not be misinterpreted to mean EHR technology that 
is any more comprehensive than the certification criteria to which it 
was tested and certified, we have added the phrase ``at a minimum'' to 
the definition. The final definition of Complete EHR will therefore 
read ``EHR technology that has been developed to meet, at a minimum, 
all applicable certification criteria adopted by the Secretary.''
    As a related point, we would also note that an eligible 
professional or eligible hospital would need to use a capability that 
is included among the adopted certification criteria to meet the 
associated meaningful use objective or measure. The eligible 
professional or eligible hospital therefore could not attempt to use a 
capability that is superfluous to certification to demonstrate the 
meaningful use of ``Certified EHR Technology.'' We understand that the 
Medicare and Medicaid EHR Incentive Programs final rule discusses this 
issue more fully in several places, and we defer to those discussions 
concerning the requirements for achieving meaningful use of Certified 
EHR Technology.
    Comment. In the context of the definition of Complete EHR, one 
commenter asked for clarification regarding how many certification 
criteria a Complete EHR must be developed to meet.
    Response. For the purposes of meeting the definition of Complete 
EHR, EHR technology designed for an ambulatory setting (to be used by 
eligible professionals) must be certified to all of the certification 
criteria adopted at 45 CFR 170.302 and 45 CFR 170.304, and EHR 
technology designed for an inpatient setting (to be used by eligible 
hospitals) must be certified to all of the certification criteria 
adopted at 45 CFR 170.302 and 45 CFR 170.306.
7. Definition of EHR Module
    Comments. Numerous commenters strongly supported our inclusion of a 
modular approach to meet the definition of Certified EHR Technology. 
Many of these commenters saw this approach as a way to spur greater 
innovation in the HIT marketplace, provide more choices for health care 
providers, and generally broaden the appeal of HIT and expedite its 
adoption. Some commenters noted, however, that they believed the 
definition needed further clarification with respect to what would 
constitute an EHR Module. In most cases, these commenters provided 
examples of technologies that they believed should meet the definition 
of EHR Module and they sought confirmation that these technologies 
would meet the definition. Included among these technologies were 
radiology information systems (RIS), picture archiving and 
communication systems (PACS), PHRs, speech recognition software, 
electrocardiogram systems, remote patient monitoring (RPM) devices, and 
other electronic devices including non-health care devices.
    Response. In the Interim Final Rule, we defined an EHR Module to 
mean ``any service, component, or combination thereof that can meet the 
requirements of at least one certification criterion adopted by the 
Secretary.'' Consequently, EHR Modules, by definition, must provide a 
capability that can be tested and certified in accordance with at least 
one certification criterion adopted by the Secretary. Therefore, if an 
EHR Module does not provide a capability that can be tested and 
certified at the present time, it is not HIT that would meet the 
definition of EHR Module. We stress ``at the present time,'' because as 
new certification criteria are adopted by the Secretary, other HIT 
could be developed and then tested and certified in accordance with the 
new certification criteria as EHR Modules.
    We encourage eligible professionals and eligible hospitals to use 
any and all HIT they believe will help make the health care they 
deliver more effective and efficient. However, unless the HIT is tested 
and certified to at least one certification criterion for use as part 
of Certified EHR Technology, it does not constitute an EHR Module for 
the purposes of this regulation. Eligible professionals and eligible 
hospitals are not prohibited from using or implementing this HIT, but 
again, at the present time, such HIT cannot

[[Page 44596]]

constitute an EHR Module and serve as a necessary component of 
Certified EHR Technology for eligible professionals or eligible 
hospitals to use when seeking to achieve meaningful use as defined in 
the Medicare and Medicaid EHR Incentive Programs final rule.
    In response to these comments, we would also like to clarify our 
conceptualization of an EHR Module. An EHR Module could provide a 
single capability required by one certification criterion or it could 
provide all capabilities but one, required by the certification 
criteria for a Complete EHR. In other words, we would call HIT tested 
and certified to one certification criterion an ``EHR Module'' and HIT 
tested and certified to nine certification criteria an ``EHR Module,'' 
where ten certification criteria are required for a Complete EHR. We 
have not made any changes to the definition of EHR Module as a result 
of these comments or the comments addressed below.
    Comment. One commenter asked whether we meant to include in the 
definition of EHR Module ``interfaces'' that perform data mapping or 
transformation. The commenter raised this question while noting that 
some organizations use multiple interfaces to interconnect their HIT 
systems and that it would be an arduous task for these organizations to 
ensure that all individual interfaces are certified. Another commenter 
sought clarification regarding what we meant when we stated as an 
example in the Interim Final Rule that EHR Modules could be ``an 
interface or other software program that provides the capability to 
exchange electronic health information.''
    Response. As discussed above, to meet the definition of EHR Module, 
HIT would need to provide a capability that could be tested and 
certified to at least one certification criterion. If a certification 
criterion has therefore been adopted that requires a particular 
capability for exchanging electronic health information, an interface 
or other software program that provides that capability could be tested 
and certified as an EHR Module. In many circumstances, an interface or 
program may provide valuable functionality, but not a capability for 
which a certification criterion has been adopted. For example, software 
implemented by an eligible professional that performs data translation 
or mapping between two databases or data sets may provide critical 
functionality, yet that software would not constitute an EHR Module. 
Similarly, interfaces between ``HIT systems'' may be critical to the 
functionality of the separate systems, but they themselves would not be 
EHR Modules.
    In those circumstances in which an interface or other software 
program is an integral component of an EHR Module without which it 
would not be able to be tested and certified, then such interface or 
other software program, though not itself an EHR Module, would function 
as a critical piece of the overall EHR Module presented for testing and 
certification. For example, a software program that would permit an 
eligible professional or eligible hospital to electronically exchange 
health information with other eligible professionals or eligible 
hospitals could be tested and certified as an EHR Module, if it 
provides the capability to electronically exchange health information 
according to standards adopted by the Secretary. In this example, 
whatever comprises the software program would be considered part of the 
EHR Module that is tested and certified.
    Finally, in situations where an eligible professional or eligible 
hospital believes that it has multiple HIT systems that would each meet 
the definition of EHR Module, we suggest that the eligible professional 
or eligible hospital evaluate whether these systems could be combined 
with other systems to constitute a Complete EHR. If they are capable of 
being combined to form a Complete EHR, it may be more expeditious and 
beneficial for an eligible professional or eligible hospital to simply 
seek Complete EHR testing and certification.
    Comments. A few commenters requested that we clarify how EHR 
Modules would be tested and certified to adopted privacy and security 
certification criteria. Other commenters asked whether we meant to 
allow for there to be EHR Modules that provided only privacy and 
security capabilities.
    Response. These comments pertain to the certification programs 
rule, and are outside of the scope of this rule. We therefore respond 
to these comments in the Temporary Certification Program final rule (75 
FR 36158).
8. Definition of Certified EHR Technology
    Comments. Multiple commenters commended ONC for recognizing the 
need to certify EHR Modules and enabling certified EHR Modules to be 
used in combination to meet the definition of Certified EHR Technology. 
These commenters noted that this approach makes it clear that eligible 
professionals and eligible hospitals will have the flexibility to 
select certified EHR modules that are the most useful to them, and can 
achieve meaningful use either with combinations of certified HIT or a 
single EHR system. However, some commenters mentioned that the 
definition is unnecessarily ambiguous, and subject to possible 
alternative interpretations. Some commenters also commented on certain 
statements in the preamble regarding EHR Modules and queried how a 
proper combination of EHR Modules could be used to meet the definition 
of Certified EHR Technology. Other commenters, while acknowledging that 
adopted certification criteria will determine in part what constitutes 
Certified EHR Technology, urged ONC to revise the definition to include 
only patient care functionality. Finally, a few commenters offered 
specific word changes for the definition to improve its clarity.
    Response. In the Interim Final Rule, we defined Certified EHR 
Technology to mean ``a Complete EHR or a combination of EHR Modules, 
each of which: (1) Meets the requirements included in the definition of 
a Qualified EHR; and (2) 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.'' With respect to a combination of EHR Modules, we clarified 
in the preamble of the Interim Final Rule that:

    As long as each EHR Module has been separately tested and 
certified in accordance with the certification program established 
by the National Coordinator * * * to all of the applicable 
certification criteria adopted by the Secretary, a proper 
combination of certified EHR Modules could meet the definition of 
Certified EHR Technology. To clarify, we are not requiring the 
certification of combinations of certified EHR Modules, just that 
the individual EHR Modules combined have each been certified to all 
applicable certification criteria in order for such a 
``combination'' to meet the definition of Certified EHR Technology.

    Many commenters appeared to be confused by the inclusion of ``each 
of which'' in the definition of Certified EHR Technology. Other 
commenters also stated that ``each of which'' was awkwardly placed, 
making it difficult to interpret how the combination of EHR Modules 
must satisfy the subsequent requirements of the definition. This 
confusion also made it difficult to understand the clarifying remarks 
reiterated above regarding our intention to avoid implying that a 
combination of certified EHR Modules had to be certified a second time 
when a proper combination had been created. We generally agree with 
these comments and are revising the definition slightly

[[Page 44597]]

to avoid this ambiguity and to clarify that the definition of Certified 
EHR Technology can be met in either of two ways.
    The first way that the definition of Certified EHR Technology can 
be met is for a Complete EHR to: (1) Meet the requirements included in 
the definition of a Qualified EHR, and (2) be 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. The second way that the definition of Certified EHR 
Technology can be met is if each constituent EHR Module of a 
combination of EHR Modules has been tested and certified in accordance 
with the certification program established by the National Coordinator 
as having met all applicable certification criteria adopted by the 
Secretary and the resultant combination also meets the requirements 
included in the definition of a Qualified EHR.
    As previously written, it was unclear to many commenters that the 
comma preceding ``each of which'' was meant to separately apply a 
Complete EHR and ``combination of EHR Modules'' to the subsequent 
requirements. Our intention was that a combination of EHR Modules would 
have to provide the capabilities necessary to meet the definition of a 
Qualified EHR and that the EHR Modules combined would have each been 
tested and certified in accordance with the certification criteria 
applicable to each EHR Module.
    In response to commenters, we have decided to revise the definition 
of Certified EHR Technology to state explicitly the two distinct ways 
the definition can be met. The revised definition will read as follows. 
Certified EHR Technology means:
    (1) A Complete EHR that meets the requirements included in the 
definition of a Qualified EHR and has been tested and certified in 
accordance with the certification program established by the National 
Coordinator as having met all applicable certification criteria adopted 
by the Secretary; or
    (2) A combination of EHR Modules in which each constituent EHR 
Module of the combination has been tested and certified in accordance 
with the certification program established by the National Coordinator 
as having met all applicable certification criteria adopted by the 
Secretary, and the resultant combination also meets the requirements 
included in the definition of a Qualified EHR.
    As discussed in the Temporary Certification Program final rule, a 
pre-coordinated integrated bundle of EHR Modules would fall under the 
second definition of Certified EHR Technology, although each EHR Module 
of the bundle would be tested and certified at the same time rather 
than separately. Therefore, provided that a proper combination of EHR 
Modules has been created, combinations of EHR Modules could be tested 
and certified either at the same time or at separate times, to meet the 
definition of Certified EHR Technology.
    Finally, we believe that commenter suggestions to revise the 
definition of Certified EHR Technology to reference specific 
certification criteria are misguided. The definition, regardless of the 
certification criteria that must be included in a Complete EHR or 
combination of EHR Modules, must be able to accommodate changes in 
certification criteria over time. Accordingly we believe that the final 
definition meets this intended goal and conveys a clear meaning.
    Comments. Some commenters appeared to interpret our definition as 
providing that EHR Modules must be used to meet the definition of 
Certified EHR Technology. Of these commenters, some requested that we 
clarify whether health care providers would be required to obtain 
certification of EHR Modules that no vendors support. Other commenters 
asked whether non-certified ``EHR modules'' could be used in 
combination with a Complete EHR or in combination with EHR Modules that 
are used to meet the definition of Certified EHR Technology.
    Response. We would like to make clear that eligible professionals 
and eligible hospitals are not required to use EHR Modules in order to 
meet the definition of Certified EHR Technology. The use of EHR Modules 
is completely voluntary and provides an alternate avenue for eligible 
professionals and eligible hospitals who seek to implement more 
customized HIT solutions while still meeting the definition of 
Certified EHR Technology. Commenters who expressed concerns about their 
responsibility for seeking certification for EHR Modules for which no 
vendor supports did not provide specific examples, and we are uncertain 
as to the basis for their concerns. Regardless, we reiterate that the 
use of EHR Modules is voluntary and we believe that most eligible 
professionals and eligible hospitals that are adopting HIT for the 
first time will have a variety of Complete EHRs available from which to 
choose.
    We also clarify that only those EHR Modules that provide 
capabilities necessary to meet the definition of Certified EHR 
Technology will need to be tested and certified. That being said, 
eligible professionals and eligible hospitals are free to utilize any 
other type of HIT to complement or in combination with Certified EHR 
Technology, including HIT that provides capabilities for other purposes 
not related to meaningful use.
    Comments. Some commenters suggested that our definition was too 
broad. Most of these commenters argued that we should permit eligible 
professionals to adopt only Complete EHRs and EHR Modules that were 
certified as including only those capabilities applicable to their 
specialty or practice. In other words, these commenters sought for the 
definition of Certified EHR Technology to be interpreted in such a way 
as to permit different specialty-oriented variations of Certified EHR 
Technology to exist.
    Response. At the present time, we believe that the definition of 
Certified EHR Technology already includes some of the flexibility these 
commenters request. We permit, for example, a Complete EHR designed for 
an ambulatory setting and a Complete EHR designed for an inpatient 
setting both to meet the definition of Certified EHR Technology, even 
though each is compliant with a slightly different set of applicable 
certification criteria. In that regard, we believe we have integrated a 
balanced and appropriate amount of flexibility into the definition of 
Certified EHR Technology, which will also allow us to make additional 
refinements over time. We believe that it is possible based on industry 
need for us to specify in a future rulemaking sets of applicable 
certification criteria for Complete EHRs and EHR Modules designed for 
particular clinical settings.
9. Definition of Human Readable Format
    Comments. A number of commenters across several certification 
criteria requested that we clarify the meaning of ``human readable 
format.'' These commenters questioned what human readable format meant 
when it was used in the certification criteria and offered examples of 
what they thought would constitute human readable format such as, style 
sheets and PDFs. A couple of commenters suggested that human readable 
format should consider patients' linguistic needs. A commenter 
requested we discuss the compliance requirements associated with the 
Americans with Disabilities Act and the relevant sections of the 
Rehabilitation Act of 1973 to ensure human readable format was meant to 
include an obligation to provide people with disabilities alternative 
formats such as large print or Braille.

[[Page 44598]]

    Response. In the Interim Final Rule, we discussed the meaning of 
human readable format and provided examples of what we believe would 
constitute human readable format. We reiterate that discussion below.

    We believe that in order to recognize the enormous potential of 
HIT, greater standardization in future years is necessary. In that 
regard, we recognize that more advanced interoperability requires 
health information to be represented by specific vocabularies and 
code sets that can be interpreted by EHR technology as well as 
converted and presented in a readable format to the users of such 
technology. At the present time we recognize that implementing 
certain vocabularies and code sets in EHR technology is a difficult, 
technical undertaking. For that reason, we have not adopted specific 
vocabularies and code sets for a number of the exchange purposes * * 
* We have, however, as a transitional step, adopted certification 
criteria that require Certified EHR Technology to be capable of 
presenting health information received in human readable format. By 
human readable format, we mean a format that enables a human to read 
and easily comprehend the information presented to them regardless 
of the method of presentation (e.g., computer screen, handheld 
device, electronic document). This would likely require information 
in coded or machine readable format to be converted to, for example, 
its narrative English language description. In an effort to further 
the transition to, and prevalence of, more specific vocabularies and 
code sets, we are interested in public comment regarding industry 
readiness if we were to adopt certification criteria requiring the 
use of additional vocabularies and code sets in parallel with 
meaningful use Stage 2. Such certification criteria could include 
not only that Certified EHR Technology be capable of presenting 
information in human readable format but also that it be capable of 
automatically incorporating certain vocabulary or code sets (i.e., 
machine readable information).

    The term human readable format is used in two contexts, when coded 
health information should be displayed to an eligible professional or 
(to a health care professional within) an eligible hospital using 
Certified EHR Technology and in the circumstances where Certified EHR 
Technology must be capable of generating an electronic copy of health 
information for individuals. Each context may dictate a different human 
readable format. For example, the use of a style sheet may be 
appropriate for both health care professionals that are interacting 
with Certified EHR Technology as well as individuals who receive an 
electronic copy of their health information to access at a later time. 
In other circumstances it may be more appropriate for a health care 
professional to view health information in human readable format on 
their handheld device while an individual may seek an electronic 
document, such as a PDF. Given the requests for additional clarity 
regarding the meaning of human readable format, we have decided to 
define the term in this final rule as follows: Human readable format 
means a format that enables a human to read and easily comprehend the 
information presented to him or her regardless of the method of 
presentation (e.g., computer screen, handheld device, electronic 
document).
    We noted in the Interim Final Rule that the standards, 
implementation specifications, and certification criteria adopted by 
the Secretary applied to Complete EHRs and EHR Modules, not to persons 
or entities. We also stated that nothing required by the Interim Final 
Rule should be construed as affecting existing legal requirements under 
other Federal laws. Accordingly, this final rule does not affect an 
eligible professional or eligible hospital's requirements to comply 
with other Federal laws in the event health information is provided in 
human readable format and persons with disabilities require reasonable 
accommodations.
10. Definition of User
    Comments. A number of commenters commenting on several 
certification criteria requested that we clarify the meaning of the 
term ``user.''
    Response. We recognize that the term user is referenced in the 
certification criteria and at times could be interpreted differently. 
We believe this flexibility is necessary because a user may be 
different depending on the certification criterion and the context 
within which the capability it specifies is used. Accordingly, we 
believe a user could be a health care professional or office staff, 
someone who might interact directly with Certified EHR Technology or 
that it could also be software program or service.

D. Final Rule Amendments to Adopted Standards, Implementation 
Specifications, and Certification Criteria Sec. Sec.  170.202, 170.205, 
170.207, 170.210, 170.302, 170.304, 170.306

1. Flexibility and Innovation
    Comments. Many commenters requested that we provide more 
flexibility in the final rule to accommodate new developments in HIT. 
These commenters agreed with our approach to identify minimum standards 
for certain code sets and they recommended a similar approach for other 
standards. Some commenters suggested alternative approaches to adopting 
standards, such as adopting standards at a higher level of abstraction 
(e.g., HL7 2.x, where ``x'' could be any version within the version 2 
family) and accompanying the adopted standards with detailed 
implementation specifications or guidance outside of the rulemaking 
process.
    Response. We appreciate commenters' support for the ``minimum 
standard'' approach that we established in the Interim Final Rule. We 
believe that code sets are an appropriate type of standard to set as a 
``minimum.'' In the Temporary Certification Program final rule, we 
discuss the approaches available to the Secretary to identify and 
accept newer versions of adopted minimum code set standards. Below, we 
discuss how we have added flexibility into this final rule and how we 
can add flexibility in future rulemakings.
    In many cases, however, our flexibility may be limited due to legal 
requirements to adopt substantive requirements through following the 
procedures of the Administrative Procedure Act (APA). Depending upon 
the circumstances and subject matter, we may not be able to alter the 
substantive standards that apply to Certified EHR Technology solely 
through guidance. In addition, a real and practical need to ensure 
consistency among various standards regulations constrains the amount 
of flexibility we can incorporate into the standards we adopt.
    In addition, in accordance with Office of the Federal Register 
regulations related to ``incorporation by reference,'' 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 do believe, however, that additional flexibility can be added 
into this and future rulemakings through at least one of four currently 
identified means:
     Alternative Standards. In the Interim Final Rule and in 
this final rule, we have adopted ``alternative'' standards (and 
applicable implementation specifications) for several certification 
criteria. As a general rule, when an adopted certification criterion 
refers to two or more standards as alternatives, use of at least one of 
the alternative standards will be considered compliant with the 
certification criterion. For the certification criterion at Sec.  
170.302(k)(1), for instance, we have adopted HL7 2.3.1

[[Page 44599]]

and HL7 2.5.1 as alternatives, and the use of either standard (and the 
applicable implementation specifications) would be sufficient to comply 
with the certification criterion. In each of these instances, we have 
tried to balance the need for flexibility with the goal of advancing 
interoperability, while also taking into account that the HIT industry 
has not yet migrated to a single specific standard for certain 
purposes. In some cases, this balancing has required the adoption of 
certification criteria that requires certain EHR technology to be 
capable of receiving electronic health information formatted according 
to a standard that it is not natively capable of generating. For 
example, with respect to patient summary records, we have adopted the 
Continuity of Care Document and Continuity of Care Record standards as 
alternatives. As a condition of certification, section 170.304(i)(1) 
provides as an additional requirement that upon receipt of a patient 
summary record formatted in the alternative standard, the EHR 
technology must be capable of displaying the patient summary record in 
human readable format. We believe this final rule correctly balances at 
this stage of EHR adoption our goal of promoting interoperability with 
the HIT industry's ability to comply with the certification criteria 
and its need for flexibility. Consistent with our long-term goals for 
interoperability, we anticipate that this balance will need to change 
as the HIT industry migrates to single specific standards for 
particular purposes.
     Minimum Code Set Standards. As previously discussed in the 
Interim Final Rule, we adopted several minimum code set standards. It 
is important to note that these code set standards set the floor, not 
the ceiling, for testing and certification. If, and when, the Secretary 
accepts a newer version of an adopted minimum standard code set, the 
Secretary will, in effect, raise the ceiling for what is permitted for 
testing and certification as well as whether Certified EHR Technology 
can be upgraded to that newer version without adversely affecting the 
Certified EHR Technology's certified status. For context purposes we 
repeat a portion of the Interim Final Rule's preamble that discussed 
our approach to minimum code set standards.

    We have implemented this approach by preceding references to 
specific adopted standards with the phrase, `at a minimum.' In those 
instances, the certification criterion requires compliance with the 
version of the code set that has been adopted through incorporation 
by reference, or any subsequently released version of the code set. 
This approach will permit Complete EHRs and EHR Modules to be tested 
and certified, to, `at a minimum,' the version of the standard that 
has been adopted or a more current or subsequently released version.

    We would note that consistent with this approach the Secretary has 
proactively identified and deemed acceptable newer versions of the 
following adopted ``minimum standard'' code sets:
    (1) LOINC version 2.3, released on February 26, 2010; and
    (2) CVX--Vaccines Administered, March 17, 2010.
    We are consequently using this opportunity to inform Complete EHR 
and EHR Module developers, prospective ONC-Authorized Testing and 
Certification Bodies, and the rest of the public of the Secretary's 
recognition of these newer versions of certain adopted ``minimum 
standard'' code sets. We reiterate that use of these newer versions is 
voluntary. We also note in accordance with 45 CFR 170.455(b)(2) that 
Certified EHR Technology may be upgraded to comply with these newer 
versions at any time without adversely affecting the certification 
status of the Certified EHR Technology.
     Optional Standards, Implementation Specifications, and 
Certification Criteria. We believe that additional flexibility and 
specificity can be introduced into this and future cycles of rulemaking 
through the adoption and designation of ``optional'' standards, 
implementation specifications, and certification criteria. Optional 
standards, implementation specifications, and certification criteria 
would be voluntary and would not be required for testing and certifying 
a Complete EHR or EHR Module. We believe that optional standards, 
implementation specifications, and certification criteria will also 
help better prepare the HIT industry for future mandatory certification 
requirements.
     Standards and Backwards Compatibility. In previous 
rulemakings, specifically the Secretary's adoption of electronic 
prescribing (e-prescribing) standards (70 FR 67579) related to the 
Medicare Part D prescription drug program, HHS discussed a process to 
improve flexibility in regulatory requirements which involves 
``backwards compatibility.'' HHS described backwards compatibility as 
meaning that a newer version of a standard retains at a minimum the 
full functionality of the version previously adopted in regulation, and 
that the newer version would permit the successful completion of the 
applicable transaction(s) with entities that continue to use the older 
version(s). HHS discussed that if a newer version of a standard were 
backward compatible with an adopted standard, it would be possible to 
pursue a more expedited approach to permit the utilization of the newer 
version while still remaining in compliance with the law. We believe 
that the approach established in the e-prescribing rulemaking could be 
leveraged in many situations for the standards and implementation 
specifications adopted for HIT certification. However, we note that 
this approach can only be implemented when a newer version of a 
standard is technically capable of fully functioning with the adopted 
version of the standard to conduct the specified transaction.
    Much like minimum code set standards, we could foresee possibly 
adopting a backward compatible version of a previously adopted standard 
and allowing entities to voluntarily use the newer version for a period 
of time. In such cases, much like a minimum code set standard, Complete 
EHR and EHR Module developers would be permitted to have their Complete 
EHR or EHR Module certified according to the adopted backward 
compatible version, and eligible professionals and eligible hospitals 
in possession of Certified EHR Technology would be permitted to upgrade 
voluntarily their Certified EHR Technology to include the adopted 
backwards compatible version. Given that we anticipate adopting new or 
modified standards, implementation specifications, and certification 
criteria every two years in sync with the initiation of a new 
meaningful use stage, we believe that the Secretary's adoption of 
backward compatible versions of standards would generally be limited to 
intermediate years (i.e., 2012 and 2014). To accomplish the adoption of 
a backwards compatible version, we would take an approach very similar 
to the approach described in the final e-prescribing regulation.
    We would first review whether the new version of an adopted 
standard retains at a minimum the full functionality of the adopted 
version of the standard as well as whether it enables the successful 
completion of the applicable transaction(s) with entities that continue 
to use the older version(s). We would then review whether a standard 
should be updated with a new version and whether use of either the new 
version or the older version would be considered compliant as well as 
whether use of the new version would conflict with any already existing 
regulatory requirements. If we believe that the Secretary's adoption of 
a newer version of a standard on a voluntary

[[Page 44600]]

basis would be appropriate, we would then seek the advice of the HIT 
Standards Committee to evaluate the newer version of the standard and 
to solicit relevant public input. The Secretary would then recognize or 
adopt for voluntary use the new version of the standard in a Federal 
Register publication. At that point, use of either the new or old 
version would be considered compliant. Entities that would voluntarily 
adopt the later backward compatible version of the standard would 
remain obligated to accommodate the earlier adopted version without 
modification. Prior to the Department formally retiring the older 
version of the standard and mandating the use of the later version, the 
Department would engage in notice and comment rulemaking.
2. Transport Standards
    Comments. Generally, commenters echoed one of two responses: Some 
urged for the complete removal of SOAP and REST and others requested 
that we provide detailed implementation specifications for SOAP and 
REST along with the identification of the transactions to which SOAP 
and REST were applicable. Some commenters also stated that neither 
standard was sufficiently specified in order to ensure 
interoperability, while others pointed out that it appeared that we had 
globally applied the usage of SOAP or REST to all adopted standards, 
which, if true, would cause conflicts with several adopted standards 
(e.g., it was noted that the HL7 standards we adopted utilize Minimum 
Lower Layer Protocol (MLLP) as the transport standard and not SOAP or 
REST).
    Response. We have considered the public comments received on this 
matter and we are convinced that it is prudent to remove the adopted 
standards, SOAP and REST. We did not intend for the significant 
potential conflicts identified by commenters to occur as a result of 
our adoption of SOAP and REST. We have determined that it would be more 
appropriate and reasonable for us not to require at the present time 
specific transport standards as a condition of certification. We hope 
that this will reduce some of the burden on Complete EHR and EHR Module 
developers and provide greater opportunities for innovation. With that 
said, we plan to carefully watch the impact of this decision and its 
affect on interoperability. We encourage Complete EHR and EHR Module 
developers to utilize transport standards that will help the industry 
coalesce around common methods for electronic health information 
exchange, and we plan to examine this decision in future rulemakings.
3. Certification Criteria and Associated Standards and Implementation 
Specifications
    We have organized our discussion of the final certification 
criteria according to the order in which they are currently specified 
at 45 CFR 170 subpart C. We note that the final regulatory citations 
will have changed for many certification criteria and encourage the 
public to review, in full, the final regulatory text specified in 
subpart C of part 170 in the regulation text of this final rule. We 
begin with the certification criteria at 45 CFR 170.302 (general 
certification criteria for Complete EHRs and EHR Modules), move on to 
45 CFR 170.304 (specific certification criteria for Complete EHRs and 
EHR Modules designed for an ambulatory setting) and end with 45 CFR 
170.306 (specific certification criteria for Complete EHRs or EHR 
Modules designed for an inpatient setting). We also include, where 
appropriate, a discussion of the adopted standard(s) and implementation 
specifications associated with each certification criterion. For each 
final certification criterion, we start with an overview of the final 
version and then discuss and respond to public comments.
a. General Certification for Complete EHRs or EHR Modules--Sec.  
170.302
    Section 170.302(a)--Drug-Drug, Drug-Allergy, Drug-Formulary Checks

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Implement drug-drug and drug-   The EP/eligible    Interim Final Rule
 allergy interaction checks.     hospital/CAH has   Text:
                                 enabled this      (1) Alerts.
                                 functionality      Automatically and
                                 for the entire     electronically
                                 EHR reporting      generate and
                                 period.            indicate in real-
                                                    time, alerts at the
                                                    point of care for
                                                    drug-drug and drug-
                                                    allergy
                                                    contraindications
                                                    based on medication
                                                    list, medication
                                                    allergy list, age,
                                                    and computerized
                                                    provider order entry
                                                    (CPOE).
                                                      (3) Customization.
                                                       Provide certain
                                                       users with
                                                       administrator
                                                       rights to
                                                       deactivate,
                                                       modify, and add
                                                       rules for drug-
                                                       drug and drug-
                                                       allergy checking.
                                                      (4) Alert
                                                       statistics.
                                                       Automatically and
                                                       electronically
                                                       track, record,
                                                       and generate
                                                       reports on the
                                                       number of alerts
                                                       responded to by a
                                                       user.
                                                   Final Rule Text: Sec.
                                                      170.302(a).
                                                      (1) Notifications.
                                                       Automatically and
                                                       electronically
                                                       generate and
                                                       indicate in real-
                                                       time,
                                                       notifications at
                                                       the point of care
                                                       for drug-drug and
                                                       drug-allergy
                                                       contraindications
                                                       based on
                                                       medication list,
                                                       medication
                                                       allergy list, and
                                                       computerized
                                                       provider order
                                                       entry (CPOE).
                                                      (2) Adjustments.
                                                       Provide certain
                                                       users with the
                                                       ability to adjust
                                                       notifications
                                                       provided for drug-
                                                       drug and drug-
                                                       allergy
                                                       interaction
                                                       checks.
------------------------------------------------------------------------


[[Page 44601]]


------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Implement drug-formulary        The EP/eligible    Interim Final Rule
 checks.                         hospital/CAH has   Text:
                                 enabled this      (2) Formulary checks.
                                 functionality      Enable a user to
                                 and has access     electronically check
                                 to at least one    if drugs are in a
                                 internal or        formulary or
                                 external drug      preferred drug list
                                 formulary for      in accordance with
                                 the entire EHR     the standard
                                 reporting period.  specified in Sec.
                                                    170.205(b).
                                                   Final Rule Text: Sec.
                                                      170.302(b).
                                                   Drug-formulary
                                                    checks. Enable a
                                                    user to
                                                    electronically check
                                                    if drugs are in a
                                                    formulary or
                                                    preferred drug list.
------------------------------------------------------------------------

    Comments. Based on the example given in the preamble of the Interim 
Final Rule, several commenters believed that we required real-time 
alerts to utilize a pop-up message or sound. Commenters stated that the 
method of delivering real-time alerts should not be included in the 
regulation as it would restrain innovation. One commenter expressed 
concern that the requirements of this certification criterion were 
overly specific with respect to how the Certified EHR Technology needed 
to perform the tasks rather than focusing on the desired result. The 
commenter recommended the certification criterion be modified to ensure 
that such alerts are clearly visible to the physicians at the point-of-
care. Some commenters recommended that the term ``notification'' should 
replace the term ``alert'' for this and other certification criterion 
because the term alert implied a particular implementation whereas 
notification was more neutral.
    Response. Unfortunately, many of the commenters who reacted to our 
example also believed that it was a requirement. We simply added the 
example of a pop-up message or sound in the preamble of the Interim 
Final Rule to make the requirement clear. The use of a pop-up message 
or sound was not a specified requirement in the regulation text. We 
agree with the commenters who explained that there may be better ways 
to provide alerts. For the purposes of testing and certification, we 
leave it entirely up to Complete EHR and EHR Module developers to 
innovate in this area and provide capabilities that are both easy to 
use and prevent medical errors. Additionally, we agree with the 
commenters who suggested that we replace ``alert'' with 
``notification,'' and we have made that change globally across all 
certification criteria that used the term alert.
    Comments. A few commenters requested clarification of the 
requirement to track and report on the number of alerts responded to by 
a user. A commenter requested clarification on why the number of alerts 
is captured but not what the user did with the alert and if this data 
is going to be used to rate providers based upon the number of alerts 
they received. Two commenters requested that ``responded to by a user'' 
be clarified and asked whether it meant that a user had taken a 
different action as a result of the alert. One commenter recommended 
removing the alert requirement unless it is more clearly specified. One 
commenter recommended deleting the requirement on alert statistics 
because it could lead to alert fatigue. A few commenters expressed 
concern about the ability to deactivate, modify, and add rules for 
drug-drug and drug-allergy checking. These commenters recommended that 
this capability be removed because of the risk to patient safety. A 
commenter noted that treating physicians should have the ability to 
ignore alerts in light of other clinical facts about the patient and 
felt that providing the ability to delete or modify alerts in a way 
that would be inconsistent with current medical standards would be 
irresponsible and contrary to the meaningful use goal of preserving the 
health and safety of patients. Other commenters requested clarification 
as to whether the ability to ``deactivate'' rules implied the ability 
to remove specific rules or drug pairs as they exist in 
commercially[hyphen]available clinical decision support (CDS) 
databases; the ability to ``modify'' rules implied that an 
administrator would be able to change the rules as they exist in these 
commercially[hyphen]available CDS databases; and the ability to ``add'' 
new rules implied that the administrator could create new rules in 
commercially[hyphen]available CDS databases. The commenters interpreted 
``modify'' to mean, for example, the ability to override or change 
severity setting; and ``add'' to mean activating a category of CDS, 
such as drug[hyphen]drug interactions, but not individual rules; and 
``deactivate'' as the ability to ``turn off'' specific types of rules. 
Another commenter requested clarification as to whether the requirement 
for customization would be met if a system administrator were to set 
the selected severity level to reflect the collective decision of a 
practice or if alerts must be tailored on an EP-by-EP basis. A 
commenter requested clarification on what qualifies as a ``response'' 
to an alert. One commenter recommended that the rule clarify that 
``responded to by a user'' means in a way which meaningfully addresses 
the alerts. A couple of commenters stated that centrally hosted 
services would have problems complying with the customization 
requirements because the hosting vendor takes responsibility for the 
administration, maintenance and updating of the clinical decision 
support rules including alerts for drug interactions alerts, including 
drug-drug, drug-allergy and drug-problem. These commenters were 
concerned that allowing each of their clients to create local drug-
interaction rules would slow their ability to provide important updates 
to their client base, since this would require navigation of a complex 
hierarchy of preferred local rules. These local rules would also 
introduce clinical risk if old local rules could create a conflict with 
a clinically appropriate global, updated rule.
    Response. Based on the significant number of comments presenting 
diverse interpretations of these provisions, we determined that this 
certification criterion needed further clarification and have revised 
it accordingly. Our intention related to the alert statistics 
capability had been to mirror the clinical decision support capability. 
With respect to customization, we sought to provide users of Certified 
EHR Technology with a way to adjust the severity level for which alerts 
are presented. In response to public comment, and to clarify what we 
believe Certified EHR Technology must include as a condition of 
certification, we have removed the ``alert statistics'' part of the 
certification criterion altogether and revised the ``customization'' 
part of the certification criterion to more clearly specify this 
capability. Our revisions focus on Certified EHR Technology's 
capability to allow certain users (e.g., those with administrator 
rights) with the ability to adjust notifications provided for drug-drug 
and drug-allergy checks (e.g., set the level of severity for which 
notifications are presented).
    Comment. A commenter stated that use of age as a required data 
element in this certification criterion is a problem

[[Page 44602]]

because drug databases handle age in non-standard ways. It was also 
stated that for geriatric patients weight is also considered along with 
age.
    Response. We agree with this commenter. After considering this 
comment, particularly in light of the potentially divergent 
interpretations of this certification criterion we noted above, we have 
removed ``age'' from the certification criterion. It was never our 
intention, as could have been anticipated, to require that Certified 
EHR Technology be capable of performing checks that relate type or 
dosage of drugs to the patient's age, or ``drug-age checks.''
    Comment. A commenter encouraged ONC to add adverse drug events to 
the certification criterion and to identify candidate standards for its 
inclusion to support meaningful use Stage 2.
    Response. We appreciate the suggestion and believe that identifying 
adverse drug events is important. Because the final meaningful use 
Stage 1 requirements under the Medicare and Medicaid EHR incentive 
programs do not include such a requirement, though, we do not believe 
that it would be appropriate at the present time to add such a 
requirement as a condition of certification. This does not preclude 
Complete EHR or EHR Module developers from including such 
functionality.
    Comment. A couple of commenters requested clarification on what 
CPOE means in the certification criterion. A commenter requested that 
ONC clarify that this certification criterion applies only to the 
order-entry workflow and is not applicable to other office processes or 
workflows which might involve the same clinical data but which would 
not necessarily generate these alerts.
    Response. We clarify for commenters that our inclusion of CPOE in 
the certification criterion is meant to indicate that notifications 
should occur based on new medication orders, in addition to a patient's 
current medications and medication allergies, as they are being 
entered. In response to the other commenter's request for 
clarification, we believe that notifications will occur during the 
order-entry workflow.
    Comment. A commenter requested that the rule be clarified to 
explicitly require that drug-drug, drug-allergy, and drug formulary 
checks occur based on information and medication lists in an 
individual's complete medical record derived from all relevant 
providers, not only the drug list of the specific provider.
    Response. We clarify that we expect Certified EHR Technology to 
perform drug-drug and drug-allergy checks based on medication list and 
medication allergy list information included within Certified EHR 
Technology as structured data. We recognize that Certified EHR 
Technology may also store health information in scanned documents, 
images, and other non-interoperable non-computable formats and, 
consequently, do not expect Certified EHR Technology to be capable of 
reading or accessing the information in these other formats for the 
purposes of performing drug-drug and drug-allergy checks.
    Comment. A commenter requested that ONC clarify that EHR vendors 
will not be required to remove the option to disable drug-drug and 
drug-allergy checks.
    Response. While we do not require that the option to disable drug-
drug and drug-allergy checks be removed as a condition of 
certification, we note that in order for an eligible professional or 
eligible hospital to become a meaningful user of Certified EHR 
Technology this capability must be enabled.
    Comments. Several commenters noted that the NCPDP Formulary and 
Benefits standard is not used in an inpatient setting. The commenters 
consequently requested clarification as to how the standard can be used 
in an inpatient setting. Some of the commenters noted that for 
inpatient settings, hospitals typically relied on their own formularies 
for performing the types of checks specified. Another commenter 
requested clarification whether the correct content exchange standard 
was National Council for Prescription Drug Programs (NCPDP) Formulary 
and Benefits Standard version 1.0 and that if it was, the commenter 
recommended its adoption. Another commenter noted that some State 
Medicaid formularies are not yet available via nationwide e-prescribing 
networks and recommended that ONC encourage the implementation of State 
Medicaid formularies within the NCPDP Formulary and Benefits Standard 
via a nationwide e-prescribing network.
    Response. We agree with those commenters who identified the 
inconsistency of applying the Formulary and Benefits standard to the 
inpatient setting. Because the CMS proposed meaningful use objectives 
applied to both eligible professionals and eligible hospitals, we did 
not make the distinction as to when a Complete EHR or EHR Module would 
need to include the Formulary and Benefits standard. However, in light 
of these comments and to support the final meaningful use measure, we 
have determined that it would be appropriate to adopt a more general 
certification criterion that would be applicable to both Complete EHRs 
and EHR Modules designed for ambulatory and inpatient settings. 
Accordingly, we have removed any reference to a particular standard 
because an eligible professional or eligible hospital that does not 
have external access to a drug formulary would be able to satisfy this 
meaningful use measure by checking an internally managed drug 
formulary. Although the Formulary and Benefits standard is no longer 
required as a condition of certification, we note that eligible 
professionals who seek to comply with the electronic prescribing 
requirements associated with Medicare Part D eligible individuals will 
need to use this standard as they do today. Additionally, we do not 
agree that it is within the scope of this rulemaking to address State 
Medicaid Agencies' participation in nationwide e-prescribing networks.
    Comments. Many commenters noted that the drug-formulary requirement 
should not apply to Complete EHRs and EHR Modules designed for an 
inpatient setting because there was no proposed requirement for 
meaningful use Stage 1 for eligible hospitals to electronically 
prescribe. Many of the commenters recommended removing this as a 
requirement for eligible hospitals while retaining it with the criteria 
for eligible professionals. A few commenters specifically recommended 
adding it to the criterion for electronic prescribing. Several 
commenters recommended that if the requirement were kept for hospitals 
it should be written as a separate criterion to address the query of a 
hospital's drug formulary during the order entry process and not the 
NCPDP Formulary and Benefits standard. A commenter stated that current 
industry practice among vendors of EHR technology is to provide a 
``generic'' national formulary rather than the formulary for a 
particular plan. The commenter recommended that the functionality 
require that a user actually perform an eligibility check before access 
is provided and, in response to that check, the functionality show the 
correct formulary and benefits information, rather than just generic 
data.
    Response. We believe that our discussion above regarding the 
removal of the standard associated with this certification criterion 
addresses many of the concerns raised by commenters. However, we 
disagree with the suggestion that Complete EHRs and EHR Modules 
designed for an inpatient setting should not be required to include 
this capability. This capability is required to be enabled for the

[[Page 44603]]

purposes of meeting the meaningful use Stage 1 measure. Consistent with 
the final meaningful use Stage 1 objectives which separated drug-drug 
and drug-allergy checks from drug-formulary checks, we have separated 
out these capabilities into two different certification criteria.
    Comments. A commenter stated a concern that this criterion, 
combined with future meaningful use requirements, will shift providers' 
focus from prescribing the best drug for the patient to prescribing 
what is covered by the patient's insurance plan or generic brands. 
Another commenter stated that adding formulary checks to the workload 
of physicians will decrease physicians' efficiency and increase their 
costs.
    Response. In this rule, the Secretary is completing the adoption of 
the initial set of standards, implementation specifications, and 
certification criteria for the certification of Complete EHRs and EHR 
modules. The certification criteria ensure that Certified EHR 
Technology includes certain capabilities. The extent to which health 
care providers must use those capabilities and how they integrate EHR 
technology into their practice falls outside the scope of this rule. We 
therefore do not believe that these concerns are within the scope of 
this rulemaking.
    Comment. A commenter recommended that ``drug-test checks'' should 
be added. The commenter stated that many drugs require some form of 
laboratory testing to ensure that drugs are prescribed appropriately. 
The commenter stated, for example, that an anticoagulant medication 
should not be prescribed unless there is a test result on record that 
shows that giving this drug would not cause harm.
    Response. Presently, drug-test checking is not a required 
capability for eligible professionals and eligible hospitals to use in 
order to successfully meet the requirements of meaningful use Stage 1. 
Accordingly, we do not believe that it would be appropriate to require 
Certified EHR Technology to be capable of performing drug-test checks 
as a condition of certification at the present time.
Section 170.302(b)--Maintain Up-To-Date Problem List


------------------------------------------------------------------------
    Meaningful use stage 1        Meaningful use       Certification
           objective             stage 1 measure         criterion
------------------------------------------------------------------------
Maintain an up-to-date problem  More than 80% of   Interim Final Rule
 list of current and active      all unique         Text:
 diagnoses.                      patients seen by  Maintain up-to-date
                                 the EP or          problem list. Enable
                                 admitted to the    a user to
                                 eligible           electronically
                                 hospital's or      record, modify, and
                                 CAH's inpatient    retrieve a patient's
                                 or emergency       problem list for
                                 department (POS    longitudinal care in
                                 21 or 23) have     accordance with:
                                 at least one      (1) The standard
                                 entry or an        specified in Sec.
                                 indication that    170.205(a)(2)(i)(A);
                                 no problems are    or
                                 known for the     (2) At a minimum, the
                                 patient recorded   version of the
                                 as structured      standard specified
                                 data.              in Sec.
                                                    170.205(a)(2)(i)(B).
                                                   Final Rule Text: Sec.
                                                      170.302(c).
                                                   Final rule text
                                                    remains the same as
                                                    Interim Final Rule
                                                    text, except for
                                                    references to
                                                    adopted standards,
                                                    which have been
                                                    changed.
------------------------------------------------------------------------

    Comments. Several commenters expressed concerns about the use of 
ICD-9-CM because it is primarily used for billing and administrative 
purposes and may not accurately represent the true clinical meaning of 
a problem or condition when it is documented at the point of care. One 
commenter stated a concern that the problem list standards do not allow 
for capturing of free text that health care providers use when an 
appropriate code is in neither SNOMED-CT[supreg] nor ICD-9-CM.
    Response. The comments are correct in that ICD-9-CM is primarily 
used for billing and administrative purposes. SNOMED-CT[supreg] is 
offered as an alternative standard that will support more clinical 
descriptions of patient problems or conditions. We believe that with 
the adoption of both SNOMED-CT[supreg] and ICD-9-CM, healthcare 
providers should have adequate coverage for patient diagnoses and 
conditions. We are discouraging the use of free text for documenting 
problem lists since this will limit the usefulness of problem lists for 
clinical reminders, decision support and other patient safety and 
quality reporting.
    Comments. Several commenters recommended that only SNOMED-
CT[supreg] be adopted, or alternatively, that we expressly indicate an 
intention to move away from ICD-9CM and ICD-10 in the future. Another 
commenter recommended against the adoption of SNOMED-CT[supreg] because 
the commenter felt that our adoption of SNOMED-CT[supreg] would require 
eligible professionals and eligible hospitals to use both ICD-9-CM and 
SNOMED-CT[supreg]. One commenter recommended that a publicly vetted and 
HHS approved standard mapping between ICD-9-CM and SNOMED CT[supreg] 
should be made available at the public's expense.
    Response. We agree conceptually that a single standard for clinical 
information would be desirable in the long term. However, presently 
both ICD-9-CM and SNOMED-CT[supreg] are used by EHR technology to code 
clinical information, and adopting both would provide users with 
additional flexibility. Moreover, we anticipate that as meaningful use 
objectives and measures evolve over time, we will receive additional 
public input and experience related to these standards and may 
eventually be able to adopt only one standard.
    Comments. A few commenters asked for clarification as to whether 
SNOMED-CT[supreg] or ICD-9CM codes needed to be included within 
Certified EHR Technology or if these standards were only necessary when 
electronic health information is exchanged. Some of these commenters 
also requested that we permit any coding system to be used as long as 
it can be mapped to the appropriate format when electronic health 
information is to be exchanged.
    Response. As previously discussed, meaningful use requirements will 
typically specify whether an adopted standard will have to be used 
among components of a business organization or solely for the 
electronic exchange of health information with other legal entities. 
The measure for this final meaningful use objective provides that 
entries be recorded as structured data. The certification criterion 
specifies that ICD-9CM or SNOMED-CT[supreg] are the code sets which 
must be included in Certified EHR Technology, and are therefore the 
code sets that would be used to record entries as structured data.

[[Page 44604]]

    Comments. A few commenters recommended the removal of 
``longitudinal care'' in the certification criterion. These commenters 
cited our clarification in the preamble that by longitudinal care we 
meant ``over multiple office visits.'' These commenters questioned how 
this language would be applicable to an inpatient setting since 
patients are typically treated for acute episodes and not over multiple 
office visits.
    Response. The reference to longitudinal care is intended to convey 
that the problem list must be comprehensive in the sense that it must 
be capable of including entries provided over an extended period of 
time. Consequently, for Complete EHRs and EHR Modules to be certified 
for an ambulatory setting, they will need to be designed to enable the 
user to electronically record, modify, and retrieve a patient's problem 
list over multiple encounters. For an inpatient setting, they will need 
to enable the user to electronically record, modify, and retrieve a 
patient's problem list for the duration of an entire hospitalization. 
This clarification was also requested in relation to the medication 
list and medication allergy list certification criteria and we have not 
repeated our response. As a result, we have retained ``longitudinal 
care'' in each certification criterion where the term is referenced and 
only make this clarification once.
    Comment. A commenter suggested that we include a reasonable 
expectation of what constitutes ``up-to-date'' in the reference to 
``up-to-date'' problem list.
    Response. We referred this comment to CMS, and it is addressed in 
the final rule on the Medicare and Medicaid EHR Incentive Programs.
Section 170.302(c)--Maintain Active Medication List

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Maintain active medication      More than 80% of   Interim Final Rule
 list.                           all unique         Text:
                                 patients seen by  Maintain active
                                 the EP or          medication list.
                                 admitted to the    Enable a user to
                                 eligible           electronically
                                 hospital's or      record, modify, and
                                 CAH's inpatient    retrieve a patient's
                                 or emergency       active medication
                                 department (POS    list as well as
                                 21 or 23) have     medication history
                                 at least one       for longitudinal
                                 entry (or an       care in accordance
                                 indication that    with the standard
                                 the patient is     specified in Sec.
                                 not currently      170.205(a)(2)(iv).
                                 prescribed any    Final Rule Text: Sec.
                                 medication)          170.302(d).
                                 recorded as       Maintain active
                                 structured data.   medication list.
                                                    Enable a user to
                                                    electronically
                                                    record, modify, and
                                                    retrieve a patient's
                                                    active medication
                                                    list as well as
                                                    medication history
                                                    for longitudinal
                                                    care.
------------------------------------------------------------------------

    Comments. A few commenters agreed with the certification criterion. 
One commenter requested that we provide more clarity on the use of term 
``retrieve.'' The commenter questioned whether we intended to use the 
word ``retrieve'' in the certification criterion to mean solely the 
retrieval of information available to Certified EHR Technology or if we 
intended for it to also include the interactive retrieval of medication 
list information from external sources. The commenter suggested we 
clarify that ``retrieve'' meant retrieval of only information 
internally available to Certified EHR Technology. Other commenters, 
similar to their comments on the problem list certification criterion, 
stated that there needed to be more clarity with respect to how the 
reference to ``longitudinal care'' applied to a Complete EHR or EHR 
Module used by an eligible hospital.
    Response. We clarify that for this certification criterion, and all 
other certification criteria, the term ``retrieve'' means the retrieval 
of information directly stored and managed by Certified EHR Technology 
and that it does not mean the retrieval of information from external 
sources, unless explicitly stated otherwise. We also take this 
opportunity, in the context of our response regarding ``longitudinal 
care'' above, to clarify that ``medication history'' is intended to 
include a record of prior modifications to a patient's medications.
    Comment. A commenter stated that there needs to be more clarity 
with respect to whether an EHR Module must maintain a list of all 
active medications or if a specialty system, such as a cardiology 
system, could maintain a list of medications specific to its specialty 
use and provide the list to the enterprise EHR.
    Response. If an EHR Module developer seeks to have its ``medication 
list EHR Module'' certified, the EHR Module must provide the 
capabilities specified by the certification criterion. We do not intend 
to limit how the EHR Module could appropriately provide these 
capabilities (i.e., whether the EHR Module must itself enable the user 
to electronically record, modify, and retrieve a patient's active 
medication list for longitudinal care, or whether the EHR Module could 
be designed to provide those capabilities through its interaction with 
a device or devices at the enterprise level).
    Comment. One comment stated that this criterion should include a 
provision to include the ability to transmit this information to public 
health entities as required by law.
    Response. Nothing we adopt in this final rule precludes such a 
capability from being included in a Complete EHR or EHR Module. That is 
not, however, currently a necessary requirement for certification.
    Comments. One commenter stated that it would need to perform 
extensive reprogramming to accommodate the standard we adopted if it 
meant modifying underlying medication databases. This commenter 
suggested that this standard as it applied to the maintenance of 
medication lists be deferred. Along those lines, a couple of commenters 
stated that more clarification was needed with respect to whether 
RxNorm identifiers needed to be stored internally within Certified EHR 
Technology or only needed to be used upon the electronic exchange of 
health information. Other commenters expressly stated that the mapping 
of the vocabulary be limited to instances where the electronic exchange 
of health information would take place.
    Response. We understand these commenters' concerns and agree that 
it would be premature to require the use of the adopted standard in 
this context. In that regard, we seek to clarify for commenters our 
intention, which was solely to associate this adopted standard (as some 
commenters suggested) with the certification criteria that require the 
capability to electronically exchange health information. We recognize 
that continuing to associate this standard with the adopted 
certification criterion could potentially impose a significant burden 
on the industry, which we did not intend. Accordingly, we have removed 
from this certification criterion the requirement to use this standard. 
We discuss our response to comments on the standard itself in the 
context of the patient summary record certification criterion.

[[Page 44605]]

Section 170.302(d)--Maintain Active Medication Allergy List

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Maintain active medication      More than 80% of   Interim Final Rule
 allergy list.                   all unique         Text:
                                 patients seen by  Maintain active
                                 the EP or          medication allergy
                                 admitted to the    list. Enable a user
                                 eligible           to electronically
                                 hospital's or      record, modify, and
                                 CAH's inpatient    retrieve a patient's
                                 or emergency       active medication
                                 department (POS    allergy list as well
                                 21 or 23) have     as medication
                                 at least one       allergy history for
                                 entry (or an       longitudinal care.
                                 indication that   Final Rule Text:
                                 the patient has    Unchanged
                                 no known          Now Sec.
                                 medication         170.302(e).
                                 allergies)
                                 recorded as
                                 structured data.
------------------------------------------------------------------------

    Comments. Much like the prior certification criterion, many 
commenters signaled their support for this certification criterion. 
Other commenters raised the same points related to this certification 
criterion as they did for the medication list certification criterion.
    Response. We believe our responses to the problem list and 
medication list certification criteria are applicable to these repeated 
comments.
    Comments. Many commenters suggested that non-medication allergies 
be added to this certification criterion. A few commenters stated that 
it could jeopardize patient safety if not all allergens were included 
in Certified EHR Technology.
    Response. Patient safety is one of HHS's top priorities. At the 
present time, the final meaningful use objective and measure focus on 
medication allergies. Accordingly, we have adopted a certification 
criterion to support this objective and measure. We would like to 
reiterate, however, that a certification criterion sets the floor not 
the ceiling for the capabilities Certified EHR Technology must include. 
We encourage Complete EHR and EHR Module developers to provide more 
comprehensive capabilities than those currently required for achieving 
certification.
Section 170.302(e)--Record and Chart Vital Signs

------------------------------------------------------------------------
Meaningful use Stage 1   Meaningful use Stage
       objective              1 measure         Certification criterion
------------------------------------------------------------------------
Record and chart        For more than 50% of   Interim Final Rule Text:
 changes in vital        all unique patients   (1)Vital signs. Enable a
 signs:                  age 2 and over seen    user to electronically
 Height          by the EP or           record, modify, and
 Weight          admitted to eligible   retrieve a patient's
 Blood           hospital's or CAH's    vital signs including,
 pressure                inpatient or           at a minimum, the
 Calculate and   emergency department   height, weight, blood
 display BMI             (POS 21 or 23),        pressure, temperature,
 Plot and        height, weight and     and pulse.
 display growth charts   blood pressure are    (2)Calculate body mass
 for children 2-20       recorded as            index. Automatically
 years, including BMI.   structured data.       calculate and display
                                                body mass index (BMI)
                                                based on a patient's
                                                height and weight.
                                               (3) Plot and display
                                                growth charts. Plot and
                                                electronically display,
                                                upon request, growth
                                                charts for patients 2-20
                                                years old.
                                               Final Rule Text: Sec.
                                                170.302(f).
                                               (1)Vital signs. Enable a
                                                user to electronically
                                                record, modify, and
                                                retrieve a patient's
                                                vital signs including,
                                                at a minimum, height,
                                                weight, and blood
                                                pressure.
                                               (2) Unchanged
                                               (3) Unchanged
------------------------------------------------------------------------

    Comment. One commenter noted that the units of measurement should 
be specified in the EHR with regards to vital signs. For example that 
height should be specified in inches or centimeters.
    Response. We do not believe that this level of specificity is 
necessary. We expect that Complete EHR and EHR Module developers will 
include the units of measure that their customers believe are necessary 
to meet their needs, which in many cases will include those that 
patients routinely request. We also expect that many Complete EHR and 
EHR Module developers will offer both metric units and U.S. units of 
measurement, as a standard business practice.
    Comments. In what appeared to be a reaction to the proposed 
meaningful use objective and measure, some commenters requested that we 
remove BMI as part of the certification criterion for Complete EHR or 
EHR Modules designed for an inpatient setting. The rationale provided 
was that acute care providers would not be required to track BMI.
    Response. While we can understand these commenters' concern, we 
believe that BMI is a simple mathematical calculation that Certified 
EHR Technology should be capable of performing regardless of the 
setting for which it is designed.
    Comment. One commenter recommended that BMI and age components 
should be used to create an alert when an unhealthy BMI is indicated 
for a patient and that Certified EHR Technology should record whether 
the patient was informed of the unhealthy BMI status.
    Response. We believe that this recommendation is overly specific, 
is more germane to meaningful use, and exceeds the type of capability 
we believe should be specified as a condition of certification.
    Comments. A few commenters noted this certification criterion 
applies more directly to specialties that predominantly treat children. 
For other specialties, this criterion would add unnecessary cost and 
complexity to many HIT products that they would use. Many commenters 
suggested that a growth chart component should not be required for EHR 
technology designed for an inpatient setting, as it is not feasible to 
track this data in a meaningful way over a long enough period of time 
in an inpatient setting (which is typically of a short and

[[Page 44606]]

infrequent duration). A couple of commenters suggested that non-
traditional forms of growth charts should be accepted. One commenter 
suggested that the certification criterion establish a baseline, but 
should not limit the expansion of this capability to other ages. Other 
commenters made specific suggestions for different age ranges, such as 
including children under the age of two and lowering the upper age to 
ages less than 20 years old (e.g., 18).
    Response. As we stated above with respect to the calculation of 
BMI, we believe that Certified EHR Technology should be capable of 
performing this capability regardless of the setting for which it is 
designed. Moreover, with respect to whether growth charts should be 
applicable to Complete EHRs and EHR Modules designed for an inpatient 
setting, we remind commenters that children's hospitals qualify as 
eligible hospitals under the Medicaid EHR incentive program and will 
also need to demonstrate meaningful use of Certified EHR Technology. We 
do not preclude Complete EHR and EHR Module developers from designing 
novel approaches to displaying growth charts. Finally, we concur with 
the commenter that suggested this certification criterion should be a 
baseline. We reiterate that this certification criterion establishes a 
floor, not a ceiling, and we encourage Complete EHR and EHR Module 
developers to include additional functionality where it will enhance 
the quality of care that eligible professionals and eligible hospitals 
can provide.
    Comments. Similar to the comments above, many commenters suggested 
the growth chart requirement should include children under age 2. The 
charting would then include: weight, length, pulse oximetry, head 
circumference, and blood pressure (with percentiles based on age and 
weight).
    Response. For Stage 1, the related meaningful use objective 
addresses ages 2-20. In order to remain consistent with and support 
this objective, we do not believe that it is necessary at this time to 
require a capability for charting any additional ages as a condition of 
certification.
    Comment. One commenter requested that we clarify whether ``plot and 
electronically display'' means to plot height, weight, and BMI over 
time or against national norms.
    Response. We clarify that we expect a growth chart to plot the 
height, weight, and BMI over time, as compared to national norms. While 
the regulation text does not specifically require comparison to 
national norms, we understand that this type of information is 
typically provided along with the growth chart itself to provide 
greater relevance and meaning for the growth charts. We encourage 
Complete EHR and EHR Module developers to include this feature.
    Comment. A commenter suggested that SNOMED-CT[supreg] be used for 
designation of BMI.
    Response. Although we agree that SNOMED-CT[supreg] could be used to 
code BMI, we only require that Certified EHR Technology be capable of 
calculating BMI. We do not believe that it is necessary, as a condition 
of certification, to specify how BMI should be coded. That being said, 
we do not preclude the use of SNOMED-CT[supreg] to code BMI.
    Comment. One commenter suggested that the certification criterion 
should be better aligned with the final meaningful use objective and 
measure. The commenter noted that the criterion includes temperature 
and pulse, which is not included in the meaningful use objective and 
measure.
    Response. We agree with the comment and have removed temperature 
and pulse from the certification criterion.
Section 170.302(f)--Smoking Status

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Record smoking status for       More than 50% of   Interim Final Rule
 patients 13 years old or        all unique         Text:
 older.                          patients 13       Smoking status.
                                 years old or       Enable a user to
                                 older seen by      electronically
                                 the EP or          record, modify, and
                                 admitted to the    retrieve the smoking
                                 eligible           status of a patient.
                                 hospital's or      Smoking status types
                                 CAH's inpatient    must include:
                                 or emergency       current smoker,
                                 department (POS    former smoker, or
                                 21 or 23) have     never smoked.
                                 smoking status    Final Rule Text: Sec.
                                 recorded as          170.302(g).
                                 structured data.  Smoking status.
                                                    Enable a user to
                                                    electronically
                                                    record, modify, and
                                                    retrieve the smoking
                                                    status of a patient.
                                                    Smoking status types
                                                    must include:
                                                    current every day
                                                    smoker; current some
                                                    day smoker; former
                                                    smoker; never
                                                    smoker; smoker,
                                                    current status
                                                    unknown; and unknown
                                                    if ever smoked.
------------------------------------------------------------------------

    Comments. Several commenters stated that the smoking status 
certification criterion was overly prescriptive because it specified 
certain status variables. These commenters agreed that recording 
smoking status is crucial to health improvement efforts, but contended 
that mandating certain fields was the wrong approach. Many of these 
commenters stated that they were unaware of defined industry standard 
value set for smoking terminology and other suggested that our 
reference to specific types of smokers be removed. Others asked whether 
these variables were examples or the only responses allowed. A few 
commenters agreed with this certification criterion as reasonable and 
appropriate because it would provide value for both clinical care and 
public health. Commenters recommended that besides what we had 
specified, the certification criterion should also reference packs per 
day history information, secondhand smoke exposure, and alcohol 
consumption information. Other commenters recommended that the 
certification criterion be changed to reflect tobacco use rather than 
smoking.
    Response. We have adopted this certification criterion to fully 
support the final meaningful use objective and measure, which in 
response to comments has been revised to further clarify the purpose of 
the objective and measure. We therefore disagree with those commenters 
who stated that this certification criterion is too prescriptive. 
Concurring with CMS, we believe that the fields associated with this 
measure should mirror those expressed in the Centers for Disease 
Control and Prevention, National Center for Health Statistics, National 
Health Interview Survey related to smoking status recodes.\2\ 
Accordingly, the final certification criterion further specifies and 
slightly broadens the smoking statuses we expect Certified EHR 
Technology to be capable of recording. Generally speaking, we 
understand that a ``current every day smoker'' or ``current some day 
smoker'' is an individual who has smoked at least 100 cigarettes during 
his/her lifetime and still

[[Page 44607]]

regularly smokes everyday or periodically, yet consistently; a ``former 
smoker'' would be an individual who has smoked at least 100 cigarettes 
during his/her lifetime but does not currently smoke; and a ``never 
smoker'' would be an individual who has not smoked 100 or more 
cigarettes during his/her lifetime.\3\ The other two statuses (smoker, 
current status unknown; and unknown if ever smoked) would be available 
if an individual's smoking status is ambiguous. The status ``smoker, 
current status unknown'' would apply to individuals who were known to 
have smoked at least 100 cigarettes in the past, but their whether they 
currently still smoke is unknown. The last status of ``unknown if ever 
smoked'' is self-explanatory.
---------------------------------------------------------------------------

    \2\ Smoking status recodes: http://www.cdc.gov/nchs/nhis/
tobacco/tobacco_recodes.htm.
    \3\ ftp://ftp.cdc.gov/pub/Health_Statistics/NCHS/datasets/
DATA2010/Focusarea27/O2701a.pdf.
---------------------------------------------------------------------------

Section 170.302(g)--Incorporate Laboratory Test Results

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Incorporate clinical lab-test   More than 40% of   Interim Final Rule
 results into certified EHR      all clinical lab   Text:
 technology as structured data.  tests results     (1) Receive results.
                                 ordered by the     Electronically
                                 EP or by an        receive clinical
                                 authorized         laboratory test
                                 provider of the    results in a
                                 eligible           structured format
                                 hospital or CAH    and display such
                                 for patients       results in human
                                 admitted to its    readable format.
                                 inpatient or      (2) Display codes in
                                 emergency          readable format.
                                 department (POS    Electronically
                                 21 or 23) during   display in human
                                 the EHR            readable format any
                                 reporting period   clinical laboratory
                                 whose results      tests that have been
                                 are either in a    received with
                                 positive/          LOINC[supreg] codes.
                                 negative or       (3) Display test
                                 numerical format   report information.
                                 are incorporated   Electronically
                                 in certified EHR   display all the
                                 technology as      information for a
                                 structured data.   test report
                                                    specified at 42 CFR
                                                    493.1291(c)(1)
                                                    through (7).
                                                   (4) Update. Enable a
                                                    user to
                                                    electronically
                                                    update a patient's
                                                    record based upon
                                                    received laboratory
                                                    test results.
                                                   Final Rule Text: Sec.
                                                      170.302(h).
                                                   (1) Unchanged.
                                                   (2) Display test
                                                    report information.
                                                    Electronically
                                                    display all the
                                                    information for a
                                                    test report
                                                    specified at 42 CFR
                                                    493.1291(c)(1)
                                                    through (7).
                                                   (3) Incorporate
                                                    results.
                                                    Electronically
                                                    attribute,
                                                    associate, or link a
                                                    laboratory test
                                                    result to a
                                                    laboratory order or
                                                    patient record.
------------------------------------------------------------------------

Comments on 170.302(g)(1)
    Comments. A few commenters suggested that we specify in the 
regulation that the reference to receiving clinical laboratory test 
results in a ``structured format'' means in HL7 version 2.3.1 format. 
These commenters further recommended that we refer to HL7 version 2.3.1 
within the certification criterion. These commenters stated that many 
Complete EHR and EHR Module developers already use HL7 2.3.1 and that 
adopting it as a standard would spur industry-wide adoption and also 
set the stage for driving adoption of future HL7 standards, like HL7 
2.5.1, in the later stages of meaningful use. A commenter in support of 
including HL7 2.3.1 stated that it was concerned that if we did not 
specify a standard for this requirement that there could be confusion 
regarding which version of the standard should be used, and that 
laboratories would have to continue to support multiple standards. 
Another commenter also noted that we did not specify a standard format 
for the laboratory results that Certified EHR Technology must be 
capable of receiving. This commenter, however, stated that many EHRs 
are compliant with HL7 2.5.1 for the purposes of receiving laboratory 
results. The commenter also recommended that we apply this 
certification criterion differently for ambulatory and inpatient 
settings by requiring that Complete EHRs and EHR Modules designed for 
an ambulatory setting be required to receive HL7 2.5.1 formatted 
laboratory test results and those designed for an inpatient setting be 
required to receive HL7 2.3.1 formatted laboratory test results. One 
commenter suggested that our objectives could be better supported if we 
stated that in this certification criterion a requirement that 
laboratory results must be received electronically using HL7 
transactions with implementation guidance.
    Response. While we understand the intent of these commenters' 
suggestions, we do not believe that it is within the scope of this rule 
to dictate the standard by which laboratories transmit test results. 
The scope of this rule is the adoption of certification criteria that 
specify required capabilities of Certified EHR Technology (in this 
case, receiving laboratory information in structured format) and not, 
in this instance, specifying the standard by which laboratories must 
transmit test results.
    Comment. A commenter requested that we clarify how this 
certification criterion is applicable to hospital settings. The 
commenter asked whether we intended for the capability of receiving 
laboratory test results to include results obtained during a patient's 
stay at the hospital or if we meant to also include the receipt of 
laboratory test results from other time periods. They suggested 
requiring only those laboratory test results obtained during the 
patient stay.
    Response. For the purposes of demonstrating compliance with this 
certification criterion, we do not specify the contexts (e.g., a 
patient stay) under which laboratory test results are received. Rather, 
consistent with the meaningful use objective and measure and the 
capabilities required by this certification criterion, we specify that 
when laboratory test results are received in structured format by 
Certified EHR Technology, that the results can be incorporated.
    Comment. One commenter requested that we clarify whether the 
structured data requirement applies to all laboratories (including 
reference labs, hospital labs, physician office labs, and physicians 
performing their own lab tests).
    Response. This certification criterion requires Complete EHRs and 
EHR Modules to provide the capability to receive clinical laboratory 
test results in a structured format as a condition of certification. It 
does not speak to how laboratories must send the test results.

[[Page 44608]]

Comments on 170.302(g)(2)
    Comments. Some commenters requested clarification on this specific 
capability within the certification criterion regarding what needed to 
be displayed in the context of LOINC codes. These commenters suggested 
that we not require the display of the actual LOINC code, but the 
description associated with the LOINC code. A commenter suggested that 
we identify a subset of common LOINC codes instead of requiring that 
tens of thousands of LOINC codes be supported for the purposes of 
certification. Other commenters suggested that we offer guidance in the 
form of a ``starter set'' of LOINC codes to encourage the use of the 
standard. One commenter requested that we confirm its understanding of 
this specific part of the certification criterion, which is that 
Certified EHR Technology must demonstrate the capability to import 
LOINC coded results from an external source. Finally, one commenter 
noted that the heading for the standard at Sec.  170.205(a)(2)(iii) 
should just refer to ``laboratory test results'' and not ``laboratory 
orders and results.''
    Response. We clarify that we do not expect Certified EHR Technology 
to natively (or internally) support LOINC in its entirety, which is why 
we do not believe that it is necessary to specify a subset of common 
LOINC codes. Given the diverse comments and requests for clarification 
on this specific aspect of the certification criterion, we agree with 
commenters that we should not require a LOINC code that has been 
received, to then be displayed. Accordingly, we have decided to remove 
this requirement from the certification criterion. We do, however, wish 
to further clarify our current approach to Certified EHR Technology's 
use of LOINC codes. Presently, we expect Certified EHR Technology to be 
able to reuse a LOINC code once it has been received and is accessible 
to Certified EHR Technology. We do not expect, as we mention above, 
that Certified EHR Technology will have to crosswalk or map internal or 
local codes to LOINC codes. This clarification is applicable to the 
standard that we have adopted regarding LOINC codes now specified at 
Sec.  170.207. This response is applicable to similar comments we 
received on other certification criteria that also referenced the use 
of LOINC codes. Finally, we agree with the commenter who suggested that 
we revise the heading of the standard at Sec.  170.205(a)(2)(iii). We 
have done this as part of the overall restructuring of the regulation 
text.
Comments on 170.302(g)(3)
    Comments. Some commenters agreed with the capability specified in 
170.302(g)(3). One noted a concern that modifications to either a 
certified Complete EHR or certified EHR Module could potentially result 
in the failure of Certified EHR Technology to display the test report 
information as required by the regulations and, thereby, put the 
laboratory in technical violation of the CLIA regulations. These 
commenters reasoned that because a Complete EHR or EHR Module must be 
tested and certified to be in compliance with 42 CFR 493.1291(c)(1) 
through (7) that certification should replace any requirement for the 
laboratory to confirm that the information has been properly 
transmitted and meets the CLIA requirements. These commenters also 
asserted that a laboratory should be relieved of any further regulatory 
responsibility under 42 CFR 493.1291(c)(1) through (7) for the display 
of the required report information to the physician or subsequent 
viewers of the information if the Certified EHR Technology has been 
implemented by an eligible professional or eligible hospital. One 
commenter reiterated the point by stating that because Certified EHR 
Technology would be required to display the required CLIA report 
elements, laboratories should not be unfairly held accountable for any 
elements that may be removed or altered by other parties from the test 
report before received by the physician.
    Response. While we can understand the concern expressed by these 
commenters, we reiterate that 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.
Comments on 170.302(g)(4)
    Comments. A couple of commenters questioned whether we intended for 
the ``updates'' to be manual updates of electronic records. If that 
were true, some commenters were concerned that would create workflow 
problems and reduce the availability of results. Other commenters 
suggested that either the user be able to create an additional record, 
rather than be permitted to change the ``official'' record or that an 
adequate audit trail be preserved of the existing data and any updates, 
since an update may result in disparities with the official record of 
test results. These commenters wanted to ensure that the laboratory's 
record would be the same as the record maintained in the EHR. One 
commenter stated that paragraph (g)(4) could imply process and system 
behavior that we did not intend to require. The commenter stated that 
it is common practice in a hospital setting for lab results to be 
transmitted in high volume from a lab system to an EHR and made 
available for review to the clinician through the EHR, without a need 
for a user to review each transaction before updating the EHR to make 
the results available. Another commenter made a similar point and 
questioned whether an ``update'' meant manual intervention, which they 
stated would be impracticable in a hospital setting. One commenter 
stated that most EHR technology already links orders to lab results in 
an established way. The commenter also indicated that the certification 
criterion we adopted requires changes to a process that most EHR 
developers have already implemented and introduces inefficiencies for 
both EHR developers and health care providers.
    Response. We appreciate the issues raised by commenters on this 
specific capability and have revised this part of the certification 
criterion to more clearly express our expectation for Certified EHR 
Technology and to be responsive to and consistent with commenters' 
suggestions. We intended for an update to mean, as indicated by the 
meaningful use objective and measures, that a laboratory test result 
would be incorporated in Certified EHR Technology with the originating 
laboratory order or with a patient's record in any one of the methods 
specified. Accordingly we have revised this specific capability to more 
clearly reflect our intent. We believe this addresses commenters' 
concerns and requests for clarification and would permit batches of 
laboratory test results to be electronically linked to laboratory 
orders or patient records without manual intervention.
    Comments. Some commenters noted that small and medium size 
practices have had a difficult time working with commercial laboratory 
vendors to provide interfaces from which they can receive lab test 
results. These commenters noted that laboratory vendors typically 
charge too much for their services and do not prioritize establishing 
connections with small and medium size practices because they do not 
have the same volume of laboratory referrals as large practices.
    Response. This certification criterion requires as a condition of 
certification that Certified EHR Technology be capable of supporting 
electronic laboratory interfaces. We understand the

[[Page 44609]]

concerns raised by commenters pertaining to the difficulty of certain 
practices being able to obtain laboratory interfaces and note that the 
meaningful use Stage 1 measure associated with this certification 
criterion is included in the ``menu set'' specified by CMS which we 
believe should help assuage some commenters' concerns. We do not 
believe that the ability of a practice (regardless of size) to obtain 
an interface or other type of connection is an issue that is within the 
scope of this final rule to address.
    Comment. One commenter recommended that we revise this 
certification criterion to require that laboratory domain expertise be 
exhibited when laboratory information is displayed. The commenter 
further elaborated by stating that laboratory results are not 
homogeneous, and that specific laboratory domain expertise is necessary 
to design the ways in which the data associated with certain laboratory 
results (e.g., microbiology, molecular pathology) are displayed in EHR 
systems to ensure appropriate presentation and interpretation.
    Response. With the exception of displaying the required elements 
specified at 42 CFR 493.1291(c)(1) through (7), we do not require as a 
condition of certification any additional display requirements. 
Accordingly, we do not preclude Complete EHR and EHR Module developers 
from designing more specific displays of laboratory results that may 
need to be displayed in a more complex fashion.
    Comment. One commenter requested that we clarify that Certified EHR 
Technology did not need to enable the EHR Technology user to receive 
voluminous raw or pre-final-report lab data, and further, that not 
providing this capability would not disqualify a Complete EHR or EHR 
Module from becoming certified.
    Response. Enabling a Complete EHR or EHR Module to receive ``raw or 
pre-final-report lab data'' is not required under this or any other 
adopted certification criterion.
    Comment. One commenter suggested that we modify this certification 
criterion to require transmission of cancer related lab tests and 
results to cancer registries as required by law.
    Response. Because this certification criterion is about 
incorporating lab test results in Complete EHRs and EHR Modules and 
does not require any electronic transmissions, we do not believe that 
this is an appropriate requirement to consider.
Section 170.302(h)--Generate Patient Lists

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Generate lists of patients by   Generate at least  Interim Final Rule
 specific conditions to use      one report         Text:
 for quality improvement,        listing patients  Generate patient
 reduction of disparities,       of the EP,         lists. Enable a user
 research or outreach.           eligible           to electronically
                                 hospital or CAH    select, sort,
                                 with a specific    retrieve, and output
                                 condition.         a list of patients
                                                    and patients'
                                                    clinical
                                                    information, based
                                                    on user-defined
                                                    demographic data,
                                                    medication list, and
                                                    specific conditions.
                                                   Final Rule Text: Sec.
                                                      170.302(i).
                                                   Generate patient
                                                    lists. Enable a user
                                                    to electronically
                                                    select, sort,
                                                    retrieve, and
                                                    generate lists of
                                                    patients according
                                                    to, at a minimum,
                                                    the data elements
                                                    included in:
                                                      (1) Problem list;
                                                   (2) Medication list;
                                                   (3) Demographics; and
                                                   (4) Laboratory test
                                                    results.
------------------------------------------------------------------------

    Comments. Several commenters requested clarification regarding the 
set of variables that should be included in the demographic information 
for the patient lists. Some of these commenters suggested that the 
gender, race, ethnicity and preferred language of the patient should be 
included in this data set. One commenter suggested that the final rule 
should explicitly adopt and incorporate the recommendations of a report 
published by the Institute of Medicine in mid-2009 entitled, ``Race, 
Ethnicity and Language Data: Standardization for Health Care Quality 
Improvement.''
    Response. We appreciate the commenters' suggestions, and we have 
used them to clarify this certification criterion. It was our intention 
that Certified EHR Technology would be able to leverage the 
information, specifically the structured data it has available to it, 
to assist eligible professionals and eligible hospitals to generate 
patient lists. We have clarified this certification criterion to 
express this intent. Accordingly, we expect that Certified EHR 
Technology will be able to generate patient lists according to certain 
data elements for which structured data will be available: Medical 
problems; medications; demographics; and laboratory test results. While 
we respect the work completed by the Institute of Medicine, we do not 
believe that the public has had an adequate opportunity to consider its 
recommendations related to demographics in the context of 
certification, and we are therefore not including them as a condition 
of certification at this time. We encourage the HIT Standards Committee 
to consider this report as it recommends standards to the National 
Coordinator.
    Comments. Several commenters requested further clarification 
regarding the meaning of ``patient's clinical information.'' Other 
commenters stated that this phrase was too vague and was not included 
as part of the proposed meaningful use objective or measure and should 
therefore be removed. Some commenters requested further definition of 
the term ``specific conditions,'' particularly to clarify whether this 
term refers to problems and diagnoses. Clarification was also requested 
regarding whether this information includes: a patient summary; the 
patient's entire medical history; and patient encounter notes. One 
commenter recommended that we clarify how the lists must be structured 
and suggested that we specify time periods for patient histories. One 
commenter requested clarification of the term ``output,'' and suggested 
that it should mean to produce a list for internal use and that it does 
not refer to exporting the patient list to a system or destination 
external to the office of an eligible professional.
    Response. We appreciate the concerns raised by these commenters and 
after further consideration agree that the terms referenced by 
commenters could be interpreted in multiple ways. Accordingly we have 
removed ``patient's clinical information'' and ``specific conditions'' 
from the certification criterion, and have reframed the certification 
criterion to more directly

[[Page 44610]]

align with the meaningful use measure by changing ``output'' to 
``generate.'' We sought to clarify that we intended that Certified EHR 
technology would be capable of electronically producing or 
``generating'' patient lists for an eligible professional or eligible 
hospital's subsequent use. We do not require as a condition of 
certification that time periods be associated with a patient list, but 
presumably time (i.e., the age of the information) could be one factor 
an eligible professional or eligible hospital could also use to sort 
their lists (e.g., patients with XYZ problem recorded in the past 3 
months). We believe that these revisions make this certification 
criterion clearer while addressing these commenters' concerns.
Section 170.302(i)--Report Quality Measures

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Eligible Professionals: Report  For 2011, provide  Interim Final Rule
 ambulatory clinical quality     aggregate          Text:
 measures to CMS or the States.  numerator,        (1) Display.
                                 denominator, and   Calculate and
                                 exclusions         electronically
                                 through            display quality
                                 attestation as     measures as
                                 discussed in       specified by CMS or
                                 section II(A)(3)   States.
                                 of [the Medicare  (2) Submission.
                                 and Medicaid EHR   Enable a user to
                                 Incentive          electronically
                                 Programs final     submit calculated
                                 rule].             quality measures in
                                                    accordance with the
                                                    standard and
                                                    implementation
                                                    specifications
                                                    specified in Sec.
                                                    170.205(e).
Eligible Hospitals and CAHs:    For 2012,          Final Rule Text: Sec.
 Report hospital clinical        electronically       170.304(j).
 quality measures to CMS or      submit the        (1) Calculate.
 the States.                     clinical quality  (i) Electronically
                                 measures as        calculate all of the
                                 discussed in       core clinical
                                 section II(A)(3)   measures specified
                                 of [the Medicare   by CMS for eligible
                                 and Medicaid EHR   professionals.
                                 Incentive         (ii) Electronically
                                 Programs final     calculate, at a
                                 rule].             minimum, three
                                                    clinical quality
                                                    measures specified
                                                    by CMS for eligible
                                                    professionals, in
                                                    addition to those
                                                    clinical quality
                                                    measures specified
                                                    in paragraph (1)(i).
                                                      (2) Submission.
                                                       Enable a user to
                                                       electronically
                                                       submit calculated
                                                       clinical quality
                                                       measures in
                                                       accordance with
                                                       the standard and
                                                       implementation
                                                       specifications
                                                       specified in Sec.
                                                         170.205(f).
                                                   Sec.   170.306(i).
                                                      (1) Calculate.
                                                       Electronically
                                                       calculate all of
                                                       the clinical
                                                       quality measures
                                                       specified by CMS
                                                       for eligible
                                                       hospitals and
                                                       critical access
                                                       hospitals.
                                                      (2) Submission.
                                                       Enable a user to
                                                       electronically
                                                       submit calculated
                                                       clinical quality
                                                       measures in
                                                       accordance with
                                                       the standard and
                                                       implementation
                                                       specifications
                                                       specified in Sec.
                                                         170.205(f).
------------------------------------------------------------------------

    Comments. Many commenters stated that the Physician Quality 
Reporting Initiative (PQRI) 2008 Registry XML specifications apply only 
in the context of eligible professionals. Some of these commenters went 
on to state that hospitals are not familiar with PQRI and have been 
submitting quality measurement data to CMS under a separate program. A 
few commenters recommended that this standard requirement be removed 
while several others stated we should adopt both Quality Reporting 
Document Architecture (QRDA) and the PQRI XML Registry specification in 
this rulemaking and move to a single standard in the next rulemaking. 
Other commenters recommended that QRDA not be adopted in this 
rulemaking. Several commenters suggested that an implementation 
specification for eligible hospitals be created if we intend to 
continue to require that quality measure be reported in the PQRI 
Registry XML format. One commenter expressed a concern that if the PQRI 
2008 Registry XML standard is maintained as the adopted standard that 
there is a danger that the certification Complete EHR and EHR Module 
developers obtain may become obsolete before Stage 1 has run its 
course. Finally, a couple of commenters suggested that ONC consider 
deferring the naming of a standard for submission of clinical quality 
measures until Stage 2 and instead only require what is necessary to 
support clinical quality measure submission in Stage 1.
    Response. Many commenters misinterpreted our intent with respect to 
the adoption of the PQRI 2008 Registry XML specification as the 
standard for electronically submitting quality reporting data to CMS. 
Presently, CMS requires the submission of aggregate, summary level data 
for the purposes of meaningful use and not data at the patient-specific 
level. It is our understanding that the PQRI 2008 Registry XML 
specification is capable of serving as the ``envelope'' for aggregate, 
summary level data. Accordingly, we do not believe that, as some 
commenters suggested, an eligible hospital's familiarity with the PQRI 
program is relevant to the adoption of this standard for this specified 
purpose. Nor do we believe that a specific implementation of this 
standard is necessary for hospital settings as the standard's purpose 
and the type of data it will transmit to CMS will be the same--
aggregate, summary level data. Through recent discussions with CMS 
since the publication of the Interim Final Rule we have determined that 
the PQRI 2009 Registry XML specification, a more recent version of the 
standards we adopted in the Interim Final Rule is a suitable 
replacement for 2008 version, and accordingly, we have adopted the 2009 
version in its place. We believe this revision should assuage some 
commenters' concerns about the obsolescence of the adopted standard and 
reduce concerns that a wholly different standard would be adopted in 
the near future. If adopting a different standard for Certified EHR 
Technology becomes necessary, we would do so only after engaging in 
subsequent rulemaking.
    Comments. A few commenters stated that many of the clinical quality 
measures proposed by CMS do not have electronic specifications and 
contended that it would be difficult for any vendor to have embedded 
these measures in their EHR products in a timely manner. But, these 
same commenters stated that when the specifications become available, 
that HHS should ensure through the certification process that the 
products are capable of generating accurate data. Many commenters 
expressed concerns that the certification criterion was too vague or 
too broad (because it implicitly referenced all of

[[Page 44611]]

the quality measures CMS had proposed). Some of the commenters 
recommended that this certification criterion be removed, while others 
recommended that it focus on a subset of measures in order to constrain 
the amount of electronic measure specifications a Complete EHR or EHR 
Module developer would need to address in order to be certified. At 
least one of these latter commenters indicated that our adopted 
certification criteria created uncertainty for Complete EHR and EHR 
Module Developers. This commenter asked that we clarify what clinical 
quality measures would need to be tested in order to satisfy this 
certification criterion and if there would be a baseline for eligible 
hospital measures as well as some identified core set of measures for 
eligible professionals. Along these same lines, another commenter 
recommended that EHR technology should be tested and certified only to 
the clinical quality measures applicable to the medical specialties of 
the eligible professionals that the EHR technology is intended to 
support and to whom it is marketed. Other commenters expressed concerns 
about timing and that a significant amount of effort would be required 
to reprogram Complete EHRs and EHR Modules to capture, calculate, and 
report the final meaningful use Stage 1 measures. Many commenters also 
stated that the proposed quality measures are not yet ready for 
automated reporting, that a significant amount of work is still 
required by the measure developer community, and that the value sets 
for these quality measures have not been validated. Several commenters 
objected to the reference to ``States'' in the certification criterion 
and recommended that it be removed. These commenters contended that the 
certification criterion should be limited to the ``federal 
requirements'' and further that it was unrealistic to expect Complete 
EHR and EHR Module developers to also comply with 50 separate State 
requirements as a condition of certification.
    Response. We understand that CMS has worked to significantly 
increase the availability of a number of electronic measure 
specifications that are associated with specific clinical quality 
measures. In light of the final approach CMS has taken with respect to 
clinical quality measures for meaningful use Stage 1, we have revised 
this certification to better align it with the Medicare and Medicaid 
EHR Incentive Programs final rule requirements. We also agree with 
those commenters that requested we explicitly focus the report of 
clinical quality measures certification criterion, and the 
certification criteria in general, on Federal requirements and have 
removed the reference to ``or States'' in this certification criterion.
    To better align this certification criterion with the final 
approach to clinical quality measures in the Medicare and Medicaid EHR 
Incentive Programs final rule, we have determined that it is no longer 
sufficient to specify one general certification criterion for both 
Complete EHRs and EHR Modules designed for either an ambulatory or 
inpatient setting. Accordingly, the final rule in Sec. Sec.  170.304 
and 170.306 will include a specific certification criterion for each 
setting. Complete EHRs and EHR Modules designed for an ambulatory 
setting will be required to be tested and certified as being compliant 
with all 6 of the core (3 core and 3 alternate core) clinical quality 
measures specified by CMS for eligible professionals (Section II(A)(3) 
of the Medicare and Medicaid EHR Incentive Programs final rule). 
Complete EHRs and EHR Modules designed for an ambulatory setting will 
also be required to be tested and certified as being compliant with, at 
a minimum, 3 of the additional clinical quality measures CMS has 
identified for eligible professionals (Section II(A)(3)of the Medicare 
and Medicaid EHR Incentive Programs final rule). We believe this 
revision provides clarity and flexibility and reduces the potential 
burden for Complete EHR and EHR Module developers (who may have been 
unfamiliar with certain clinical quality measures because of the type 
of eligible professional they serve) to become compliant with this 
certification criterion. As a result, Complete EHR and EHR Module 
developers for the ambulatory setting may provide Certified EHR 
Technology with a certain level of variability in terms of clinical 
quality measure capabilities. To provide further transparency for 
potential eligible professionals regarding the clinical quality 
measures to which a Complete EHR or EHR Module has been tested and 
certified, we specified that an ONC-Authorized Testing and 
Certification Body would need to report such information to the 
National Coordinator, and further, that the Complete EHR or EHR Module 
developer would need to make sure this information is available and 
communicated to prospective purchasers as part of the Complete EHR or 
EHR Module's certification.
    Complete EHRs and EHR Modules designed for an inpatient setting 
will be required to be tested and certified as being compliant with all 
of the clinical quality measures specified by CMS (Section II(A)(3) of 
the Medicare and Medicaid EHR Incentive Programs final rule) for 
eligible hospitals. Again, we believe this revision provides greater 
clarity and reduces the potential burden for Complete EHR and EHR 
Module developers.
    Comments. One commenter suggested that we separate the calculation 
and the submission parts of this certification criterion into two 
separate certification criteria.
    Response. We disagree. We see no basis for separating these two 
parts of this certification criterion into two separate certification 
criteria. However, we believe that it is necessary to specify two 
different certification criteria to account for the different clinical 
quality measures that eligible professionals and eligible hospitals 
will need to report. Accordingly, we have adopted separate 
certification criteria for Complete EHRs and EHR Modules designed for 
ambulatory and inpatient settings and referenced the respective quality 
measures for each in the appropriate certification criterion.
    Comments. One commenter suggested that all approved PQRI registries 
be automatically certified as an EHR Module.
    Response. We do not believe that it is prudent or appropriate to 
automatically deem certain HIT as certified. That being said, if a PQRI 
registry can adequately perform the capability specified by the 
certification criterion, it could be certified as an EHR Module.
    Comments. Several commenters stated that Certified EHR Technology 
should be capable of collecting quality measurement data and 
calculating results for reporting to avoid having eligible 
professionals and eligible hospitals perform these processes manually. 
These commenters also stated that Certified EHR Technology should be 
capable of accurately and reliably reporting quality measurement data. 
Some commenters recommended that a Complete EHR or EHR Module only be 
required to be certified to existing e-measure specifications.
    Response. We agree that the collection of clinical quality 
measurement data and the calculation of results for submission to CMS 
should be performed by Certified EHR Technology. We also agree that 
Complete EHRs or EHR Modules should only be required to be tested and 
certified to developed electronic measure specifications. This is why 
CMS has only specified clinical quality measures for eligible 
professionals and eligible hospitals in the Medicare and Medicaid EHR 
Incentive Programs final rule for which electronic measure

[[Page 44612]]

specifications have been developed. Complete EHR and EHR Module 
developers should follow these electronic measure specifications in 
order to accurately calculate clinical quality measures.
    Comments. Several commenters recommended that the certification 
criterion should be revised to include the word ``accurately.''
    Response. We expect that clinical quality measures would be 
accurately calculated and do not see a need to specifically include the 
word in the certification criterion.
Section 170.302(j)--Check Insurance Eligibility and Sec.  170.302(k)--
Submit Claims

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Removed from final rule.......  Removed from       Interim Final Rule
                                 final rule.        Text:
                                                      Enable a user to
                                                       electronically
                                                       record and
                                                       display patients'
                                                       insurance
                                                       eligibility, and
                                                       submit insurance
                                                       eligibility
                                                       queries to public
                                                       or private payers
                                                       and receive an
                                                       eligibility
                                                       response in
                                                       accordance with
                                                       the applicable
                                                       standards and
                                                       implementation
                                                       specifications
                                                       specified in Sec.
                                                         170.205(d)(1)
                                                       or (2).
                                                   Final Rule Text:
                                                   Removed.
------------------------------------------------------------------------


------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Removed from final rule.......  Removed from       Interim Final Rule
                                 final rule.        Text:
                                                      Enable a user to
                                                       electronically
                                                       submit claims to
                                                       public or private
                                                       payers in
                                                       accordance with
                                                       the standard and
                                                       implementation
                                                       specifications
                                                       specified in Sec.
                                                         170.205(d)(3).
                                                   Final Rule Text:
                                                   Removed.
------------------------------------------------------------------------

    Comments. Many commenters recommended that the certification 
criteria for administrative transactions be removed because they 
considered the administrative capabilities that we required to be 
outside of the scope of an electronic health record and stated further 
that their inclusion did not align with the HIT industry's common view 
of what constituted EHR technology. A large number of commenters 
conveyed specific challenges including: These functions are usually 
handled by practice management systems which generally are separate 
from an EHR, although on occasion some vendors include these 
functionalities in their EHRs; practice management systems adoption is 
already very high and requiring certification for these products would 
be unnecessary and burdensome, given the wide variety and number of 
vendors and significant potential for increasing costs for providers; 
providers interested in achieving meaningful use would have to abandon 
a working practice management system if their practice management 
vendors were unwilling or unable to get certified; and many providers 
currently use clearinghouses to convert paper claims into electronic 
claims to submit to CMS and other payers. Several commenters 
recommended retaining the administrative transactions certification 
criteria because it would eventually reduce administrative costs across 
the health care system. Many commenters requested that we clarify 
several aspects of these certification criteria while some other 
commenters noted that significant progress has been made in using 
electronic eligibility inquires and claims transactions outside of an 
EHR context. Those commenters expressed concern that the inclusion of 
administrative transaction capability in this rule would create 
confusion, ambiguity, and potentially duplicate efforts. A couple of 
commenters noted that some payers do not accept electronic claims and 
eligibility checks. One commenter expressly noted that including the 
administrative functionalities would decrease innovation by creating a 
large barrier to entry for EHR innovators. Finally, a couple of 
commenters noted that health care providers would face significant 
challenges in the transition to ASC X12N 5010 and ICD-10 and lost 
productivity.
    Response. In concert with CMS, we have considered commenters' 
rationale for and against the inclusion of these certification 
criteria. We have tried to summarize above several technical and 
programmatic challenges commenters identified if administrative 
transaction capability were included within the certification 
requirements. Due to the removal of these objectives from the 
meaningful use Stage 1 requirements, we do not believe that it would be 
appropriate to continue to require, as a condition of certification, 
that Complete EHRs and EHR Modules include these capabilities. 
Accordingly, we have removed the adopted standards, implementation 
specifications, and certification criteria related to these 
administrative transactions from this final rule.
    As CMS explains in more detail in the Medicare and Medicaid EHR 
Incentive Programs final rule, the subsequent inclusion of 
administrative simplification requirements as part of meaningful use 
Stage 2 is an important long-term policy goal. Administrative 
simplification can improve the efficiency and reduce unnecessary costs 
in the health care system as a whole; the small percentage of paper 
claims submitted represents a disproportionately high administrative 
cost for health plans; the reconciliation of billing charges for 
services not eligible for payment creates a significant burden for 
providers, health plans, and most significantly, for patients. 
Moreover, we believe that the integration of administrative and 
clinical information systems is necessary to support effective 
management and coordinated care in physician practices. For example, 
the ability to: leverage clinical documentation in support of 
appropriate charge capture (e.g., for preventive counseling, or 
immunizations provided); link lists of patients needing clinical 
reminders with patient contact information; stratify quality measures 
by patient demographic factors (e.g., race/ethnicity) and insurer 
status (e.g., Medicare beneficiaries).
    Additionally, we believe that important benefits can be recognized 
through the future adoption of administrative transactions standards 
and certification criteria for Complete EHRs and EHR Modules. Through 
the

[[Page 44613]]

use of EHR Modules, eligible professionals and eligible hospitals have 
the opportunity to use practice management systems or clearinghouses 
that provide the capability to conduct administrative transactions as 
components of Certified EHR Technology. In that regard, we recognize 
the concerns expressed by some commenters that the developers of some 
practice management systems may not be prepared to seek certification 
for these legacy systems in 2010 or 2011. We also acknowledge that the 
required compliance date of January 1, 2012 for ASC X12N version 5010 
transactions would further complicate the certification process 
associated with meaningful use Stage 1. However, we believe that after 
the ASC X12N version 5010 transition has occurred, and we approach the 
October 1, 2013 compliance date for HIPAA covered entities to use ICD-
10, our decision to delay the adoption of administrative transactions 
certification criteria will prove beneficial for the adoption of 
Certified EHR Technology.
    In order to meet upcoming administrative simplification deadlines, 
most health care providers will have to upgrade their practice 
management systems or implement new ones. This will provide an 
important opportunity to align EHR technology capabilities and 
standards for administrative transactions with the administrative 
simplification provisions that the Affordable Care Act provides for 
health plans and clearinghouses. Therefore, we intend to include for 
adoption, administrative transactions standards and certification 
criteria to support meaningful use Stage 2 rulemaking, and expect 
health care providers and Complete EHR and EHR Module developers to 
take this into consideration leading up to 2013.
    Comments. Many commenters recommended that we remove the 
implementation specification, CORE Phase 1 (CORE), which we previously 
adopted. Several commenters noted that CORE is only useful if it has 
also been adopted by health plans, and they explained that not all 
health plans had adopted CORE. A few commenters expressed concern with 
CORE stating that it adds requirements to the HIPAA Standard 
Transactions and did not follow the work of the standards development 
organization that maintains administrative transactions. A few 
commenters also believed that following CORE results in non-compliant 
ASC X12N 4010 transactions. Other commenters noted that it appeared 
that we had required CORE for both ASC X12N 4010 and 5010 standard 
transactions, but that CORE Phase 1 is only applicable to ASC X12N 4010 
standard transactions and cannot be used with ASC X12N 5010 standard 
transactions. A few commenters requested that we clarify whether 
providers and vendors will be required to receive CORE certification. 
Several commenters recommended ONC retain CORE Phase 1. A few 
commenters noted that CORE promotes uniformity and can provide 
significant reduction in transaction costs. A couple commenters 
recommended that ONC adopt subsequent CORE standards in future stages.
    Response. As previously mentioned, we have decided to align our 
revisions with the changes made in the Medicare and Medicaid EHR 
Incentive Programs final rule and to remove, as noted above, the 
standards, implementation specifications, and certification criteria 
associated with administrative transactions. Consistent with that 
approach, we are removing the CORE Phase 1 implementation specification 
for the reasons submitted in comments.
Section 170.302(l)--Medication Reconciliation

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
The EP, eligible hospital or    The EP, eligible   Interim Final Rule
 CAH who receives a patient      hospital or CAH    Text:
 from another setting of care    performs          Medication
 or provider of care or          medication         reconciliation.
 believes an encounter is        reconciliation     Electronically
 relevant should perform         for more than      complete medication
 medication reconciliation.      50% of             reconciliation of
                                 transitions of     two or more
                                 care in which      medication lists by
                                 the patient is     comparing and
                                 transitioned       merging into a
                                 into the care of   single medication
                                 the EP or          list that can be
                                 admitted to the    electronically
                                 eligible           displayed in real-
                                 hospital's or      time.
                                 CAH's inpatient   Final Rule Text: Sec.
                                 or emergency         170.302(j)
                                 department (POS   Medication
                                 21 or 23).         reconciliation.
                                                    Enable a user to
                                                    electronically
                                                    compare two or more
                                                    medication lists.
------------------------------------------------------------------------

    Comments. Many commenters suggested that for this certification 
criterion we clarify whether we intended for the process of medication 
reconciliation to be automatic or to support an eligible professional 
or eligible hospital in performing this task. Many saw the former as a 
potential risk to patient safety. Although several different reasons 
were given, many commenters recommended that we revise the 
certification criterion to indicate that two or more medication lists 
be simultaneously displayed in order to permit an eligible professional 
or eligible hospital to then reconcile the medication lists.
    Response. We have reviewed commenters' concerns and intend to 
clarify the language in this certification criterion. We recognize that 
the technical foundation and safety checks are not currently in place 
for automated medication reconciliation. We did not intend to imply 
that automated reconciliation needed to occur through our use of the 
word ``electronically.'' We used the term ``electronically'' to express 
our expectation that eligible professionals and eligible hospitals 
would be able to use Certified EHR Technology to complete this task. 
Accordingly, we have revised this certification criterion to require 
that Certified EHR Technology be capable of providing a user with the 
ability to electronically compare two or more medication lists (e.g., 
between an externally provided medication list and the current 
medication list in Certified EHR Technology). We expect that this could 
be done in a number of ways and we do not want to preclude Complete EHR 
and EHR Module developers from innovating, provided that the desired 
outcome is reached. For example, a user could be presented with two 
electronic lists side-by-side and move medications from one list to the 
other and then select the final current list. Alternatively, a user 
could view one list and two PDFs of other medications and use this 
capability to update the current medication list. We do, however, see 
great promise in making this capability more comprehensive and 
anticipate exploring ways to improve the utility of this capability 
before we adopt a subsequent round of certification criteria.
    Comments. Several commenters supported this certification 
criterion, but wanted clarification regarding how

[[Page 44614]]

we expected testing and certification to be accomplished, especially if 
only one medication list was in use.
    Response. We believe that the clarifications and revisions to the 
certification criterion and the discussion above clarify how we intend 
for this certification criterion to be tested.
    Comments. Several commenters requested that we clarify the meanings 
of ``medication reconciliation,'' ``transitions of care,'' and 
``relevant encounter.''
    Response. These terms are not used in the certification criterion. 
We encourage commenters to review the Medicare and Medicaid EHR 
Incentive Programs final rule to see how these terms have been 
clarified in response to public comments.
Section 170.302(m)--Submission to Immunization Registries

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Capability to submit            Performed at       Interim Final Rule
 electronic data to              least one test     Text:
 immunization registries or      of certified EHR  Submission to
 Immunization Information        technology's       immunization
 Systems and actual submission   capacity to        registries.
 in accordance with applicable   submit             Electronically
 law and practice.               electronic data    record, retrieve,
                                 to immunization    and transmit
                                 registries and     immunization
                                 follow up          information to
                                 submission if      immunization
                                 the test is        registries in
                                 successful         accordance with:
                                 (unless none of   (1) One of the
                                 the immunization   standards specified
                                 registries to      in Sec.
                                 which the EP,      170.205(h)(1) and,
                                 eligible           at a minimum, the
                                 hospital or CAH    version of the
                                 submits such       standard specified
                                 information have   in Sec.
                                 the capacity to    170.205(h)(2); or
                                 receive the       (2) The applicable
                                 information        state-designated
                                 electronically).   standard format.
                                                   Final Rule Text: Sec.
                                                      170.302(k).
                                                   Submission to
                                                    immunization
                                                    registries.
                                                    Electronically
                                                    record, modify,
                                                    retrieve, and submit
                                                    immunization
                                                    information in
                                                    accordance with:
                                                   (1) The standard (and
                                                    applicable
                                                    implementation
                                                    specifications)
                                                    specified in Sec.
                                                    170.205(e)(1) or
                                                    Sec.
                                                    170.205(e)(2); and
                                                      (2) At a minimum,
                                                       the version of
                                                       the standard
                                                       specified in Sec.
                                                         170.207(e).
------------------------------------------------------------------------

    Comments. A significant majority of commenters recommended that we 
remove paragraph (m)(2) related to the applicable state-designated 
format. These commenters contended that such a requirement was vague, 
could be problematic from an interoperability perspective, and would 
make certification impracticable.
    Response. We agree with those commenters that requested we 
explicitly focus the certification criterion and certification in 
general on Federal requirements. We have therefore removed the 
reference to ``applicable stated-designated standard format'' in the 
certification criterion. Additionally, we have reviewed this 
certification criterion and have determined that our reference to 
``immunization registries'' is unnecessary. We are primarily concerned 
with Certified EHR Technology's ability to transmit the immunization 
information in a standardized format, and do not believe that it is 
necessary to specify a particular recipient in the certification 
criterion.
    Comments. Many commenters supported our adoption of both HL7 2.3.1 
and HL7 2.5.1. Some commenters acknowledged that HL7 2.3.1 was more 
commonly used for the purpose of submitting information to immunization 
registries while other commenters suggested that we only adopt HL7 
2.5.1. Some commenters recommended that we keep our adopted standards 
the way they are. Others recommended that we only adopt HL7 2.3.1 
because most immunization registries cannot comply with HL7 2.5.1.
    Response. We appreciate that commenters support our adoption of 
both HL7 2.3.1 and HL7 2.5.1. We understand that both standards are 
currently in use and for that reason we have permitted either to be 
used for purposes of certification. We also understand that eligible 
professionals and eligible hospitals will have to use the standard that 
the immunization registry or Immunization Information System in their 
jurisdiction can receive and, as a result, we have adopted the two most 
common standards utilized for the transmission of immunization 
information.
    Comment. One commenter noted that it would be very helpful to 
provide a source for mapping from the NDC code on the vaccine packaging 
to the CVX/MVX codes used for interoperability, in anticipation of 
supporting barcode scanning of vaccines. Another commenter noted that 
while some mapping has occurred between CPT and CVX, they were not 
aware of a translation map from NDC to CVX. They also stated that even 
though a list of CVX codes is available, they were not aware of a 
downloadable immunization database using CVX codes. They considered 
this lack of a database a significant burden and impediment to 
compliance. The commenter concluded by suggesting that CPT codes be 
used instead of CVX codes, because CPT codes are used for billing 
purposes and would be readily available.
    Response. The CDC maintains an openly available list of updated CVX 
codes as well as a mapping of CVX codes to CPT codes on their Web 
site.\4\ Moreover, we believe that CVX codes are more appropriate than 
CPT codes because as the commenter referenced, CPT codes are used for 
billing purposes. In that regard, we believe that because there is a 
publicly available mapping between CVX and CPT, it would not be 
difficult or burdensome to map CPT codes to CVX codes. NDC codes were 
not adopted as a standard to represent immunizations and we do not 
believe that requiring their use for the purposes of demonstrating 
compliance with this certification criterion would be appropriate.
---------------------------------------------------------------------------

    \4\ http://www.cdc.gov/vaccines/programs/iis/stds/cpt.htm.
---------------------------------------------------------------------------

    Comment. One commenter recommended that we revise the certification 
criterion combined with associated standards to state, ``For the 
purposes of electronically submitting information to immunization 
registries Certified EHR Technology must be capable of using a 
certified EHR module or portal provided by a state immunization 
registry which is capable of submitting and retrieving coded 
immunization information or capable of using HL7 2.3.1 or HL7 2.5.1 as 
a content exchange standard and the CDC maintained HL7 standard code 
set CVX--Vaccines Administered as the vocabulary standard.'' The basis 
for this commenter's suggestion was that providers in its state link to 
the state's

[[Page 44615]]

immunization module through EHRs and that all immunization data are 
stored immediately in the state's registry. The commenter further 
clarified that since the data resides in the state registry natively, 
there is no need to transmit this information.
    Response. In light of this commenter's suggestion, we have revised 
the certification criterion to replace the word ``transmit'' with 
``submit'' to better align this certification criterion with the 
meaningful use objective and measure. We believe that submission of 
immunization data would encompass this commenter's existing method.
    Comment. One commenter stated that they believed the use of CVX is 
neither mature nor widespread.
    Response. We disagree. Our information indicates that CVX codes are 
widely used for reporting to immunization registries.
    Comment. Some commenters identified implementation specifications 
that are available for the standards we had adopted for transmitting 
immunization information. A couple of these commenters specifically 
recommended using implementation specifications that would identify 
message types necessary for transmissions to immunization registries. 
Commenters also suggested using the CDC's implementation guides, and 
explicitly recommended that we adopt the CDC public health information 
network (PHIN) implementation guide version 2.2 associated with HL7 
2.3.1 for the transmission of immunization information and the CDC 
implementation guide as well as the implementation guide associated 
with HL7 2.5.1.
    Response. In the Interim Final Rule, we expressed our interest in 
receiving public comment on whether there were additional 
implementation specifications that we should adopt. We also noted that 
we would consider adopting implementation specifications for any or all 
of the standards adopted in the Interim Final Rule. After further 
consideration of commenters' recommendations and consultation with the 
CDC, we agree with these commenters and believe that adopting 
implementation specifications for the transmission of immunization 
information would benefit EHR technology developers and users. 
Moreover, given commenters' general requests for greater specificity 
and our stated goal of greater interoperability, we believe that it 
would be appropriate to adopt the following implementation 
specifications for the submission of immunization data. For HL7 2.3.1 
we have adopted the ``Implementation Guide for Immunization Data 
Transactions using Version 2.3.1 of the Health Level Seven (HL7) 
Standard Protocol, Implementation Guide Version 2.2.'' We are aware 
that this implementation specification has been successfully adopted 
numerous times in various contexts since its publication four years ago 
and do not believe that it will be burdensome for Complete EHR and EHR 
Module developers to implement these specifications. For HL7 2.5.1, we 
have adopted the ``Implementation Guide for Immunization Messaging 
Release 1.0.'' This implementation specification represents the 
collaborative effort of the American Immunization Registry Association 
(AIRA) and the CDC. We have also consulted with CDC, and the CDC 
confirms the appropriateness and supports the usage of these 
implementation specifications in this context. We encourage migration 
to this newer implementation specification and believe that it will 
likely advance interoperability across the country and improve query 
capabilities.
    Comment. A commenter recommended that we clarify that the 
certification criterion should be limited to verifying the ability of 
the system to record, retrieve, and transmit immunization information.
    Response. The purpose of testing and certifying a Complete EHR or 
EHR Module to this certification criterion is to verify that it can 
perform the capabilities included in the certification criterion.
    Comment. A couple of commenters strongly supported the transmission 
of immunization data to state and local immunization registries but 
requested that the data requirements be expanded to include the 
transmission of information regarding diseases such as cystic fibrosis 
to pediatric registries.
    Response. Presently, we do not believe that it is necessary or 
appropriate to expand this certification criterion in this manner. We 
emphasize, though, that this should not preclude eligible professionals 
or eligible hospitals from using Certified EHR Technology to submit 
other types of information as medically appropriate and if the 
recipient of the information is capable of receiving the data.
    Comment. A commenter recommended including the term ``modify'' in 
the certification criterion.
    Response. We agree, and consistent with our other certification 
criteria that include the term ``modify,'' we have added this term.
Section 170.302(n)--Public Health Surveillance

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Capability to submit            Performed at       Interim Final Rule
 electronic syndromic            least one test     Text:
 surveillance data to public     of certified EHR  Public health
 health agencies and actual      technology's       surveillance.
 submission in accordance with   capacity to        Electronically
 applicable law and practice.    provide            record, retrieve,
                                 electronic         and transmit
                                 syndromic          syndrome-based
                                 surveillance       public health
                                 data to public     surveillance
                                 health agencies    information to
                                 and follow-up      public health
                                 submission if      agencies in
                                 the test is        accordance with one
                                 successful         of the standards
                                 (unless none of    specified in Sec.
                                 the public         170.205(g).
                                 health agencies   Final Rule Text: Sec.
                                 to which an EP,      170.302(l).
                                 eligible          Public health
                                 hospital or CAH    surveillance.
                                 submits such       Electronically
                                 information have   record, modify,
                                 the capacity to    retrieve, and submit
                                 receive the        syndrome-based
                                 information        public health
                                 electronically).   surveillance
                                                    information in
                                                    accordance with the
                                                    standard (and
                                                    applicable
                                                    implementation
                                                    specifications)
                                                    specified in Sec.
                                                    170.205(d)(1) or
                                                    Sec.
                                                    170.205(d)(2).
------------------------------------------------------------------------

    Comments. A couple of commenters supported the adoption of 
certification criteria related to public health reporting. One 
commenter believed that this certification criterion should be 
implemented as adopted.
    Response. We appreciate commenters' support of this certification 
criterion.
    Comment. One commenter recommended that we defer any vocabulary 
standard for public health reporting and surveillance until a later 
date. Another commenter expressed

[[Page 44616]]

concern that we would adopt as a standard, ``according to applicable 
public health agency requirements,'' because they thought it could be 
problematic for hospital systems with facilities in two or more states, 
as their EHR technology would have to meet whatever standards each 
state elected to use.
    Response. We clarify for commenters that we adopted two content 
exchange standards for electronic submission to public health agencies 
for surveillance and reporting. We did not adopt a specific vocabulary 
standard, nor did we include the phrase one commenter stated that we 
included. However, we have, consistent with our rationale in the 
immunization submission certification criterion, removed our reference 
to ``public health agencies'' as the recipient of information. Also, 
consistent with the certification criterion above, we have replaced the 
term ``transmit'' with ``submit.''
    Comments. A couple of commenters stated that compliance with HL7 
2.5.1 not be included in this adopted set of standards. One commenter 
suggested HL7 2.5.1 should be adopted in a future rulemaking. Another 
commenter suggested that HL7 2.3.1 be required for the purposes of 
certification. Another commenter recommended that the standard be HL7 
2.3.1, because in its opinion many public health agencies cannot comply 
with HL7 2.5.1 while another commenter took the opposite position and 
recommended HL7 2.5.1.
    Response. Given the diversity in implementations and public health 
agencies' ability to receive information in a given standard, we 
believe that the flexibility included in this criterion is necessary 
for the foreseeable future. However, relative to the general comments 
we received regarding the adoption of implementation specifications for 
adopted standards, we have adopted the following implementation 
specifications for HL7 2.5.1: Public Health Information Network HL7 
Version 2.5 Message Structure Specification for National Condition 
Reporting Final Version 1.0 and the Errata and Clarifications National 
Notification Message Structural Specification. We believe that these 
implementation specifications provide the additional clarity commenters 
were seeking and will enable Complete EHR and EHR Module developers to 
focus their efforts on a more specific implementation of the HL7 2.5.1 
standard. We do not believe that a suitable implementation 
specification for HL7 2.3.1 exists for the purpose of public health 
surveillance and reporting.
    Comments. Multiple commenters stated concerns that the Federal 
government and state governments, as well as other public health 
agencies, do not have the capability to receive information 
electronically in a standardized format. One commenter stated that 
while they supported using the HL7 standards, some agencies are only 
able to accept public health submissions if they have an HL7-based 
feed. Several commenters suggested that the public health reporting 
requirement be delayed until a single, national standard exists. One 
commenter stated that requiring EHRs to ``electronically record, 
retrieve, and transmit syndrome-based public health surveillance 
information to public health agencies'' is a worthwhile future goal, 
but they strongly questioned the likelihood that it could be 
accomplished within the 2011-2012 timeframe. The commenter also noted 
that the certification criterion did not specify which agencies (local, 
state, Federal) are included, and that most of those agencies are not 
prepared to receive biosurveillance data electronically in the format 
specified. The commenter concluded that it would be difficult for any 
EHR to prove compliance with the certification criterion as written and 
recommended the following alternative: ``Electronically record, 
retrieve, and be capable of producing an electronic message containing 
syndrome-based public health surveillance information in accordance 
with one of the standards specified in Sec.  170.205(g).''
    Response. We recognize that some public health agencies do not yet 
have the capability of electronically receiving information. We do not 
believe that this should serve as a limiting factor, however, or 
preclude Certified EHR Technology from having the capability to 
transmit information in a standard format.
    Comment. One commenter commented that if a public health agency is 
unable to accept the data, separate reports could be filed with the 
public health agency to ensure compliance with the standards.
    Response. The commenter's point is unclear, as is its proposal. We 
therefore reiterate that Certified EHR Technology must be capable of 
transmitting health information in accordance with the standards 
adopted by the Secretary, regardless of whether a specific public 
health agency can accept or receive the information.
    Comment. One commenter suggested that if current interfaces comply 
with public health surveillance data using older versions of HL7, the 
organizations should be allowed to keep these versions and not be 
required to upgrade to a newer version.
    Response. We permit a Complete EHR or EHR Module to be tested and 
certified to either HL7 2.3.1 or HL7 2.5.1. No other versions will be 
considered compliant with the adopted standards or certification 
criterion.
    Comment. One commenter recommended that we specify acceptable 
testing methods. The commenter also recommended that the testing 
methods should include an evaluation of HL7 conformance, completeness, 
and accuracy of test messages sent to a state public health agency with 
a demonstrated capability for electronic laboratory reporting.
    Response. We do not specify the testing methods applicable to the 
certification criterion, because that information is outside the scope 
of this final rule.
    Comment. One commenter suggested that adverse events be reported to 
public health agencies.
    Response. Our certification criterion does not preclude other types 
of reportable events from occurring. Presently, we do not believe that 
it is appropriate to modify the certification criterion to explicitly 
refer to adverse events.
    Comment. One commenter recommended that because some public health 
agencies do not have the ability to receive public health surveillance 
information in electronic format, we should clarify that this 
certification criterion is limited to verifying the ability of the 
system to record, modify, retrieve, and submit such information based 
on at least one test of these capabilities.
    Response. We reiterate, that the purpose of certification is to 
verify that a Complete EHR or EHR Module can perform these 
capabilities. That should not be construed to mean that an eligible 
professional or eligible hospital is exempt from using Certified EHR 
Technology to meet the meaningful use objective and measure.
    Comment. A commenter recommended including the word ``modify'' in 
the certification criterion.
    Response. Consistent with our rationale above, we have added the 
word modify to the certification criterion.
Section 170.302(o)--Access Control

[[Page 44617]]



------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Protect electronic health       Conduct or review  Interim Final Rule
 information created or          a security risk    Text:
 maintained by the certified     analysis per 45   Access control.
 EHR technology through the      CFR 164.308        Assign a unique name
 implementation of appropriate   (a)(1) and         and/or number for
 technical capabilities.         implement          identifying and
                                 security updates   tracking user
                                 as necessary and   identity and
                                 correct            establish controls
                                 identified         that permit only
                                 security           authorized users to
                                 deficiencies as    access electronic
                                 part of its risk   health information.
                                 management        Final Rule Text: Sec.
                                 process.             170.302(o).
                                                   Unchanged.
------------------------------------------------------------------------

    Comment. One commenter explicitly noted its support for this 
certification criterion. We received other comments that included some 
mention of ``access'' but did not expressly focus on the certification 
criterion or provide any related suggestions or recommendations.
    Response. We appreciate the comment supporting this certification 
criterion. This certification criterion remains unchanged from the 
certification criterion adopted in the Interim Final Rule.
Section 170.302(p)--Emergency Access

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Protect electronic health       Conduct or review  Interim Final Rule
 information created or          a security risk    Text:
 maintained by the certified     analysis per 45   Emergency access.
 EHR technology through the      CFR 164.308        Permit authorized
 implementation of appropriate   (a)(1) and         users (who are
 technical capabilities.         implement          authorized for
                                 security updates   emergency
                                 as necessary and   situations) to
                                 correct            access electronic
                                 identified         health information
                                 security           during an emergency.
                                 deficiencies as   Final Rule Text: Sec.
                                 part of its risk     170.302(p).
                                 management        Unchanged.
                                 process.
------------------------------------------------------------------------

    Comment. One commenter asked that we clarify the circumstances that 
would qualify as an ``emergency'' and further clarify whether 
compliance with this certification criterion is intended to pre-empt 
conflicting or stricter state laws that may limit this type of access 
or require patient consent. Further, the commenter questioned whether 
we were implying that some authorized users of Certified EHR Technology 
would not be authorized for emergency situations or whether we intended 
for any authorized user to be entitled to access in an emergency 
situation. Finally, another commenter requested clarification as to 
whether emergency access is driven by organizational policies and 
whether capturing such access in an audit log is appropriate.
    Response. We have adopted certification criteria to ensure that 
Certified EHR Technology includes certain capabilities, in this case 
that Certified EHR Technology be capable of permitting authorized users 
to access electronic health information during an emergency. The 
criterion is not intended to specify what constitutes an emergency or 
who would be authorized to access electronic health information in an 
emergency. In a medical emergency, those determinations would be made 
under specific factual circumstances and in accordance with applicable 
state and federal laws, organizational policies and procedures, and the 
relevant standard of care.
    With respect to emergency access, we note that HHS stated in the 
HIPAA Security Final Rule (68 FR 8355):

    We believe that emergency access is a necessary part of access 
controls and, therefore, is properly a required implementation 
specification of the ``Access controls'' standard. Access controls 
will still be necessary under emergency conditions, although they 
may be very different from those used in normal operational 
circumstances. For example, in a situation when normal environmental 
systems, including electrical power, have been severely damaged or 
rendered inoperative due to a natural or manmade disaster, 
procedures should be established beforehand to provide guidance on 
possible ways to gain access to needed electronic protected health 
information.

We believe that this certification criterion is consistent with the 
HIPAA Security Rule.
    Some commenters appeared to interpret our reference to 
``emergency'' in ``emergency access'' as solely constituting a clinical 
or life threatening emergency related to a patient for which access 
would be required. We believe that emergency could encompass that 
scenario, as well as a broader range of possibilities, including normal 
patient care when timely access to electronic health information 
becomes critical. Therefore, we have not sought to limit the 
development of emergency access capabilities for Certified EHR 
Technology to a particular scenario.
    Comment. One commenter suggested that we require automated 
notification of user activity to system administrators when emergency 
access is invoked.
    Response. We appreciate this suggestion. However, at the present 
time, we do not believe that this requirement should be a condition of 
certification because a person or entity's organizational policies and 
procedures may ensure timely notification of appropriate personnel.
Section 170.302(q)--Automatic Log-Off

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Protect electronic health       Conduct or review  Interim Final Rule
 information created or          a security risk    Text:
 maintained by the certified     analysis per 45   Automatic log-off.
 EHR technology through the      CFR 164.308        Terminate an
 implementation of appropriate   (a)(1) and         electronic session
 technical capabilities.         implement          after a
                                 security updates   predetermined time
                                 as necessary and   of inactivity.
                                 correct           Final Rule Text: Sec.
                                 identified           170.302(q).
                                 security          Unchanged.
                                 deficiencies as
                                 part of its risk
                                 management
                                 process.
------------------------------------------------------------------------


[[Page 44618]]

    Comments. One commenter supported this requirement. Another 
commenter concurred with the purpose of the certification criterion, 
but noted that it may be difficult in some circumstances for eligible 
professionals or eligible hospitals to implement this capability if the 
Certified EHR Technology is offered as a service and multiple 
individuals are using the Certified EHR Technology at the same time.
    Response. We appreciate the commenters' support for the adoption of 
this certification criterion. We believe that automatic logoff 
capabilities are commonplace and that this certification criterion can 
be met by any Complete EHR or EHR Module developer. We are aware that 
many Web services today logoff customers after a period of inactivity 
and do not believe this requirement is unduly burdensome for any 
Complete EHR or EHR Module developer.
Section 170.302(r)--Audit Log

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Protect electronic health       Conduct or review  Interim Final Rule
 information created or          a security risk    Text:
 maintained by the certified     analysis per 45   (1) Record actions.
 EHR technology through the      CFR 164.308        Record actions
 implementation of appropriate   (a)(1) and         related to
 technical capabilities.         implement          electronic health
                                 security updates   information in
                                 as necessary and   accordance with the
                                 correct            standard specified
                                 identified         in Sec.
                                 security           170.210(b).
                                 deficiencies as   (2) Alerts. Provide
                                 part of its risk   alerts based on user-
                                 management         defined events.
                                 process.          (3) Display and
                                                    print.
                                                    Electronically
                                                    display and print
                                                    all or a specified
                                                    set of recorded
                                                    information upon
                                                    request or at a set
                                                    period of time.
                                                   Final Rule Text: Sec.
                                                      170.302(r).
                                                   (1) Record actions.
                                                    Record actions
                                                    related to
                                                    electronic health
                                                    information in
                                                    accordance with the
                                                    standard specified
                                                    in Sec.
                                                    170.210(b).
                                                      (2) Generate audit
                                                       log. Enable a
                                                       user to generate
                                                       an audit log for
                                                       a specific time
                                                       period and to
                                                       sort entries in
                                                       the audit log
                                                       according to any
                                                       of the elements
                                                       specified in the
                                                       standard at
                                                       170.210(b).
------------------------------------------------------------------------

    Comments. Several commenters recommended that we add to the 
standard specified at Sec.  170.210(b) ``access,'' ``reading,'' or 
``viewing'' as triggers for when actions needed to be recorded as part 
of an audit log. One commenter recommended expanding the audit content 
to include maintaining the before-access content of the information 
accessed as well as the after-access content. Some commenters requested 
clarification of the intended meaning of the reference to recording the 
action of ``printing.'' Commenters recommended expanding or replacing 
``print'' in the standard with other types of output methods such as 
extraction, copy, exchange, report, and export. Some commenter stated 
that the print function in many operating systems and software products 
is a multiple step process that is difficult for any system to audit. 
Other commenters expressed concerns that the requirement to audit all 
printing would be difficult because there were numerous ways to 
circumvent the specific action of printing, such as using the print 
screen function and printing out the image of the screen shot. One 
commenter stated that auditing of the print function would be possible, 
but complete auditing of all possible ways of printing would be 
impracticable.
    Response. We appreciate the thoughtfulness and thoroughness of the 
comments provided on this standard. We agree with commenters that 
auditing the action of printing, as it was originally envisioned, could 
be circumvented in such ways as to make the burden of trying to 
accurately audit such occurrences outweigh the benefit. Accordingly, we 
have removed ``printed'' from the standard. We also agree with 
commenters that our omission of ``access'' should be corrected and we 
have added ``accessed'' to the standard. We view the action of 
``access'' to encompass ``reading'' or ``viewing'' and consequently 
have not included those terms as well. Finally, we believe that the 
action of ``accessed'' is a superset of actions which may include 
``export'' and for that reason have not included, per some commenters' 
suggestions, the word ``exported'' in the standard. Additionally, to 
provide greater clarity, we have added in ``and by whom'' toward the 
end of the standard in order to more clearly specify that the actions 
recorded should be associated with the user identification that is 
recorded.
    The final standard will read as follows: ``The date, time, patient 
identification, and user identification must be recorded when 
electronic health information is created, modified, accessed, or 
deleted; and an indication of which action(s) occurred and by whom must 
also be recorded.''
    Comments. Some commenters requested that we clarify the term ``user 
identification'' in the standard specified at Sec.  170.210(b) and 
recommended the use of existing standards-based definitions, such as 
HL7's definition of author which includes person, organization, or 
device.
    Response. We specified in the standard that the date, time, patient 
identification, and user identification must be recorded when certain 
actions take place. The HL7's definition of author is consistent with 
our expectation. While we believe that in most cases a user will be a 
health care professional performing an action using Certified EHR 
Technology, it is also possible that a device or another software 
process or program could perform any one of these actions. We do not 
intend to preclude Complete EHR and EHR Module developers from 
including these and other types of specific features.
    Comment. One commenter stated that the audit alert criterion 
exceeds reasonable expectations for Certified EHR Technology to provide 
automatic alerts, and recommended that the audit criteria focus on 
record access rather than electronic alerts. Several commenters 
suggested that alerts are not well defined and should be removed from 
the criteria. Several commenters expressed concern that the audit 
alerting criterion goes beyond what is required by HITECH and HIPAA and 
exceeds the current capabilities of products in the market, and 
recommends that the alerting criterion be eliminated from the final 
rule. Some commenters recommended against the adoption of certification 
criterion that requires EHR systems to create an unlimited and open-
ended series of rules to produce user-defined alerts, and suggested 
that we should clearly define

[[Page 44619]]

which actions should be recorded and what alerts should be defined and 
provided in an audit log. Several commenters stated that the use of the 
phrase ``based on user-defined events'' in the criterion could be 
easily misinterpreted or misunderstood to extend beyond ``entity-
defined'' events to include individual patient preferences. Some of the 
commenters that expressed concerns also contended that it would be 
difficult to test and certify this portion of the certification 
criterion.
    Response. Again, we appreciate the thoroughness of the commenters' 
suggestions. With respect to alerts based on user-defined events, we 
had intended for Complete EHRs or EHR Modules designed to provide this 
capability to be capable of being configured by a specific user of 
Certified EHR Technology or based on organizational policy to generate 
alerts when certain actions (defined in the standard) had taken place. 
For example, a user-defined event could be when a patient's health 
information is accessed outside of normal business hours. In this case, 
it was our expectation that Certified EHR Technology would alert a 
specific user of the Certified EHR Technology or the organization's 
information security staff. We understand the point that commenters 
raise, however, about the potential for misinterpretation of this 
certification criterion and the consequent potential burden.
    Our overall intent for the third paragraph of this certification 
criterion was to ensure that Certified EHR Technology provided the 
capability for eligible professionals and eligible hospitals to gain 
access to a specified portion, or a complete representation, of the 
Certified EHR Technology's audit log. We believe that this capability 
is essential for eligible professionals and eligible hospitals for risk 
analysis and other purposes. Therefore, in concert with the feedback 
commenters provided on the second paragraph, we analyzed whether 
combining the third paragraph with the second paragraph into a single 
paragraph would express a clearer requirement. Accordingly, we have 
merged the two paragraphs and have adopted in the final rule a 
requirement that we believe more clearly expresses our intent for this 
certification criterion. We also note for clarification that the phrase 
``any of the elements specified by 170.210(b)'' would also include, for 
example, ``date'' or that information has been ``deleted.''
    Finally, we believe that it is important for our privacy and 
security certification criteria to remain consistent with the HIPAA 
Security Rule to the degree that Certified EHR Technology includes 
technical capabilities that are associated with assisting HIPAA covered 
entities comply with applicable legal requirements. We disagree, 
however, with those commenters who stated that we did not have a 
sufficient legal basis to adopt this certification criterion the way we 
did because it went beyond the HIPAA Security Rule. What a HIPAA 
covered entity must do to remain in compliance with the HIPAA Security 
Rule is separate and distinct from the capabilities that a Complete EHR 
or EHR Module must include in order to be certified. We do not believe 
that we are precluded by the HITECH Act from adopting certification 
criteria that go beyond the requirements specified by the HIPAA 
Security Rule. We believe that the HITECH Act, while directing that 
standards, implementation specifications, and certification criteria be 
consistent with the HIPAA standards, authorizes the Secretary to adopt 
certification criteria more broadly for the electronic use and exchange 
of health information. Section 3004(b)(1) of the PHSA, as added by the 
HITECH Act, requires the Secretary, for instance, to adopt an initial 
set of standards, implementation specifications, and certification 
criteria to enhance the interoperability, functionality, utility, and 
security of health information technology.
    With respect to the concern expressed that this certification 
criterion requires capabilities that exceed the current capabilities of 
products in the market, we disagree. Based on our understanding of the 
current EHR technology in the market, we believe that the capabilities 
we have specified in the criterion and the embedded standard are 
already common industry practice, and further, that the industry has 
expanded the functionality available in audit logs.
    Comment. One commenter suggested we defer our adoption of the 
standard until the next rulemaking related to meaningful use.
    Response. We disagree. As stated above, we believe that audit log 
capabilities are an essential component of Certified EHR Technology. As 
we mentioned above, we believe that the actions we have specified in 
the standard, in response to public comment, are already common 
industry practice. Moreover, audit logs will provide valuable 
information to eligible professionals and eligible hospitals in the 
event of a security incident.
    Comments. Several commenters acknowledged the importance of the 
audit log, but emphasized that the audit log requirements should 
address the availability of the audit log and its security. Several 
commenters recommended that additional requirements be added, including 
that the audit log always be on during normal production for the 
minimum elements specified in 170.210(b), be maintained in a secure 
manner, be produced in a human readable format, and be retained in 
conjunction with the retention period of the record.
    Response. We agree with these commenters on the merits of their 
suggestions. In particular, we note that audit logs provide an 
important resource for eligible professionals and eligible hospitals. 
Audit logs can assist in the identification of security incidents, such 
as unauthorized access, as well as serve to deter users from conducting 
fraudulent or abusive activities and detect such activities. The 
purpose of adopted certification criteria is to specify the 
capabilities Complete EHRs and EHR Modules must include in order to be 
certified, not when such capabilities must be used. Accordingly, we do 
not believe that it would be appropriate to specify in this 
certification criterion the time period for which an audit log should 
be ``on.'' We agree with commenters that audit logs should be 
maintained in a secure manner. For this reason, we have preserved the 
capability we adopted in the Interim Final Rule as part of the 
integrity certification criterion that specified that Certified EHR 
Technology must be capable of detecting alterations to audit logs. We 
encourage the HIT Standards Committee to consider additional 
capabilities that could be specified related to audit logs.
    Comment. One commenter recommended that the IHE Audit Trail and 
Node Authentication (ATNA) Integration Profile be used, but that its 
use be constrained to the electronic transactions among organizations, 
rather than electronic transmissions within an organization.
    Response. We decided to defer our adoption of the ATNA standard 
because it can be configured in multiple ways and we did not believe 
that it would be appropriate at this time to require a specific 
implementation as a condition of certification. Our deferral does not 
preclude Complete EHR and EHR Module developers from using the 
standard, however.
    Comment. One commenter requested clarification between ``read'' 
audits and ``write'' audits, and how each is to be used. The commenter 
suggested that not requiring the capability of ``read'' audits will 
significantly reduce the ability of auditors to identify and 
investigate

[[Page 44620]]

inappropriate use of health information when records are accessed but 
not manipulated. The commenter noted that auditing all read operations 
for all data elements within an EHR is infeasible. The commenter 
further suggested that ``read'' operations should be audited only when 
certain demographic health information needed to identify a patient 
(e.g., name, record number, date of birth, address) is presented to or 
can be known by the user.
    Response. As discussed above, we have adopted in the standard the 
action of ``accessed'' which would encompass the action of ``read.'' At 
the present time, we only identify certain data elements in the adopted 
standard that must be recorded and believe that this specificity will 
help reduce any potential burden associated with recording the action 
of ``accessed.''
Section 170.302(s)--Integrity

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Protect electronic health       Conduct or review  Interim Final Rule
 information created or          a security risk    Text:
 maintained by the certified     analysis per 45   (1) In transit.
 EHR technology through the      CFR 164.308        Verify that
 implementation of appropriate   (a)(1) and         electronic health
 technical capabilities.         implement          information has not
                                 security updates   been altered in
                                 as necessary and   transit in
                                 correct            accordance with the
                                 identified         standard specified
                                 security           in Sec.
                                 deficiencies as    170.210(c).
                                 part of its risk  (2) Detection. Detect
                                 management         the alteration and
                                 process.           deletion of
                                                    electronic health
                                                    information and
                                                    audit logs, in
                                                    accordance with the
                                                    standard specified
                                                    in Sec.
                                                    170.210(c).
                                                   Final Rule Text: Sec.
                                                      170.302(s).
                                                   (1) Create a message
                                                    digest in accordance
                                                    with the standard
                                                    specified in
                                                    170.210(c).
                                                   (2) Verify in
                                                    accordance with the
                                                    standard specified
                                                    in 170.210(c) upon
                                                    receipt of
                                                    electronically
                                                    exchanged health
                                                    information that
                                                    such information has
                                                    not been altered.
                                                      (3) Detection.
                                                       Detect the
                                                       alteration of
                                                       audit logs.
------------------------------------------------------------------------

    Comments. Several commenters requested a definition of ``in 
transit.'' Other commenters suggested that hashing of messages in 
transit be limited to circumstances of transmission over public 
networks only. These commenters suggested that messages transmitted 
over private networks be exempt from complying with this standard. One 
commenter suggested that in addition to message hashing, digital 
signatures should be required on messages in transit. Another commenter 
stated that requiring hashing of messages in transit is overly 
burdensome. One commenter requested that we clarify whether we intended 
Sec.  170.302(s)(1) to require that the receiver of a message always 
verify messages received rather than simply demonstrate the capability 
to use hashing.
    Response. We intend for this certification criterion to support, at 
a minimum, the HIPAA Security Rule implementation specification 
provided at 45 CFR 164.312(e)(2)(i) ``[i]mplement security measures to 
ensure that electronically transmitted electronic protected health 
information is not improperly modified without detection until disposed 
of.'' Because this certification criterion specifies a capability that 
Certified EHR Technology must include, we do not believe that it is 
necessary or appropriate for us to address whether hashing is 
applicable to public and private networks. Additionally, we clarify 
that Certified EHR Technology must include the capability to check the 
integrity of health information that has been received through 
electronic exchange. However, similar to our approach to many adopted 
certification criteria, we do not specify the instances in which this 
capability needs to be executed. Nevertheless, in response to public 
comments we have attempted to clarify this certification criterion. We 
clarify that we expect Certified EHR Technology to be capable of 
creating a message digest and when in receipt of a message digest, to 
use the message digest to verify that the contents of the message have 
not been altered. We have revised the certification criterion to 
clarify our intent.
    Additionally, based on these revisions in the certification 
criterion, we wish to clarify the wording of the integrity standard 
specified at 170.210(c). The standard currently includes the words ``or 
higher'' at the end of the standard. To provide more certainty to the 
industry of our intended meaning, we are replacing those words with 
more accurate terminology. We have modified the standard to read as 
follows: ``A hashing algorithm with a security strength equal to or 
greater than SHA-1 must be used to verify that electronic health 
information has not been altered.'' More information on SHA-1 and other 
secure hash algorithms can be found in FIPS 180-3 \5\ while more 
information on the security strength of certain hashing algorithms can 
be found in NIST Special Publication 800-107.\6\
---------------------------------------------------------------------------

    \5\ http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_
final.pdf.
    \6\ http://csrc.nist.gov/publications/nistpubs/800-107/NIST-SP-
800-107.pdf.
---------------------------------------------------------------------------

    Comments. Some commenters noted that Sec.  170.302(s)(2) refers to 
the use of the adopted standard which specifies the use of hashing to 
detect audit log alteration or deletion and that such a requirement is 
inappropriate. Other commenters recommended that hashing should not, at 
the present time, be used for detecting alterations to data at rest.
    Response. We have considered these comments and agree with these 
commenters that this requirement requires further clarification. We 
note that part of this requirement as adopted in the Interim Final Rule 
(``detect * * * deletion of electronic health information'') is 
redundant with the standard we specify for audit logs which requires 
that deletions of electronic health information be recorded. For this 
reason, we have removed the reference to the detection of deleted 
electronic health information and have opted for a more concise 
requirement that alterations to audit logs be detected. In response to 
public comment, we have chosen not to specify a standard for detecting 
alterations to audit logs at this time.
    Comment. One commenter requested clarification as to how message 
hashing should work when messages are part of a multi-part transmission 
process, e.g., through switches, clearinghouses, and other brokers.
    Response. We expect Certified EHR Technology to be capable of 
generating a hash of electronic health information and upon receipt of 
such information, verifying that it has not been altered when it has 
been electronically exchanged. We recognize that certain situations may 
not be conducive to the

[[Page 44621]]

use of hashes, which is why, as we noted above, we do not specify the 
instances in which hashing must be used, just that Certified EHR 
Technology include these capabilities.
    Comment. One commenter stated that secure transmission requirements 
are ``inappropriate'' because they do not support any meaningful use 
requirements.
    Response. We disagree. Meaningful use requires the electronic 
exchange of health information and the protection of such information. 
We believe that the only practical and effective way that electronic 
health information can be exchanged in a meaningful manner is if the 
integrity of the information can be maintained. Information 
``integrity'' is also one of the three pillars of securing or 
``protecting'' electronic information.
Section 170.302(t)--Authentication

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Protect electronic health       Conduct or review  Interim Final Rule
 information created or          a security risk    Text:
 maintained by the certified     analysis per 45   (1) Local. Verify
 EHR technology through the      CFR 164.308        that a person or
 implementation of appropriate   (a)(1) and         entity seeking
 technical capabilities.         implement          access to electronic
                                 security updates   health information
                                 as necessary and   is the one claimed
                                 correct            and is authorized to
                                 identified         access such
                                 security           information.
                                 deficiencies as   (2) Cross network.
                                 part of its risk   Verify that a person
                                 management         or entity seeking
                                 process.           access to electronic
                                                    health information
                                                    across a network is
                                                    the one claimed and
                                                    is authorized to
                                                    access such
                                                    information in
                                                    accordance with the
                                                    standard specified
                                                    in Sec.
                                                    170.210(d).
                                                   Final Rule Text: Sec.
                                                      170.302(t).
                                                   Authentication.
                                                    Verify that a person
                                                    or entity seeking
                                                    access to electronic
                                                    health information
                                                    is the one claimed
                                                    and is authorized to
                                                    access such
                                                    information.
------------------------------------------------------------------------

    Comments. One commenter expressly supported this certification 
criterion. A majority of commenters expressed concerns related to Sec.  
170.302(t) and the cross-enterprise authentication standard specified 
at Sec.  170.210(d). Some commenters misinterpreted our example and 
stated that Security Assertion Markup Language (SAML) should not be 
required or be a named standard. One commenter suggested expanding the 
set of examples we provided. Other commenters requested that the 
standard and the related portion of the certification criterion be 
removed because it was too burdensome to implement at the present time, 
was overly broad, and could be subject to multiple interpretations. 
Other commenters contended that there is an insufficient infrastructure 
to support cross-enterprise authentication. One commenter stated that 
cross-enterprise authentication would not reside in an EHR application, 
but rather in the network infrastructure.
    Response. We have considered the concerns issued by commenters and 
agree that the burden associated with cross enterprise authentication 
is unnecessarily high and cross-network authentication should not be a 
condition of certification at the present time. As a result, we have 
removed this specific part of the certification criterion and the 
associated standard.
    Comment. A commenter requested clarification as to whether ``user 
name and password'' would be sufficient to authorize a user or whether 
biometrics would be required.
    Response. We do not believe that it is appropriate to specify, as a 
condition of certification, the types of factors that users could 
utilize to authenticate themselves.
Section 170.302(u)--Encryption

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Protect electronic health       Conduct or review  Interim Final Rule
 information created or          a security risk    Text:
 maintained by the certified     analysis per 45   (1) General. Encrypt
 EHR technology through the      CFR 164.308        and decrypt
 implementation of appropriate   (a)(1) and         electronic health
 technical capabilities.         implement          information
                                 security updates   according to user-
                                 as necessary and   defined preferences
                                 correct            in accordance with
                                 identified         the standard
                                 security           specified in Sec.
                                 deficiencies as    170.210(a)(1).
                                 part of its risk  (2) Exchange. Encrypt
                                 management         and decrypt
                                 process.           electronic health
                                                    information when
                                                    exchanged in
                                                    accordance with the
                                                    standard specified
                                                    in Sec.
                                                    170.210(a)(2).
                                                   Final Rule Text: Sec.
                                                      170.302(u).
                                                   General encryption.
                                                    Encrypt and decrypt
                                                    electronic health
                                                    information in
                                                    accordance with the
                                                    standard specified
                                                    in Sec.
                                                    170.210(a)(1),
                                                    unless the Secretary
                                                    determines that the
                                                    use of such
                                                    algorithm would pose
                                                    a significant
                                                    security risk for
                                                    Certified EHR
                                                    Technology.
                                                   Sec.   170.302(v).
                                                      Encryption when
                                                       exchanging
                                                       electronic health
                                                       information.
                                                       Encrypt and
                                                       decrypt
                                                       electronic health
                                                       information when
                                                       exchanged in
                                                       accordance with
                                                       the standard
                                                       specified in Sec.
                                                         170.210(a)(2).
------------------------------------------------------------------------

    Comments. A number of commenters stated that transmissions of 
health information over leased or private network lines should not be 
subject to the encryption of data in transit requirement.
    Response. Certified EHR Technology must include the capability to 
encrypt and decrypt information regardless of the transmission method 
used. This certification criterion and related standard do not specify 
the circumstances under which encryption and decryption must be 
performed; they simply require the capability. If an eligible 
professional or eligible hospital determines that encryption is an 
appropriate and necessary safeguard, we believe that Certified EHR 
Technology should provide the capability to

[[Page 44622]]

implement encryption. Overall, we want to ensure that Certified EHR 
Technology is capable of assisting eligible professionals and eligible 
hospitals to implement more secure technical solutions if they 
determine, based on their risk analysis, that technical safeguards such 
as encryption are reasonable and appropriate, or required.
    Comment. One commenter requested further clarification of the 
phrase ``encrypted and integrity protected link.'' Several commenters 
recommended that Transport Layer Security (TLS) ought to be 
specifically named as a required protocol. Other commenters also 
expressed concern that unless TLS is explicitly named, all example 
protocols would be required to be supported.
    Response. The example list of protocols that would meet the 
certification criterion is not intended to be exhaustive or suggest 
that Complete EHRs or EHR Modules must be capable of using all of the 
listed protocols to be certified. The example list of protocols in the 
Interim Final Rule was included solely for illustrative purposes. We 
have, however, consistent with the way we have restructured the 
regulatory text for some standards (to better associate them with the 
adopted certification criterion that reference them), modified this 
standard to simply express that the standard is any encrypted and 
integrity protected link.
    Comments. Several commenters suggested replacing the functional 
description of the encryption standard with a specific reference to 
FIPS 140-2. These commenters also noted that HHS had included such a 
reference in an update to its guidance specifying the technologies and 
methodologies that render protected health information unusable, 
unreadable, or indecipherable that was included in the Breach 
Notification for Unsecured Protected Health Information Interim Final 
Rule, published on August 24, 2009 (74 FR 42740), and further, 
requested that we make our standard consistent with this guidance. Some 
commenters explicitly recommended that AES be specified as the 
encryption algorithm standard.
    Response. We have considered these commenters' points and have 
decided to revise our adopted standard to be more flexible regarding 
the encryption algorithms we permit EHR Technology to implement to be 
certified. We have also sought to clarify how our adopted standard 
relates to the guidance included in the breach notification interim 
final rule. We have revised the general encryption standard to read as 
follows: ``Any encryption algorithm identified by the National 
Institute of Standards and Technology (NIST) as an approved security 
function in Annex A of the Federal Information Processing Standards 
(FIPS) Publication 140-2.''
    The National Institute of Standards and Technology (NIST) published 
Federal Information Processing Standards (FIPS) Publication 140-2 to 
specify the security requirements for cryptographic modules. As part of 
FIPS 140-X conformance, NIST publishes ``annexes'' of different 
``approved'' security protocols. For purposes of encryption, NIST 
maintains ``Annex A'' which identifies ``approved security functions.'' 
Annex A identifies both symmetric and asymmetric key encryption 
algorithms that NIST has identified for use in accordance with FIPS 
140-2. In response to commenters' concerns, we believe that leveraging 
NIST's work in this area provides for a clearer requirement for 
compliance and provides Complete EHR and EHR Module developers with the 
ability to use one or more secure encryption algorithms for the 
purposes of demonstrating compliance with this certification criterion. 
We believe this flexibility will benefit eligible professionals and 
eligible hospitals because they may be able to leverage a broader suite 
of secure encryption algorithms. As noted in Special Publication 800-
111, which is specified in the guidance included in the breach 
notification interim final rule for the encryption of data at rest, 
``[w]henever possible, AES should be used for the encryption algorithm 
because of its strength and speed.''
    We point out that the adopted certification criterion identifies 
certain discretionary authority that the Secretary is retaining with 
respect to acceptable encryption algorithms. We have adopted the list 
of approved encryption algorithms that NIST has identified and 
referenced in FIPS 140-2 Annex A, which is being incorporated by 
reference. While the list is intended to be current, we anticipate that 
NIST will on an as-needed basis revise and update the list, based on 
the development of new technologies or perhaps on identified 
vulnerabilities associated with a particular algorithm. Regardless of 
any revisions to this list by NIST, this version of Annex A that is 
incorporated by reference will remain effective for purposes of serving 
as the adopted encryption standard. With that said, if the Secretary 
determines that one of the listed encryption algorithms poses a 
significant security risk for Certified EHR Technology, the Secretary 
will notify the public on the Department's Web site (and perhaps with 
some time delay in the Federal Register), and will direct ONC-ATCBs or 
ONC-ACBs not to test and certify Complete EHRs and EHR Modules 
according to the specified compromised algorithm. The Department would 
then follow-up with rulemaking as necessary and appropriate to update 
the adopted list of acceptable encryption algorithms.
    Comments. Many commenters expressed concerns that the rule would 
require the encryption of data at rest. One commenter recommended that 
encryption not be a required functionality of EHR systems, but defined 
as limited to devices. Some commenters stated that requiring EHR 
systems to be capable of encryption would hinder adoption.
    Response. We require that Certified EHR Technology must be capable 
of encrypting electronic health information. We do not specify the 
policies surrounding the use of encryption by an eligible professional 
or eligible hospital nor do we specify that it should only apply to 
devices. Rather we intend for Certified EHR Technology to be 
technologically capable of encryption, thereby allowing, if desired or 
required, an eligible professional or eligible hospital who adopts 
Certified EHR Technology to use this capability. We disagree that 
requiring Certified EHR Technology be capable of encryption would 
hinder adoption. To the contrary, we believe that Certified EHR 
Technology capable of encrypting electronic health information will be 
desired, especially in light of the new breach notification 
requirements established by the HITECH Act and the Breach Notification 
for Unsecured Protected Health Information Interim Final Rule. We also 
take this opportunity to make a technical correction to this 
certification criterion. We inadvertently combined both encryption 
capabilities under the same paragraph and per our reaffirmed 
interpretation expressed in the Temporary Certification Program, we 
believe that the scope of one certification criterion starts at the 
first paragraph level and includes all subparagraphs. As a result, we 
view these as two distinct capabilities and have created a separate 
certification criterion for each.
    Comments. One commenter stated that the security requirements, 
particularly for encryption, are lower than the security standards it 
already meets. This commenter consequently believes that our adoption 
of this standard would require it to reduce the security of its 
products. Another commenter stated that encryption technology should 
not be integrated into an EHR product, but should instead be 
implemented through other means as

[[Page 44623]]

part of the system on which an EHR may be installed.
    Response. We believe that Certified EHR Technology must be capable 
of performing encryption. Because of the flexibility in the adopted 
standard, however, how encryption is technically implemented is up to 
the Complete EHR or EHR Module developer to determine within the 
parameters of Annex A of FIPS 140-2. Given the changes we have made to 
the general encryption standard, we believe that the full range of the 
most secure encryption algorithms are available for Complete EHR and 
EHR Module developers to implement.
    Comments. A few commenters stated that the term ``user-defined 
preferences'' in the certification criteria was too vague and allowed 
too much latitude for divergent interpretations of the requirement. 
Other commenters noted that users do not always get to define such 
preferences as they would conflict with overarching organizational 
policies.
    Response. We intended the phrase, ``according to user-defined 
preferences'' in the Interim Final Rule, to mean that users would have 
the ability to elect when they wanted encryption to occur, for example, 
at log-off. We recognize that organizational policies, software as 
service models and other architectures in which Certified EHR 
Technology may be implemented, could lead to encryption being 
instituted in significantly different ways and, as a result, we have 
removed the reference to ``user-defined preferences.''
Section 170.302(v)--Accounting of Disclosures

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Protect electronic health       Conduct or review  Interim Final Rule
 information created or          a security risk    Text:
 maintained by the certified     analysis per 45   Record disclosures
 EHR technology through the      CFR 164.308        made for treatment,
 implementation of appropriate   (a)(1) and         payment, and health
 technical capabilities.         implement          care operations in
                                 security updates   accordance with the
                                 as necessary and   standard specified
                                 correct            in Sec.
                                 identified         170.210(e).
                                 security          Final Rule Text: Sec.
                                 deficiencies as      170.302(w).
                                 part of its risk  Certification
                                 management         criterion made
                                 process.           optional, while the
                                                    text of this
                                                    certification
                                                    criterion remains
                                                    unchanged.
------------------------------------------------------------------------

    Comments. Many commenters asserted that the certification criterion 
and accompanying standard for accounting of disclosures for treatment, 
payment, and health care operations (as these terms are defined at 45 
CFR 164.501) would be a resource intensive process and too 
administratively, technically, and financially burdensome. A large 
portion of commenters further conveyed specific challenges including: 
The ability to differentiate between a ``use'' and a ``disclosure'' (as 
these terms are defined at 45 CFR 160.103); storing three years worth 
of disclosures, which many noted could be voluminous; that health care 
providers, especially hospitals, have decentralized systems, which 
today are manually accessed to create an accounting of disclosures; the 
development time for such a capability would take more time than is 
available before the meaningful use Stage 1 effective date; that it 
would be difficult to account for these types of disclosures in real-
time without a code set for disclosures; that this requirement could 
affect workflow; and the scope of electronic exchanges that the term 
``disclosure'' would encompass is unclear. A majority of commenters 
also echoed that the Secretary should use discretion provided by the 
HITECH Act to delay the compliance date for accounting of disclosures 
for treatment, payment, and health care operations. Commenters 
supported this suggestion by pointing out that the Secretary has not 
yet formally established the policies for accounting of disclosures. 
They explained that the HITECH Act requires the Secretary to promulgate 
a rule no later than six months after the Secretary has adopted a 
standard for accounting of disclosures, which has not yet occurred. 
Many of these commenters suggested that the certification criterion and 
standard should be removed or their adoption delayed until after the 
technical specifications for accounting of disclosures can be 
harmonized with the Secretary's forthcoming promulgation of a 
regulation on this issue. Other commenters noted that the HIT Policy 
Committee included accounting of disclosures in its suggestions as a 
meaningful use Stage 3 objective. In response to the questions we 
posed, several commenters noted that to whom the disclosure was made 
(recipient) should be an important element included in an accounting of 
disclosures. One commenter noted that the standard should be the same 
as what is currently applicable to disclosures that are not for 
treatment, payment, and health care operations and cited the 
requirements at 45 CFR 164.528(b)(2). Other commenters stated that the 
adopted certification criterion should be an audit log.
    Response. We appreciate the thoroughness, specificity, and detail 
provided by many of those who commented on this certification 
criterion. We recognize that significant technical and policy 
challenges remain unresolved. Accordingly, we do not believe that the 
capability to account for disclosures should be a condition of 
certification at the present time. As discussed in the beginning of the 
preamble of this final rule, we have decided to make this certification 
criterion ``optional'' instead of removing it. Additionally, the 
standard will remain unchanged as currently worded and as applicable to 
the certification criterion to provide guidance to Complete EHR and EHR 
Module developers that choose to adopt this capability at this time. As 
an optional certification criterion, though, Complete EHR or EHR Module 
will not be required to possess the capability for certification. As we 
stated previously in the Interim Final Rule, we plan to work 
collaboratively with the Office for Civil Rights (OCR) as it develops 
the regulatory policy related to this requirement. We anticipate 
updating this certification criterion and the related standard in a 
future rulemaking to reflect OCR's final policies regarding accounting 
of disclosures.
    Comment. Several commenters requested that we clarify what is meant 
by a ``description of the disclosure.'' Some commenters noted that it 
would not be possible to include these descriptions in an accounting 
without code sets for the various types of disclosures. These 
commenters also indicated that this requirement could have serious 
workflow implications unless it can be fully automated.
    Response. We recognize the technological challenges associated with 
effectively and efficiently addressing this aspect of the standard 
which some commenters mentioned. We also recognize that the regulated 
community is awaiting the proposed rule and subsequent final rule that 
will implement important privacy provisions

[[Page 44624]]

of the HITECH Act. 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. We also assumed that 
Complete EHR and EHR Module developers could find innovative ways to 
associate certain electronically available information with the 
disclosures, such as, to whom the disclosure was made. Again, for the 
time being, we have made this certification criterion optional, and 
will wait for OCR to promulgate final regulations for accounting of 
disclosures, before revisiting whether this certification criterion 
should be required.
b. Specific Certification for Complete EHRs or EHR Modules Designed for 
an Ambulatory Setting--Sec.  170.304
Section 170.304(a)--Computerized Provider Order Entry

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Use CPOE for medication orders  More than 30% of   Interim Final Rule
 directly entered by any         unique patients    Text:
 licensed healthcare             with at least     Enable a user to
 professional who can enter      one medication     electronically
 orders into the medical         in their           record, store,
 record per state, local and     medication list    retrieve, and
 professional guidelines.        seen by the EP     manage, at a
                                 or admitted to     minimum, the
                                 the eligible       following order
                                 hospital's or      types:
                                 CAH's inpatient   (1) Medications;
                                 or emergency      (2) Laboratory;
                                 department (POS   (3) Radiology/
                                 21 or 23) have     imaging; and
                                 at least one      (4) Provider
                                 medication order   referrals.
                                 entered using     Final Rule Text: Sec.
                                 CPOE.                170.304(a).
                                                   Computerized provider
                                                    order entry. Enable
                                                    a user to
                                                    electronically
                                                    record, store,
                                                    retrieve, and
                                                    modify, at a
                                                    minimum, the
                                                    following order
                                                    types:
                                                   (1) Medications;
                                                   (2) Laboratory; and
                                                   (3) Radiology/
                                                    imaging.
------------------------------------------------------------------------

    Comments. A couple of commenters noted that within the confines of 
many hospitals, just about any ``order'' can be entered, so the process 
of order entry is defined. For providers, the commenter noted that the 
ability to perform orders varies. The commenter inquired whether a 
specific meaning for order entry was intended for this certification 
criterion. A few commenters supported the certification criterion. One 
commenter recommended that referrals to dieticians, speech therapists, 
child life and social services be added to the order types, as well as 
durable medical equipment, orthotics, and prosthetics. Another 
commenter recommended that CPOE include a Patient Plan of Care (PPOC) 
because, according to the commenter, PPOC requires the content 
necessary for electronic data interoperability. The commenter felt that 
PPOC within an EHR would help to achieve the integration goals that 
promote the appropriate exchange of medical information for the optimal 
coordination of patient care in different healthcare settings. Another 
commenter suggested that we narrow the CPOE requirements to focus on 
medications, laboratory tests, and imaging tests. One commenter stated 
that based on the discussions of CPOE in the Interim Final Rule and the 
Medicare and Medicaid EHR Incentive Programs proposed rule, we should 
consider a request for a consultation or a provider referral made by an 
eligible professional in a private practice to constitute an order that 
should be handled functionally through CPOE.
    Response. We agree with the commenter that suggested that we narrow 
our focus, in order to reduce the burden associated with this 
certification criterion. Accordingly, we have removed ``provider 
referrals'' from the certification criterion. Complete EHR and EHR 
Module developers may include additional orders as they see fit and as 
recommended by some commenters, however in order to be certified they 
must include at a minimum the three order types (medications, 
laboratory, and radiology/imaging) specified in the certification 
criterion. Many commenters generally supported these three specified 
order types and we note that while the final meaningful use Stage 1 
objective focuses on medication orders, we believe that for the 
purposes of certification and to equip eligible professionals with a 
basic set of ordering capabilities, it is appropriate to continue to 
maintain these three order types. (This response also applies to the 
change we made in the CPOE certification criterion for Complete EHRs or 
EHR Modules designed for an inpatient setting). Finally, in further 
reviewing this certification criterion in light of comments received, 
we have also determined that it would be appropriate and clearer to 
replace the term ``manage'' with ``modify'' to be more consistent with 
the terminology used in other certification criteria. We have also made 
this change in the CPOE certification criterion for Complete EHRs and 
EHR Modules designed for an inpatient setting.
    Comment. A commenter stated that the lab industry does not have any 
standards for order entry, and even among lab providers, their 
operating units utilize different standards. The commenter contended 
that this lack of consistency in order entry would require EHRs to 
build custom interfaces to every lab. They recommended that we require 
that Certified EHR Technology provide the ability to link the results 
to the original order. Another commenter recommended that the 
certification criterion include the requirement for standardized bi-
directional laboratory interfaces, including functionality pertinent to 
all the laboratory order data needed for the laboratory to conduct 
proper testing, patient matching and billing (including limited 
coverage rules and printing of Advance Beneficiary Notices (ABNs)).
    Response. In the certification criterion discussed above regarding 
incorporating laboratory test results, we have required that Certified 
EHR Technology be capable of electronically attributing, associating, 
or linking a laboratory test result to a laboratory order or patient 
record. Bidirectional exchange (including electronic transmission of

[[Page 44625]]

laboratory orders) is not a requirement of meaningful use Stage 1 and 
is beyond the scope of this rule.
    Comments. Several commenters recommended we clarify that the user 
of CPOE includes the eligible professional and any authorized user in 
the office of the eligible professional (EP). They also recommended 
that CPOE be deemed to include the scenario in which only the actual 
orders are entered by the EP, with the additional billing and 
demographic information entered by authorized users in the EP's office 
or even by third parties (e.g. laboratory personnel in the patient 
service center of a laboratory that collects specimens from the 
patient).
    Response. As we stated in an earlier response, the standards, 
implementation specifications, and certification criteria adopted in 
this final rule apply to Complete EHRs and EHR Modules. We have focused 
on whether Certified EHR Technology must include a capability and how 
it must perform the capability. As a result, it is not within the scope 
of this rulemaking to specify the persons who would need to use CPOE.
    Comment. A commenter suggested that we not create controlled 
vocabularies or value sets in the regulation but rather refer to and 
adopt existing controlled vocabularies or subsets. The commenter also 
stated that the regulation introduces a requirement to record, store, 
retrieve and manage orders, though no vocabularies are specified and 
further pointed out that there are no vocabularies or standards for 
orders, images, or referrals in any part of the Interim Final Rule. The 
commenter recommended that the Department focus its efforts on 
identifying and adopting standards for computable and interoperable 
representations of these elements and processes before directing 
eligible professionals to implement ``CPOE.''
    Response. We appreciate the commenter's concern. This is an initial 
set of standards, implementation specifications, and certification 
criteria and we expect to adopt more standards, implementation 
specifications, and certification criteria in the future as necessary 
to improve the comprehensiveness of certain capabilities.
    Comment. A commenter requested that we clarify whether only imaging 
and radiology reports were intended to be included in this capability, 
or, if we intended to include the images themselves in addition to the 
imaging reports as part of the certification criteria. The commenter 
recommended that we further clarify the criterion and moreover, adopt 
the DICOM standard in the initial set of standards, as an essential 
step in meeting the CPOE capability.
    Response. We clarify that the adopted certification criteria 
related to CPOE pertain only to the ordering, and not to the delivery 
of results (reports or images). As a result, we do not believe that 
this commenter's recommendation is applicable to this certification 
criterion.
    Comment. A commenter recommended that the CPOE certification 
criterion should include a prompt for an authorized user of the CPOE to 
include diagnosis codes at order entry.
    Response. We do not believe that it would be appropriate to specify 
this type of capability as a condition of certification because it is 
not central to the meaningful use objective and measure this 
certification criterion is intended to support.
Section 170.304(b)--Electronically Exchange Prescription Information

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Generate and transmit           More than 40% of   Interim Final Rule
 permissible prescriptions       all permissible    Text:
 electronically (eRx).           prescriptions     Enable a user to
                                 written by the     electronically
                                 EP are             transmit medication
                                 transmitted        orders
                                 electronically     (prescriptions) for
                                 using certified    patients in
                                 EHR technology.    accordance with the
                                                    standards specified
                                                    in Sec.
                                                    170.205(c).
                                                   Final Rule Text: Sec.
                                                      170.304(b).
                                                      Electronic
                                                       prescribing.
                                                       Enable a user to
                                                       electronically
                                                       generate and
                                                       transmit
                                                       prescriptions and
                                                       prescription-
                                                       related
                                                       information in
                                                       accordance with:
                                                      (1) The standard
                                                       specified in Sec.
                                                         170.205(b)(1)
                                                       or Sec.
                                                       170.205(b)(2);
                                                       and
                                                      (2) The standard
                                                       specified in
                                                       170.207(d).
------------------------------------------------------------------------

    Comments. Many commenters supported the adoption of NCPDP SCRIPT 
8.1 and the inclusion of NCPDP SCRIPT 10.6. These commenters also 
encouraged the exclusive adoption of NCPDP 10.6 for meaningful use 
Stage 2. One commenter stated that more clarification was needed as to 
which NCPDP SCRIPT standard was required for certification.
    Response. In the Interim Final Rule, we stated that we expected 
that CMS would identify as a backwards compatible standard NCPDP SCRIPT 
10.6 and permit its use as an alternative to NCPDP SCRIPT 8.1 for the 
electronic transmission of prescription and certain other prescription-
related information for Medicare Part D covered drugs prescribed for 
Part D eligible individuals (75 FR 38026). Further, we stated that ``if 
SCRIPT 10.6 is permitted, prior to any modification of the provisions 
of this interim final rule in response to public comment, we would 
expect to change our requirement to simply permit either SCRIPT 8.1 or 
SCRIPT 10.6.'' Accordingly, we have modified this certification 
criterion to specify that Complete EHR and EHR Module developers may 
seek to have their Complete EHR or EHR Module tested and certified to 
either solely NCPDP SCRIPT 8.1 or 10.6. Additionally, we have also 
replaced the standard adopted in the Interim Final Rule and have 
adopted both NCPDP SCRIPT 8.1 and NCPDP SCRIPT 10.6. As discussed in 
the beginning of the preamble, we have revised our approach to 
specifying the certification criteria to more clearly focus on the 
capabilities with which they must be associated. Therefore, we have 
modified this certification criterion to specify that a Complete EHR or 
EHR Module would be compliant with this certification criterion if it 
has the capability of generating and transmitting prescription and 
prescription-related information according to NCPDP SCRIPT 8.1 while 
also using the adopted vocabulary standard, or if it is capable of 
generating and transmitting prescriptions and prescription-related 
information according to NCPDP SCRIPT 10.6 while also using the adopted 
vocabulary standard.
    Comments. Several commenters supported the adoption of RxNorm and 
the use of RxNorm code sets as a vocabulary standard. One commenter 
recommended that RxNorm be adopted

[[Page 44626]]

in Stage 1 while one commenter stated that Stage 2 is likely the 
earliest timeframe practicable for implementation. Others suggested 
that more testing was needed before RxNorm could be adopted in full. 
Some commenters stated that RxNorm is not complete and requested 
guidance on how gaps in RxNorm will be addressed. A couple commenters 
stated a concern that current drug databases do not map to RxNorm and 
that in order to develop interfaces for electronic prescribing 
services, pharmacies and developers will need to expend significant 
effort. Other commenters stated that more clarification was needed with 
respect to the description of the adopted standard and one of those 
commenters recommended that the description be changed to ``a drug data 
source provider that demonstrates group domain comprehensiveness.''
    Response. We have consolidated and addressed our adopted vocabulary 
standard for medications under this certification criterion. However, 
our response and subsequent clarifications are applicable to all 
certification criteria that reference this vocabulary standard.
    As we explained in the Interim Final Rule, we determined that the 
HIT industry would benefit from a certain degree of flexibility with 
respect to the coding of medications. To provide this flexibility while 
also establishing a glide path to full adoption of RxNorm, we adopted a 
standard that permits the use of one of many different vocabulary 
standards. We specified that a Complete EHR or EHR Module would be 
compliant with the adopted vocabulary standard if it utilized ``[a]ny 
code set by an RxNorm drug data source provider that is identified by 
the United States National Library of Medicine as being a complete data 
set integrated within RxNorm.'' We specified the standard this way in 
order to establish what we believe is an important bridge to full 
RxNorm adoption and will help facilitate this transition over time. Our 
adoption of this standard stems from our belief that Complete EHRs and 
EHR Modules should be capable of classifying and categorizing 
medications for the purpose of clinical quality measurement and 
clinical decision support. The National Library of Medicine (NLM) 
maintains the Unified Medical Language System[supreg] (UMLS[supreg]), 
which contains the mapping between RxNorm and commonly utilized drug 
vocabularies.
    At the time we published the Interim Final Rule, we noted that NLM, 
according to the most recent RxNorm release, listed a number of RxNorm 
drug data source providers with complete data sets integrated within 
RxNorm. After the Interim Final Rule was published, NLM subsequently 
released several more RxNorm versions. NLM has also reorganized the 
RxNorm documentation in a way that we believe more clearly specifies 
the intent of our standard. Accordingly, we believe that this standard, 
particularly in response to public comments, can be further clarified. 
In addition, to permit the development or mapping and use of other 
vocabularies independent of NLM, we have dropped the requirement that 
NLM explicitly identify the acceptable data sources. Instead, the 
standard now permits the use of codes from any drug vocabulary 
successfully included in RxNorm. To provide guidance and clarification 
to the industry, we will recognize any source vocabulary that is 
identified by NLM's RxNorm Documentation as a source vocabulary 
included in RxNorm. We are therefore revising the standard to state: 
``Any source vocabulary that is included in RxNorm, a standardized 
nomenclature for clinical drugs produced by the United States National 
Library of Medicine.'' We note that in section 3.1, of the most recent 
release of the ``RxNorm Documentation (06/07/10, Version 2010-3) \7\,'' 
NLM has identified the following source vocabularies as being included 
in RxNorm.
---------------------------------------------------------------------------

    \7\ http://www.nlm.nih.gov/research/umls/rxnorm/docs/2010/
rxnorm_doco_full_2010-3.html.
---------------------------------------------------------------------------

     GS--Gold Standard Alchemy.
     MDDB--Medi-Span Master Drug Data Base.
     MMSL--Multum MediSource Lexicon.
     MMX--Micromedex DRUGDEX.
     MSH--Medical Subject Headings (MeSH).
     MTHFDA--FDA National Drug Code Directory.
     MTHSPL--FDA Structured Product Labels.
     NDDF--First DataBank NDDF Plus Source Vocabulary.
     NDFRT--Veterans Health Administration National Drug File--
Reference Terminology.
     SNOMED CT--SNOMED Clinical Terms (drug information).
     VANDF--Veterans Health Administration National Drug File.
    We clarify for commenters that the standard we have adopted is a 
functional standard that enables the use of any source vocabulary that 
is included within RxNorm. Consequently, any one of these ``source 
vocabularies'' identified by NLM may be used, or any other source 
vocabulary successfully included within RxNorm.
    Comments. A few commenters stated concerns about this certification 
criterion causing two different workflows because of the restrictions 
placed on the electronic prescribing of controlled substances.
    Response. The Drug Enforcement Agency has since published an 
interim final rule (75 FR 16236) on the requirements related to the 
electronic prescribing of controlled substances. At the present time, 
we do not require as a condition of certification for Complete EHRs and 
EHR Modules that they be capable of enabling compliance with the 
current DEA provisions for the electronic prescribing of controlled 
substances.
    Comments. A couple of commenters stated that the prescribing 
capabilities must allow for weight-based dosing calculation with 
intelligent rounding and that without this, e-prescribing will not be 
helpful to pediatricians.
    Response. We recognize that this is an important capability for 
pediatricians; however, we do not believe that it necessary to require 
it as a condition of certification at the present time. Again, this 
does not preclude Complete EHR and EHR Module developers from including 
this capability.
    Comments. A few commenters expressed concerns about some pharmacies 
not being capable of receiving electronic prescriptions which they 
stated could cause a negative impact on the workflow. One commenter 
suggested that we add a ``where possible'' to the certification 
criterion.
    Response. While we recognize that some pharmacies may be unable to 
receive electronic prescriptions at the present time, we do not believe 
this limitation should affect the capability that Certified EHR 
Technology must provide. Further, we do not believe that inserting 
``where applicable'' would be beneficial because it would make the 
criterion unnecessarily ambiguous. This phrase would relate to when 
electronic prescribing should be conducted, not how it should be done, 
which is the focus of this certification criterion.
    Comment. A commenter stated that the electronic prescribing process 
should be linked to the contraindication and formulary conflict process 
and should provide automatic alerts. Another commenter recommended that 
information relating to the language the patient speaks should be 
required as part of the electronic prescribing process, so that 
pharmacy is notified of a patient's need for language assistance.
    Response. We do not believe that it would be appropriate to expand 
the certification criterion as suggested at this time. This does not 
preclude a Complete EHR or EHR Module

[[Page 44627]]

developer from pursuing other ways to optimize how a Complete EHR or 
EHR Module may function.
Section 170.304(c)--Record Demographics

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Record demographics:            More than 50% of   Interim Final Rule
 preferred language...   all unique         Text:
 gender...............   patients seen by  Enable a user to
 race.................   the EP or          electronically
 ethnicity............   admitted to the    record, modify, and
 date of birth........   eligible           retrieve patient
                                 hospital's or      demographic data
                                 CAH's inpatient    including preferred
                                 or emergency       language, insurance
                                 department (POS    type, gender, race,
                                 21 or 23) have     ethnicity, and date
                                 demographics       of birth.
                                 recorded as       Final Rule Text: Sec.
                                 structured data      170.304(c).
                                                   Record demographics.
                                                    Enable a user to
                                                    electronically
                                                    record, modify, and
                                                    retrieve patient
                                                    demographic data
                                                    including preferred
                                                    language, gender,
                                                    race, ethnicity, and
                                                    date of birth.
                                                    Enable race and
                                                    ethnicity to be
                                                    recorded in
                                                    accordance with the
                                                    standard specified
                                                    at 170.207(f).
------------------------------------------------------------------------

    Comments. Several commenters recommended that we adopt the OMB race 
and ethnicity codes.
    Response. We agree with these commenters and have adopted the OMB 
race and ethnicity codes. In the Medicare and Medicaid EHR Incentive 
Programs proposed rule (75 FR 1855), CMS stated that race and ethnicity 
codes should follow current Federal standards. We note that the OMB 
race and ethnicity codes constitute a government-unique standard for 
the purposes of the National Technology Transfer and Advancement Act of 
1995 (NTTAA). We have adopted this standard because it provides an 
easily understood structure and format for electronically transmitting 
the data elements identified in the meaningful use Stage 1 objective, 
the standard is readily available, in general it provides the best 
standard to use to support our policies goals. Moreover, we are unaware 
of any alternative voluntary consensus standard that accomplishes the 
same purpose.
    Comments. Several commenters recommended additional elements for 
the certification criterion for us to consider adding. One commenter 
recommended that we include more demographic data items to allow 
successful matching with prior admissions and further that we consider 
requiring the inclusion of social security number, birthplace, and 
years of education, if available. A couple commenters requested that we 
add occupation and industry status as well because they are already 
required for cancer registries. Another commenter suggested that we add 
family history to demographics that should be captured and reported. 
One commenter suggested that we also include a patient's functional 
status. Many commenters suggested that we encourage self-reporting of 
demographics and indicate whether information was self-reported. 
Finally, one commenter stated that EHRs are not appropriate source of 
legal documentation for births and deaths.
    Response. While we understand commenters' intentions, we do not 
believe that it would be appropriate to expand this certification 
criterion beyond what is required to support meaningful use. Again, as 
we have previously stated, this does not preclude a Complete EHR or EHR 
Module developer from including the capability to record additional 
demographic information. Finally, consistent with the Medicare and 
Medicaid EHR Incentive Programs final rule, we have removed the 
capability to record insurance type from the certification criterion.
Section 170.304(d)--Generate Patient Reminder List

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Send reminders to patients per  More than 20% of   Interim Final Rule
 patient preference for          all unique         Text:
 preventive/ follow up care      patients 65       Electronically
                                 years or older     generate, upon
                                 or 5 years old     request, a patient
                                 or younger were    reminder list for
                                 sent an            preventive or follow-
                                 appropriate        up care according to
                                 reminder during    patient preferences
                                 the EHR            based on demographic
                                 reporting period   data, specific
                                                    conditions, and/or
                                                    medication list.
                                                   Final Rule Text: Sec.
                                                      170.304(d).
                                                   Patient reminders.
                                                    Enable a user to
                                                    electronically
                                                    generate a patient
                                                    reminder list for
                                                    preventive or follow-
                                                    up care according to
                                                    patient preferences
                                                    based on, at a
                                                    minimum, the data
                                                    elements included
                                                    in:
                                                   (1) Problem list;
                                                   (2) Medication list;
                                                   (3) Medication
                                                    allergy list;
                                                   (4) Demographics; and
                                                   (5) Laboratory test
                                                    results.
------------------------------------------------------------------------

    Comments. Several commenters stated that they support this 
certification criterion. Other commenters requested further definition 
of the term ``specific conditions,'' particularly whether this term 
refers to data as contained in the problem list. One commenter 
suggested that the criterion text be modified to read: ``Electronically 
generate, upon request, a patient reminder list for preventive or 
follow-up care according to patient or physician preferences based on 
demographic data, specific conditions, and/or medication list.'' 
Several commenters requested further definition of the term ``patient 
preferences.'' Clarification was requested about the meaning of the 
term, how these preferences would be recorded, how the preferences 
would be used, and whether the preferences should be automated. A 
question was raised by two commenters about how many choices should be 
allowed for the preferred reminder delivery method due to additional 
EHR system programming that may be

[[Page 44628]]

needed to support the set of choices. One commenter was concerned about 
whether there would be a cost to physician practices to implement this 
requirement and whether the practices will have the capacity to 
accommodate this requirement. Another commenter suggested that this 
requirement be moved to meaningful use stage 2 to allow more time for 
EHRs to be enhanced. Several commenters requested clarification of the 
term ``upon request.'' One commenter wanted to know which persons would 
be authorized to request the patient reminder list and how often. 
Another commenter suggested that the phrase ``upon request'' be 
removed, as it believed that outpatient physicians could make 
significant advances in the health of their patients by generating and 
delivering reminders at every encounter.
    Response. In response to comments, we have revised this 
certification criterion to more clearly articulate the capability we 
expect Certified EHR Technology to include. CMS discusses and clarifies 
the intended meaning of ``patient preferences'' in the Medicare and 
Medicaid EHR Incentive Programs final rule and because this term is 
derived from the meaningful use objective, we encourage commenters to 
review CMS's responses to their requests for clarification. Consistent 
with the revisions we made to the ``generate patient lists'' 
certification criterion, we believe that Certified EHR Technology 
should be able to leverage the information, specifically the structured 
data it had available to it, to assist eligible professionals and 
eligible hospitals generate a patient reminder list. We have removed 
``upon request'' from the certification criterion, because, after 
further review, we believe that the action of requesting a list is 
implied by the certification criterion and the meaningful use measure, 
and therefore, unnecessary to further specify.
    Comments. Two commenters stated that specialists will use patient 
reminders differently than primary care providers. These commenters 
worried that some patients' preferences may exceed a system's current 
capabilities and one commenter requested that the phrase ``with respect 
to system capability'' be added after ``patient preferences.''
    Response. We understand these commenters' points of view, however, 
we do not believe that this addition is necessary given the references 
in the certification criterion to specified data elements and CMS's 
express desire to consider patient preferences as described in the 
Medicare and Medicaid EHR Incentive Programs final rule.
    Comments. Two commenters asked whether this requirement refers to 
the creation of a list for the internal purposes of the eligible 
professional and his/her staff only and does not refer to or require 
electronic communication to a patient.
    Response. Yes, we expect Certified EHR Technology to be capable of 
generating a patient reminder list for an eligible professional and 
his/her staff. The meaningful use measure establishes the requirement 
for an eligible professional to take action once the reminder list has 
been generated.
    Comments. Two commenters suggested that the set of variables 
contained in the demographic information for the patient lists note the 
preferred language of the patient.
    Response. Preferred language is included in demographics and we do 
not believe that it is necessary to expressly call it out as part of 
this certification criterion.
Section 170.304(e)--Clinical Decision Support

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Implement one clinical          Implement one      Interim Final Rule
 decision support rule           clinical           Text:
 relevant to specialty or high   decision support  (1) Implement rules.
 clinical priority along with    rule.              Implement automated,
 the ability to track                               electronic clinical
 compliance that rule.                              decision support
                                                    rules (in addition
                                                    to drug-drug and
                                                    drug-allergy
                                                    contraindication
                                                    checking) according
                                                    to specialty or
                                                    clinical priorities
                                                    that use demographic
                                                    data, specific
                                                    patient diagnoses,
                                                    conditions,
                                                    diagnostic test
                                                    results and/or
                                                    patient medication
                                                    list.
                                                      (2) Alerts.
                                                       Automatically and
                                                       electronically
                                                       generate and
                                                       indicate in real-
                                                       time, alerts and
                                                       care suggestions
                                                       based upon
                                                       clinical decision
                                                       support rules and
                                                       evidence grade.
                                                      (3) Alert
                                                       statistics.
                                                       Automatically and
                                                       electronically
                                                       track, record,
                                                       and generate
                                                       reports on the
                                                       number of alerts
                                                       responded to by a
                                                       user.
                                                   Final Rule Text: Sec.
                                                      170.304(e).
                                                      (1) Implement
                                                       rules. Implement
                                                       automated,
                                                       electronic
                                                       clinical decision
                                                       support rules (in
                                                       addition to drug-
                                                       drug and drug-
                                                       allergy
                                                       contraindication
                                                       checking) based
                                                       on the data
                                                       elements included
                                                       in: problem list;
                                                       medication list;
                                                       demographics; and
                                                       laboratory test
                                                       results.
                                                      (2) Notifications.
                                                       Automatically and
                                                       electronically
                                                       generate and
                                                       indicate in real-
                                                       time,
                                                       notifications and
                                                       care suggestions
                                                       based upon
                                                       clinical decision
                                                       support rules.
------------------------------------------------------------------------

    Comments. Several commenters were explicitly supportive of this 
certification criterion, while others offered specific suggestions and 
requests for clarification. Several commenters requested that we 
specify the decisions support rules that should be included. One 
commenter asked if we could clarify whether a Complete EHR or EHR 
Module developer would have to include specific rules that individual 
eligible professionals would want or whether those rules could be added 
later. Another commenter asked for clarification regarding several 
terms including ``diagnostic test results,'' whether a ``condition'' 
was equivalent to ``problem,'' as well as whether the rules would be 
associated with quality measures.
    Response. In consideration of commenters' request for clarification 
and to more closely align this certification criterion with the 
meaningful use measure, we have revised this certification criterion. 
We have removed the terms that caused some confusion with commenters 
and believe that these revisions will provide more specificity and will 
make

[[Page 44629]]

compliance with the certification criterion easier. Moreover, we 
clarify that with respect to notifications, that ``real-time'' means at 
the point of clinical decision making (i.e., notifications must be 
provided when an eligible professional is using Certified EHR 
Technology and not run overnight and provided in the morning, for 
instance).
    Comments. A number of commenters asked questions and requested 
clarifications regarding ``alerts.'' One commenter requested whether it 
is the number of alerts that is important or the type of alerts that is 
important and how we expect an eligible professional to respond to an 
alert. The commenter also asked if we could clarify what would qualify 
as a ``response.'' One commenter stated that whether we intended for 
the examples (pop-up or sound) to be inclusive of the types of alerts 
we expected Certified EHR Technology would include and whether this was 
deemed more valuable than a more passive notification. The commenter 
suggested that the word ``alert'' be replaced with ``notification'' 
while another suggested the word ``advisory.'' Some commenters 
requested clarification regarding ``alerts responded to by a user'' and 
whether there was an expectation that alerts communicate structured 
reasons. These commenters also asked whether users would enter a reason 
for any overrides or, in the case of notifications, the user would 
simply acknowledge the alert by clicking ``OK.'' The commenters also 
questioned whether ignored alerts should be tracked? Many of these 
commenters recommended removing Sec.  170.304(e)(3). Alternatively, one 
commenter recommended that we not only consider the number of alerts 
``responded to'' but also the action prompted and whether or not that 
action was taken.
    Response. We thank commenters for the thorough feedback on this 
certification criterion. We have already addressed in our responses 
above the concerns raised by commenters and will not repeat them here. 
With respect to the third part of this certification criterion, we have 
considered public comment and have decided to remove the requirement 
from the certification criterion. We also removed this requirement to 
be more consistent with CMS's expectations for meaningful use, which do 
not include requiring the tracking of alerts at this time.
    Comments. A few commenters asked for clarification on what we meant 
by ``evidence grade'' and what standard for evidence grading will be 
applied in order to determine compliance with this objective. Other 
commenters noted that ``evidence grade'' as a part of the rules to 
trigger alerts is not widely available in the marketplace and that 
using evidence grade in this manner could be burdensome and present a 
significant maintenance issue.

    Response. We have considered public comment, and agree that 
evidence grade is not as widely available in the marketplace as we had 
anticipated. We therefore remove our reference to ``evidence grade'' in 
the certification criterion.
Section 170.304(f)--Electronic Copy of Health Information

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Provide patients with an        More than 50% of   Interim Final Rule
 electronic copy of their        all patients of    Text:
 health information (including   the EP or the     Enable a user to
 diagnostic test results,        inpatient or       create an electronic
 problem list, medication        emergency          copy of a patient's
 lists, medication allergies),   departments of     clinical
 upon request.                   the eligible       information,
                                 hospital or CAH    including, at a
                                 (POS 21 or 23)     minimum, diagnostic
                                 who request an     test results,
                                 electronic copy    problem list,
                                 of their health    medication list,
                                 information are    medication allergy
                                 provided it        list, immunizations,
                                 within 3           and procedures in:
                                 business days.    (1) Human readable
                                                    format; and
                                                   (2) On electronic
                                                    media or through
                                                    some other
                                                    electronic means in
                                                    accordance with:
                                                   (i) One of the
                                                    standards specified
                                                    in Sec.
                                                    170.205(a)(1);
                                                      (ii) The standard
                                                       specified in Sec.

                                                       170.205(a)(2)(i)(
                                                       A), or, at a
                                                       minimum, the
                                                       version of the
                                                       standard
                                                       specified in Sec.

                                                       170.205(a)(2)(i)(
                                                       B);
                                                      (iii) One of the
                                                       standards
                                                       specified in Sec.

                                                       170.205(a)(2)(ii)
                                                       ;
                                                      (iv) At a minimum,
                                                       the version of
                                                       the standard
                                                       specified in Sec.

                                                       170.205(a)(2)(iii
                                                       ); and
                                                      (v) The standard
                                                       specified in Sec.

                                                       170.205(a)(2)(iv)
                                                       .
                                                   Final Rule Text: Sec.
                                                      170.304(f).
                                                      Electronic copy of
                                                       health
                                                       information.
                                                       Enable a user to
                                                       create an
                                                       electronic copy
                                                       of a patient's
                                                       clinical
                                                       information,
                                                       including, at a
                                                       minimum,
                                                       diagnostic test
                                                       results, problem
                                                       list, medication
                                                       list, and
                                                       medication
                                                       allergy list in:
                                                      (1) Human readable
                                                       format; and
                                                      (2) On electronic
                                                       media or through
                                                       some other
                                                       electronic means
                                                       in accordance
                                                       with:
                                                      (i) The standard
                                                       (and applicable
                                                       implementation
                                                       specifications)
                                                       specified in Sec.
                                                         170.205(a)(1)
                                                       or Sec.
                                                       170.205(a)(2);
                                                       and
                                                      (ii) For the
                                                       following data
                                                       elements the
                                                       applicable
                                                       standard must be
                                                       used:
                                                      (A) Problems. The
                                                       standard
                                                       specified in Sec.
                                                         170.207(a)(1)
                                                       or, at a minimum,
                                                       the version of
                                                       the standard
                                                       specified in Sec.
                                                         170.207(a)(2);
                                                      (B)Laboratory test
                                                       results. At a
                                                       minimum, the
                                                       version of the
                                                       standard
                                                       specified in Sec.
                                                         170.207(c); and
                                                      (C) Medications.
                                                       The standard
                                                       specified in Sec.
                                                         170.207(d).
------------------------------------------------------------------------

    Comment. A commenter recommended that durable medical equipment and 
supplies be added to the minimum list.
    Response. In the context of the Meaningful Use Stage 1 objective 
and measure, we do not believe that it is appropriate, at the present 
time, to add durable medical equipment in the certification criterion. 
However, that does not preclude Complete EHRs and

[[Page 44630]]

EHR Modules from having that additional capability.
    Comments. A few commenters requested clarification as to the 
underlying intent of the certification criterion and whether it was 
intended that a patient be provided with a complete medical record or 
simply a ``snapshot.'' Commenters also asked how longitudinal the copy 
must be and requested that we specify a time period that the electronic 
copy must cover. A commenter stated that eligible professionals should 
be able to limit the applicable time period by episode of care or other 
parameters. The commenter noted that state law also specifies the 
information that can be provided to a patient without the provider 
serving as an intermediary. A few commenters requested clarification 
that the medication list is limited to the current medication list. A 
commenter recommended that the certification criterion be limited only 
to information readily available to the provider at the conclusion of a 
patient encounter.
    Response. We expect Certified EHR Technology to be capable of 
generating an electronic copy of health information that includes the 
minimum elements required as a condition of certification. We do not 
believe that it is appropriate to dictate the timeframe such 
information must encompass, but we would expect that it would include, 
at a minimum, the most current information that is available and 
accessible within the Certified EHR Technology. We do not believe that 
limiting this certification criterion to specify that just the 
information available at the end of an encounter is consistent with our 
policy objectives.
    Comments. Many commenters requested a definition of ``diagnostic 
test results.'' One commenter suggested that for Stage 1, the 
definition of diagnostic test result be made clear and be limited to, 
at a minimum, lab results.
    Response. This term is derived from the Medicare and Medicaid EHR 
Incentive Programs final rule, and its meaning is described there. We 
encourage commenters to review the Medicare and Medicaid EHR Incentive 
Programs final rule.
    Comments. Several commenters requested that ONC define how relevant 
procedures are determined for the certification criterion. The 
commenters suggested that a subset of procedures (e.g., surgeries, 
catheterizations) be defined to avoid generating huge lists of 
``small'' procedures (e.g., venipunctures). These commenters expressed 
that it was critical for the rule to provide a clear, clinically-
relevant definition of which types of procedures are to be included.
    Response. We appreciate the comment and have revised this 
certification criterion to remove ``procedures'' as well as 
``immunizations,'' to be more consistent with the final meaningful use 
objective and measure and for greater clarity.
    Comment. A commenter requested clarification on how an electronic 
copy will be disseminated, and provided examples such as a web-portal, 
e-mail, and compact disc.
    Response. We do not specify the method by which an individual must 
receive an electronic copy of the specified health information, only 
that Certified EHR Technology be capable of electronically generating 
an electronic copy in human readable format and in accordance with one 
of the adopted summary record standards. While Certified EHR Technology 
must be capable of creating an electronic copy of a patient's health 
information as specified in this certification criterion, we encourage 
Complete EHR and EHR Module developers to also include the capability 
to generate an electronic copy in a manner that allows eligible 
professionals (and eligible hospitals as this capability relates to 
Complete EHRs and EHR Modules designed for an inpatient setting) to 
comply with applicable provisions of the HIPAA Privacy and Security 
Rules.
    Comment. A commenter requested that we add a requirement for alerts 
to prompt users to ask patients if they want a copy of their health 
information and include the ability to record whether the information 
was actually provided and the patient's preference on the format of the 
information. The commenter believed that this requirement is necessary 
because many patients are not aware that they can make such a request.
    Response. While potentially useful as a reminder, we do not believe 
that this capability should be a condition of certification. This 
capability would exceed the scope of the relevant meaningful use Stage 
1 objective and measure. We also note that Complete EHR and EHR Module 
developers are not precluded from including this capability in their 
EHR technology.
    Comment. A commenter noted that with our emphasis on the 
representation of clinical information in the format of a CCD or CCR, 
it is unclear whether the certification criterion is enough to meet 
patients' expectations.
    Response. We recognize that this minimum information may not 
satisfy every patient's interests, however, we believe that the 
information specified represents a core set of information that most 
patients will appreciate is more readily accessible to them.
    Comment. A commenter requested clarification on the use of the word 
``and'' in the certification criterion and questioned whether it 
suggested that the Certified EHR Technology must generate two outputs 
to produce an electronic copy (i.e., a copy in human readable format 
and a copy as a CCD or CCR). The commenter made this inquiry because it 
believed that the certification criterion could be met through the 
production of a CCD or CCR with an appropriate style sheet. 
Additionally, a commenter stated that it is unclear whether the 
electronic copy of the health information provided to patients must be 
in a CCD or CCR format for Stage 1 or if alternative formats are 
allowed. This commenter recommended that we clarify and distinguish 
between the electronic medium carrying the information and the content 
enclosed.
    Response. Yes, in order to meet this certification criterion, 
Certified EHR Technology must be able to generate an electronic copy 
that is in human readable format and as a CCD or CCR. If Certified EHR 
Technology is capable of generating one copy that could meet both of 
these requirements, we would consider that to be a compliant 
implementation of this capability.
Section 170.304(g)--Timely Access

[[Page 44631]]



------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Provide patients with timely    More than 10% of   Interim Final Rule
 electronic access to their      all unique         Text:
 health information (including   patients seen by  Enable a user to
 lab results, problem list,      the EP are         provide patients
 medication lists, medication    provided timely    with online access
 allergies) within four          (available to      to their clinical
 business days of the            the patient        information,
 information being available     within four        including, at a
 to the EP.                      business days of   minimum, lab test
                                 being updated in   results, problem
                                 the certified      list, medication
                                 EHR technology)    list, medication
                                 electronic         allergy list,
                                 access to their    immunizations, and
                                 health             procedures.
                                 information       Final Rule Text: Sec.
                                 subject to the       170.304(g).
                                 EP's discretion   Timely access. Enable
                                 to withhold        a user to provide
                                 certain            patients with online
                                 information.       access to their
                                                    clinical
                                                    information,
                                                    including, at a
                                                    minimum, lab test
                                                    results, problem
                                                    list, medication
                                                    list, and medication
                                                    allergy list.
------------------------------------------------------------------------

    Comments. Many commenters suggested that we should replace the word 
``online'' with ``electronic'' to be more clearly aligned with 
meaningful use and to not preclude other forms of legitimate electronic 
access.
    Response. We disagree. The purpose and intent of this certification 
criterion and its associated meaningful use objective and measure (as 
clarified in the Medicare and Medicaid EHR Incentive Programs final 
rule) is to ensure that patients have the ability to access their 
health information when they see fit to do so. Accordingly, referring 
to ``electronic'' in this certification criterion would not ensure that 
Certified EHR Technology provides the desired capability.
    Comments. A few commenters asked for clarification on the meaning 
of ``procedures'' and type of results to be listed in the electronic 
copy, for example, lab test results, problem list, medication lists, or 
others specified by the eligible professional.
    Response. As discussed above, we have revised this certification 
criterion to remove ``procedures'' as well as ``immunizations,'' to be 
more consistent with the final meaningful use objective and measure.
Section 170.304(h)--Clinical Summaries

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Provide clinical summaries for  Clinical           Interim Final Rule
 patients for each office        summaries          Text:
 visit.                          provided to       (1) Provision. Enable
                                 patients for       a user to provide
                                 more than 50% of   clinical summaries
                                 all office         to patients for each
                                 visits within 3    office visit that
                                 business days.     include, at a
                                                    minimum, diagnostic
                                                    test results,
                                                    problem list,
                                                    medication list,
                                                    medication allergy
                                                    list, immunizations
                                                    and procedures.
                                                   (2) Provided
                                                    electronically. If
                                                    the clinical summary
                                                    is provided
                                                    electronically it
                                                    must be:
                                                      (i) Provided in
                                                       human readable
                                                       format; and
                                                      (ii) On electronic
                                                       media or through
                                                       some other
                                                       electronic means
                                                       in accordance
                                                       with:
                                                      (A) One of the
                                                       standards
                                                       specified in Sec.
                                                         170.205(a)(1);
                                                      (B) The standard
                                                       specified in Sec.

                                                       170.205(a)(2)(i)(
                                                       A), or, at a
                                                       minimum, the
                                                       version of the
                                                       standard
                                                       specified in Sec.

                                                       170.205(a)(2)(i)(
                                                       B);
                                                      (C) One of the
                                                       standards
                                                       specified in Sec.

                                                       170.205(a)(2)(ii)
                                                       ;
                                                      (D) At a minimum,
                                                       the version of
                                                       the standard
                                                       specified in Sec.

                                                       170.205(a)(2)(iii
                                                       ); and
                                                      (E) The standard
                                                       specified in Sec.

                                                       170.205(a)(2)(iv)
                                                       .
                                                   Final Rule Text: Sec.
                                                      170.304(h).
                                                      Clinical
                                                       summaries. Enable
                                                       a user to provide
                                                       clinical
                                                       summaries to
                                                       patients for each
                                                       office visit that
                                                       include, at a
                                                       minimum,
                                                       diagnostic test
                                                       results, problem
                                                       list, medication
                                                       list, and
                                                       medication
                                                       allergy list. If
                                                       the clinical
                                                       summary is
                                                       provided
                                                       electronically it
                                                       must be:
                                                      (1) Provided in
                                                       human readable
                                                       format; and
                                                      (2) Provided on
                                                       electronic media
                                                       or through some
                                                       other electronic
                                                       means in
                                                       accordance with:
                                                      (i) The standard
                                                       (and applicable
                                                       implementation
                                                       specifications)
                                                       specified in Sec.
                                                         170.205(a)(1)
                                                       or Sec.
                                                       170.205(a)(2);
                                                       and
                                                      (ii) For the
                                                       following data
                                                       elements the
                                                       applicable
                                                       standard must be
                                                       used:
                                                      (A) Problems. The
                                                       standard
                                                       specified in Sec.
                                                         170.207(a)(1)
                                                       or, at a minimum,
                                                       the version of
                                                       the standard
                                                       specified in Sec.
                                                         170.207(a)(2);
                                                      (B)Laboratory test
                                                       results. At a
                                                       minimum, the
                                                       version of the
                                                       standard
                                                       specified in Sec.
                                                         170.207(c); and
                                                      (C) Medications.
                                                       The standard
                                                       specified in Sec.
                                                         170.207(d).
------------------------------------------------------------------------

    Comments. Several commenters requested that ``diagnostic test 
results'' be further defined, with one commenter suggesting that lab 
results be the minimum and other commenters suggesting a more 
comprehensive list, including diagnostic imaging results. Many 
commenters requested clarification on the list of procedures and asked 
whether this would include only procedures in a recent hospitalization 
or historically all procedures performed on the patient. One commenter 
questioned why immunization data appeared in the list

[[Page 44632]]

and believed its inclusion was inconsistency with the other items.
    Response. We have made revisions to this certification criterion 
consistent with the changes that we have already discussed above, 
including the removal of certain terms.
    Comment. One commenter expressed concern that patient summaries are 
most useful when the patient/family literacy and the context of the 
health and follow-up care are taken into consideration. The commenter 
noted further that as written there is little flexibility in this 
certification criterion and that many patients will be overwhelmed with 
technical data that comes with little context for understanding it.
    Response. We understand the commenter's point; however, we do not 
believe that certification (which will validate whether a Complete EHR 
or EHR Module can perform this capability in a manner compliant with 
the standards adopted by the Secretary) is the appropriate mechanism to 
address this commenter's concerns.
    Comment. One commenter urged that patient summaries be 
affirmatively offered to the patient, without their requesting them, 
and that the offer be provided in their native language with the offer 
documented in the EHR.
    Response. We do not believe that it is within the scope of this 
final rule to require eligible professionals to offer patient summaries 
to patients.
    Comments. Several commenters requested that this rule clarify that 
providers would only be responsible for the completeness and accuracy 
of the clinical summary to the extent they provided or did not provide 
the relevant data (e.g. if another provider has not forwarded data, 
they are not responsible).
    Response. We do not believe that this behavior can be addressed by 
the certification criterion, nor do we believe that it is within the 
scope of this final rule.
Section 170.304(i)--Exchange Clinical Information and Patient Summary 
Record

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
          objectives             Stage 1 measures        criterion
------------------------------------------------------------------------
Capability to exchange key      Performed at       Interim Final Rule
 clinical information (for       least one test     Text:
 example, problem list,          of certified EHR  (1) Electronically
 medication list, medication     technology's       receive and display.
 allergies, diagnostic test      capacity to        Electronically
 results), among providers of    electronically     receive a patient's
 care and patient authorized     exchange key       summary record, from
 entities electronically.        clinical           other providers and
                                 information.       organizations
                                                    including, at a
                                                    minimum, diagnostic
                                                    tests results,
                                                    problem list,
                                                    medication list,
                                                    medication allergy
                                                    list, immunizations,
                                                    and procedures in
                                                    accordance with Sec.
                                                      170.205(a) and
                                                    upon receipt of a
                                                    patient summary
                                                    record formatted in
                                                    an alternate
                                                    standard specified
                                                    in Sec.
                                                    170.205(a)(1),
                                                    display it in human
                                                    readable format.
                                                   (2) Electronically
                                                    transmit. Enable a
                                                    user to
                                                    electronically
                                                    transmit a patient
                                                    summary record to
                                                    other providers and
                                                    organizations
                                                    including, at a
                                                    minimum, diagnostic
                                                    test results,
                                                    problem list,
                                                    medication list,
                                                    medication allergy
                                                    list, immunizations,
                                                    and procedures in
                                                    accordance with:
The EP, eligible hospital or    The EP, eligible      (i) One of the
 CAH who transitions their       hospital or CAH       standards
 patient to another setting of   who transitions       specified in Sec.
 care or provider of care or     or refers their         170.205(a)(1);
 refers their patient to         patient to
 another provider of care        another setting
 should provide summary of       of care or
 care record for each            provider of care
 transition of care or           provides a
 referral.                       summary of care
                                 record for more
                                 than 50% of
                                 transitions of
                                 care and
                                 referrals.
                                                      (ii) The standard
                                                       specified in Sec.

                                                       170.205(a)(2)(i)(
                                                       A), or, at a
                                                       minimum, the
                                                       version of the
                                                       standard
                                                       specified in Sec.

                                                       170.205(a)(2)(i)(
                                                       B);
                                                      (iii) One of the
                                                       standards
                                                       specified in Sec.

                                                       170.205(a)(2)(ii)
                                                       ;
                                                      (iv) At a minimum,
                                                       the version of
                                                       the standard
                                                       specified in Sec.

                                                       170.205(a)(2)(iii
                                                       ); and
                                                      (v) The standard
                                                       specified in Sec.

                                                       170.205(a)(2)(iv)
                                                       .
                                                   Final Rule Text: Sec.
                                                      170.304(i)
                                                   (1) Electronically
                                                    receive and display.
                                                    Electronically
                                                    receive and display
                                                    a patient's summary
                                                    record, from other
                                                    providers and
                                                    organizations
                                                    including, at a
                                                    minimum, diagnostic
                                                    tests results,
                                                    problem list,
                                                    medication list, and
                                                    medication allergy
                                                    list in accordance
                                                    with the standard
                                                    (and applicable
                                                    implementation
                                                    specifications)
                                                    specified in Sec.
                                                    170.205(a)(1) or
                                                    Sec.
                                                    170.205(a)(2). Upon
                                                    receipt of a patient
                                                    summary record
                                                    formatted according
                                                    to the alternative
                                                    standard, display it
                                                    in human readable
                                                    format.
                                                   (2) Electronically
                                                    transmit. Enable a
                                                    user to
                                                    electronically
                                                    transmit a patient
                                                    summary record to
                                                    other providers and
                                                    organizations
                                                    including, at a
                                                    minimum, diagnostic
                                                    test results,
                                                    problem list,
                                                    medication list, and
                                                    medication allergy
                                                    list in accordance
                                                    with:
                                                      (i) The standard
                                                       (and applicable
                                                       implementation
                                                       specifications)
                                                       specified in Sec.
                                                         170.205(a)(1)
                                                       or Sec.
                                                       170.205(a)(2);
                                                       and
                                                      (ii) For the
                                                       following data
                                                       elements the
                                                       applicable
                                                       standard must be
                                                       used:
                                                      (A) Problems. The
                                                       standard
                                                       specified in Sec.
                                                         170.207(a)(1)
                                                       or, at a minimum,
                                                       the version of
                                                       the standard
                                                       specified in Sec.
                                                         170.207(a)(2);
                                                      (B) Laboratory
                                                       test results. At
                                                       a minimum, the
                                                       version of the
                                                       standard
                                                       specified in Sec.
                                                         170.207(c); and

[[Page 44633]]


                                                      (C) Medications.
                                                       The standard
                                                       specified in Sec.
                                                         170.207(d).
------------------------------------------------------------------------

    Comments. A few commenters supported our adoption of the Continuity 
of Care Record (CCR) standard for patient summary records; a couple 
commenters expressed no preference; while many commenters were opposed 
to our adoption of CCR as an alternate standard and did not believe 
that it was an appropriate selection. Several commenters did not 
comment on the merits of adopting CCD and CCR but rather expressed 
general concern that adopting two standards would be wasteful, counter-
productive, confusing, time-consuming, and reduce interoperability. Of 
the commenters that supported the adoption of CCR, most expressed their 
appreciation for the flexibility we had provided. These commenters 
contended that CCR was easier to implement and would make it easier for 
smaller Complete EHR and EHR Module developers to enter the market and 
get certified. One commenter suggested that if we intended to keep both 
CCD and CCR as adopted standards that we specify the transactions for 
which each standard should apply. This commenter recommended that CCD 
be used for exchanging summary records between health care providers 
and that CCR be used for exchanging summary records to PHRs. Of the 
commenters that opposed our selection of CCR, many of them recommended 
that we adopt the CCD standard as the sole standard for summary 
records. These commenters principally referenced that the CCD was a 
harmonization of CDA and CCR. Some commenters stated that we did not 
provide sufficient rationale for adopting CCR and we had reopened a 
debate over the two standards that was purportedly previously settled. 
Some commenters were concerned that CCR could not support certain 
information, particularly, in the hospital setting. These commenters 
contended that CCR could not support discharge information and that CCR 
cannot provide input into clinical decision support due to the lack of 
a common definition of how data is structured. Other commenters 
referenced that CCR is not extensible and questioned its ability to be 
used for quality reporting. Several commenters recommended that, short 
of adopting solely CCD, we provide clearer guidance to the industry 
regarding what standard we expect to adopt for future stages of 
meaningful use because CCD and CCR are not based on a common 
information model.
    Response. We appreciate the constructive comments and 
recommendations provided by commenters. We address our adoption of the 
patient summary record standards in this certification criterion 
because we believe that it is the most applicable place to do so. 
Section 3004(b)(1) of the PHSA requires the Secretary to adopt an 
initial set of standards, implementation specifications, and 
certification criteria. Section 3004(b)(2) of the PHSA provided the 
Secretary with additional flexibility in considering what standards, 
implementation specifications, and certification criteria to adopt in 
the initial set. Section 3004(b)(2) states that ``[t]he standards, 
implementation specifications, and certification criteria adopted 
before the date of the enactment of this title through the process 
existing through the Office of the National Coordinator for Health 
Information Technology may be applied towards meeting the requirement 
of paragraph (1).'' Accordingly, we looked at all of the standards, 
implementation specifications, and certification criteria recognized by 
the Secretary at any point in time prior to the enactment of the HITECH 
Act to determine whether they should be included in this initial set. 
Contrary to some commenters statements, the CCR patient summary record 
standard was in fact recognized by the Secretary in 2008 (73 FR 3976) 
as part of the HITSP Consumer Empowerment Interoperability 
Specification (HITSP V2.1 2007 IS03). We understand that in January, 
2009, the Secretary recognized (74 FR 3604) an updated HITSP IS03 which 
removed the CCR standard. We do not believe that section 3004(b)(2) 
precludes the Secretary from considering all possible standards that 
were part of the ``prior process.'' To the contrary, we believe the 
HITECH Act provided the Secretary with the authority and flexibility to 
determine which standards would be best to include in this initial set. 
Accordingly, we adopted both the CCR and CCD as patient summary record 
standards.
    We adopted both standards for a few reasons. First, we are aware, 
contrary to some commenters' statements, that a significant segment of 
the HIT industry still uses the CCR patient summary record standard and 
that some health care providers prefer the CCR over the CCD. For this 
reason, we did not want to mandate, at such an early stage, that all of 
these early adopters adopt a different summary record standard for the 
purposes of meaningful use Stage 1, given that electronic health 
information exchange is not required. Second, we understand that in 
some circumstances the CCR is easier, faster, and requires fewer 
resources to implement than the CCD. We have therefore concluded that 
it was appropriate to adopt the CCR standard for patient summary 
records in this initial set of standards. Finally, we believe that at 
the present time, each standard could equally be used to satisfy the 
requirements of meaningful use Stage 1.
    Comments. Numerous commenters questioned why we did not adopt the 
HITSP C32 implementation specification for the CCD. These commenters 
requested that we adopt the C32 implementation specification. They 
noted that it had been accepted by the industry, tested and implemented 
in several operating environments, and was supported by multiple EHR 
technology developers. A few commenters requested additional 
clarification regarding our adoption of a ``level 2'' CCD as part of 
this standard and stated that use of a level 2 CCD was inconsistent 
with our adoption of several adopted vocabulary standards. These 
commenters questioned whether we intended to adopt a level 3 CCD. At 
least one commenter recommended the removal of our reference to levels. 
Another commenter stated that problem list, medication list, medication 
allergy list, procedures, etc. are commonly referred to as ``sections'' 
of the CDA or CCD document, not ``fields.'' They stated that sections 
may contain narrative text using the CDA XML format for text, and need 
not contain level 3 entries; however, they believed that in order to 
use the specified clinical vocabularies found in the Interim Final Rule 
in an interoperable fashion, the codes from these selected vocabularies 
must appear in level 3 entries. Some commenters also noted this and 
recommended that we adopt CCD and specify that the standard must be 
implemented in accordance with the HITSP C32 implementation 
specification, using the vocabulary standards we had adopted in the 
Interim Final Rule. One commenter noted that units of measure are 
components of structured entries (CDA

[[Page 44634]]

level 3) in these sections. The commenter supported specified clinical 
vocabularies and level 3 CCD because the commenter felt that level 3 
would be necessary to properly communicate the information.
    Response. We have considered public comments and, in response, have 
made two changes. Both are related to our adoption of the CCD standard. 
In the Interim Final Rule we explicitly included a reference to ``level 
2'' to indicate that we expected a Complete EHR or EHR Module would be 
capable of generating a level 2 CCD. After further consideration, we 
agree that removing ``level 2'' from the adopted standard will help 
clarify the requirements regarding the implementation of CCD. As some 
commenters pointed out, the coded data elements we expect to populate 
the fields of the CCD would necessitate ``level 3'' entries. Thus, we 
have removed the reference to ``level 2.'' We also agree, that the 
HITSP C32 (version 2.5) implementation specification for CCD would be 
appropriate to adopt. We understand that a majority of Complete EHR and 
EHR Module developers who have implemented the CCD standard do so 
according to the HITSP C32 implementation specification, and 
consequently we do not believe that this would be a significant burden. 
We further clarify that, for the purposes of testing and certification, 
a compliant CCD implemented according to the HITSP C32 must include the 
information for those entries ``required'' by the HITSP C32. 
Additionally, we note that as specified by this certification 
criterion, we expect that certain health information for which other 
certification criteria require to be recorded will be used to populate 
certain ``optional'' entries specified by the HITSP C32 implementation 
specification (e.g., problems from a problem list should in most cases 
be available to populate the ``condition content module'' section of 
the HITSP C32). Accordingly, we expect that the test data used to 
evaluate whether a Complete EHR or EHR Module can successfully generate 
a CCD according to the HITSP C32 will include the data specified in the 
certification criterion to populate the ``optional'' entries for which 
we have adopted vocabulary standards (e.g., problems). Moreover, from a 
consistency perspective, we expect that the same test data referenced 
above, which would be used to test and certify a CCD implemented 
according to the HITSP C32 would also be used to test and certify a 
Complete EHR or EHR Module's ability to populate a CCR. This principle 
is also applicable to Complete EHRs and EHR Modules designed for an 
inpatient setting.
    Comment. One commenter noted that although CVX is identified as the 
required standard for interaction with state immunization registries, 
no standard for ``immunizations'' is outlined for the clinical summary. 
They presumed that CVX could be used for this purpose, but stated that 
CVX does not include a dose or date or reaction.
    Response. Consistent with the changes we have made elsewhere in the 
final rule, we have removed ``immunizations'' from this certification 
criterion.
    Comment. A commenter suggested that ONC strike the following from 
the certification criteria ``and upon receipt of a patient summary 
record formatted in an alternate standard specified in Sec.  
170.205(a)(1), display it in human readable format.'' Another commenter 
stated that data transport is not addressed in the standards, and the 
criterion instead refers to ``transmit.'' The commenter suggested 
changing the first part of the criterion to ``display'' instead of 
``receive,'' and the second part of the criterion to ``export'' instead 
of ``transmit.''
    Response. We disagree and have not made these changes. We believe 
that this certification criterion expresses the capabilities we expect 
Certified EHR Technology will include. Furthermore, the action of 
``exporting'' a patient summary record does not indicate or require 
that Certified EHR Technology is actually capable of transmitting a 
patient summary record to Certified EHR Technology implemented by a 
different eligible professional or eligible hospital.
    Comment. A commenter requested clarification on how historical data 
from paper records should be treated for the purpose of certification. 
If historical data is on paper, the standards for display are 
inapplicable.
    Response. Data from paper records would not be a relevant factor 
for the purposes of testing and certification. We are concerned with 
whether Complete EHRs and EHR Modules have implemented specific 
capabilities in compliance with the certification criteria adopted by 
the Secretary.
    Comments. A couple of commenters requested definition of 
``diagnostic test result'' and ``procedures'' in the context of this 
criterion.
    Response. Again, we do not believe that it is appropriate to define 
``diagnostic test result'' in this final rule since the term is derived 
from the Medicare and Medicaid EHR Incentive Programs final rule. 
Consistent with other revisions we have made in the final rule, we have 
removed ``procedures'' from the certification criterion.
    Comment. At least one commenter requested that we clarify what 
Certified EHR Technology needs to be capable of meeting this 
certification criterion. The commenter asked whether the generation of 
a CCD or CCR would constitute compliance with this criterion or would 
the import and human readable display of both document types be 
required.
    Response. We clarify that compliance with this certification 
criterion can be achieved by demonstrating that the Complete EHR or EHR 
Module is capable of receiving and displaying patient summary records 
that comply with either patient summary record standard (and if the 
alternative standard is used, displaying the non-natively implemented 
patient summary record standard in human readable format) and 
generating and transmitting a patient summary record according to one 
of the patient summary record standards populated with the specified 
data types and their applicable standard(s). For example, a Complete 
EHR designed to generate patient summary records in the CCD standard 
would need to be capable of generating and transmitting patient summary 
records in accordance with CCD. Upon receipt of a patient summary 
record formatted according to the CCR standard, the Complete EHR must 
also be capable of displaying the CCR-formatted patient summary record 
in human readable format. We clarify that we also expect that the 
Complete EHR designed to natively generate a CCD would be tested and 
certified as being capable of properly displaying any CCD that it 
receives and have added the term ``display'' in the beginning of the 
certification criterion. This change is also applicable to the 
certification criterion for Complete EHRs and EHR Modules designed for 
an inpatient setting.
    Comment. A commenter requested that we clarify how we intended 
adopted vocabularies to be used. The commenter queried whether 
vocabulary standards that we had adopted apply to EHRs or to 
transactions that EHRs conduct. The commenter further requested that we 
clarify whether a local/proprietary medication vocabulary could be 
mapped to RxNorm, and whether a local/proprietary problem list 
vocabulary could be mapped to SNOMED-CT[supreg]. Finally, the commenter 
asked if mapping is permitted, and if so, requested that we identify 
the subsets of these vocabularies that should be used.

[[Page 44635]]

    Response. For purposes of electronically exchanging a patient 
summary record, we expect the patient summary record to include health 
information that is coded, where applicable, in accordance with adopted 
vocabulary standards. Therefore, unless otherwise required in the 
context of a meaningful use objective and measure, an eligible 
professional (or eligible hospital) would be permitted to map or 
crosswalk local/proprietary codes to the adopted vocabulary standards 
prior to transmitting a patient summary record. We do not believe that 
it would be appropriate to specify subsets of adopted vocabularies at 
this time and would seek additional input from the HIT Standards 
Committee or public comment prior to specifying vocabulary subsets.
    Comment. A commenter stated that the adopted data exchange 
standards do not provide for the inclusion of narrative text results, 
such as a radiology report, or images of scanned paper documents. The 
commenter questions how meaningful use objectives will be achieved 
without these and recommends that implementation guidance be issued 
that includes specific references to content or vocabulary standards.
    Response. We have not adopted standards for radiology reports or 
images; however, both the CCR and CCD can be used to convey narrative 
text and objects such as scanned documents.
    Comments. A couple of commenters requested clarification as to the 
testing we expected to occur related to a Complete EHR or EHR Module's 
compliance with this certification criterion. These commenters 
questioned whether the generation of a CCD and XDS (HITSP/TP13)/FTP/e-
mail of a document would meet the certification criterion requirements.
    Response. We clarify that because we have removed the adopted 
transport standards, we do not require as a condition of certification 
that a specific transport standard be used to transmit a generated CCD.
    Comments. One commenter expressly agreed with the expectations of 
the certification criterion. Another commenter stated that this 
functionality is crucial to support the patient/family-centered medical 
home. One commenter recommended that the Certified EHR Technology be 
designed so that the amount of data transmitted could be adjusted by 
physicians so they do not violate the HIPAA Privacy Rule's ``minimum 
necessary'' requirements.
    Response. We appreciate commenters' support for this certification 
criterion and agree that patient summary records serve a valuable 
purpose. Presently, we do not believe that it is appropriate to require 
as a condition of certification a capability associated with the HIPAA 
Privacy Rule's minimum necessary requirements because such requirements 
are generally context specific and determined when a HIPAA covered 
entity uses or discloses protected health information or when a HIPAA 
covered entity requests protected health information from another HIPAA 
covered entity. We do not preclude, however, Complete EHR and EHR 
Module developers from including additional features to assist HIPAA 
covered entities comply with these and other HIPAA Privacy Rule 
requirements.
    Comment. A commenter recommended that the summary care record 
should include the durable medical equipment and supplies used by the 
patient.
    Response. Presently, the correlated meaningful use objective and 
measure do not specify that a patient summary record must contain 
information regarding durable medical equipment. Accordingly, we do not 
believe that it would be appropriate to require this as a condition of 
certification.
c. Specific Certification for Complete EHRs or EHR Modules Designed for 
an Inpatient Setting--Sec.  170.306
Section 170.306(a)--Computerized Provider Order Entry

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Use CPOE for medication orders  More than 30% of   Interim Final Rule
 directly entered by any         unique patients    Text:
 licensed healthcare             with at least     Enable a user to
 professional who can enter      one medication     electronically
 orders into the medical         in their           record, store,
 record per state, local and     medication list    retrieve, and
 professional guidelines.        seen by the EP     manage, at a
                                 or admitted to     minimum, the
                                 the eligible       following order
                                 hospital's or      types:
                                 CAH's inpatient   (1) Medications;
                                 or emergency      (2) Laboratory;
                                 department (POS   (3) Radiology/
                                 21 or 23) have     imaging;
                                 at least one      (4) Blood bank;
                                 medication order  (5) Physical therapy;
                                 entered using     (6) Occupational
                                 CPOE.              therapy;
                                                   (7) Respiratory
                                                    therapy;
                                                   (8) Rehabilitation
                                                    therapy;
                                                   (9) Dialysis;
                                                   (10) Provider
                                                    consults; and
                                                   (11) Discharge and
                                                    transfer.
                                                   Final Rule Text: Sec.
                                                      170.306(a).
                                                   Computerized provider
                                                    order entry. Enable
                                                    a user to
                                                    electronically
                                                    record, store,
                                                    retrieve, and
                                                    modify, at a
                                                    minimum, the
                                                    following order
                                                    types:
                                                      (1) Medications;
                                                   (2) Laboratory; and
                                                   (3) Radiology/
                                                    imaging.
------------------------------------------------------------------------

    A commenter recommended that we clarify what is meant by order 
entry because the commenter believes that within the confines of many 
hospitals, just about any ``order'' can be performed. A few commenters 
requested that ``diet orders'' be added to the list of CPOE order types 
in order to prevent inconsistent patient care. Another commenter 
recommended that speech-language pathology and audiology also be added. 
Two commenters noted that the certification criterion specifies a long 
list of order types. The commenters recommended that we not attempt to 
create an exhaustive list. One of the commenters also noted that no 
information is given as to what constitutes adequate functionality for 
any of the orders after the first three order types and that some, such 
as ``dialysis'' may not be appropriate order functionality for a 
general EHR system for hospitals. Both commenters

[[Page 44636]]

recommended that we remove all orders from four through 10 and replace 
them with a single provision ``other order types.''
    Response. Consistent with the revisions we made to the CPOE 
certification criterion associated with Complete EHRs and EHR Modules 
designed for an ambulatory setting, we agree with those commenters who 
recommended that we specify a minimum core set of orders as a condition 
of certification. Accordingly, we identify medication, laboratory, and 
radiology/imaging as the minimum types of orders a Complete EHR or EHR 
Module designed for inpatient settings must include in order to be 
certified. While this certification criterion is now the same as the 
certification criterion for Complete EHRs and EHR Modules designed for 
an ambulatory setting, we have not combined and moved the CPOE 
certification criteria to the general certification criteria section. 
Rather, we have kept the certification criteria for CPOE separate 
because we anticipate that these certification criteria could in the 
future include different requirements, specific to the settings for 
which Complete EHRs and EHR Modules are developed.
    Comment. A commenter repeated a question it raised with respect to 
CPOE for eligible professionals. The commenter requested that we 
clarify whether only imaging and radiology reports were intended to be 
included in this capability, or, if we intended to include the images 
themselves in addition to the imaging reports as part of the 
certification criteria. The commenter recommended that we further 
clarify the criterion and requested that the DICOM standard be adopted 
in the initial set of standards, as an essential step in meeting the 
CPOE capability.
    Response. We refer this commenter to our previous response above 
regarding this issue.
Section 170.306(b)--Record Demographics

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Record demographics...........  More than 50% of   Interim Final Rule
 preferred language...   all unique         Text:
 gender...............   patients seen by  Enable a user to
 race.................   the EP or          electronically
 ethnicity............   admitted to the    record, modify, and
 date of birth........   eligible           retrieve patient
 date and preliminary    hospital's or      demographic data
 cause of death in the event     CAH's inpatient    including preferred
 of mortality in the eligible    or emergency       language, insurance
 hospital or CAH.                department (POS    type, gender, race,
                                 21 or 23) have     ethnicity, date of
                                 demographics       birth, and date and
                                 recorded as        cause of death in
                                 structured data.   the event of
                                                    mortality.
                                                   Final Rule Text: Sec.
                                                      170.306(b).
                                                   Record demographics.
                                                    Enable a user to
                                                    electronically
                                                    record, modify, and
                                                    retrieve patient
                                                    demographic data
                                                    including preferred
                                                    language, gender,
                                                    race, ethnicity,
                                                    date of birth, and
                                                    date and preliminary
                                                    cause of death in
                                                    the event of
                                                    mortality. Enable
                                                    race and ethnicity
                                                    to be recorded in
                                                    accordance with the
                                                    standard specified
                                                    at Sec.
                                                    170.207(f).
------------------------------------------------------------------------

    Many commenters expressed the same comments with respect to this 
certification criterion as they did for the record demographics 
certification criterion for Complete EHRs and EHR Modules designed for 
ambulatory setting. These commenters recommended the addition of other 
demographic information for additional clarity, as discussed above.
    Comment. A commenter stated that an EHR is not an appropriate 
source of legal documentation for births and deaths because they 
indicated that it is not possible to obtain official birth and death 
certificates from a provider or hospital.
    Response. In concert with and following the changes made to this 
meaningful use objective which are explained in more detail in the 
Medicare and Medicaid EHR Incentive Programs final rule, we believe 
that the changes we have made to this specific part of the 
certification criterion address this commenter's concern.
Section 170.306(c)--Clinical Decision Support

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Implement one clinical          Implement one      Interim Final Rule
 decision support rule related   clinical           Text:
 to a high priority hospital     decision support  (1) Implement rules.
 condition along with the        rule.              Implement automated,
 ability to track compliance                        electronic clinical
 with that rule.                                    decision support
                                                    rules (in addition
                                                    to drug-drug and
                                                    drug-allergy
                                                    contraindication
                                                    checking) according
                                                    to a high priority
                                                    hospital condition
                                                    that use demographic
                                                    data, specific
                                                    patient diagnoses,
                                                    conditions,
                                                    diagnostic test
                                                    results and/or
                                                    patient medication
                                                    list.
                                                   (2) Alerts.
                                                    Automatically and
                                                    electronically
                                                    generate and
                                                    indicate in real-
                                                    time, alerts and
                                                    care suggestions
                                                    based upon clinical
                                                    decision support
                                                    rules and evidence
                                                    grade.
                                                      (3) Alert
                                                       statistics.
                                                       Automatically and
                                                       electronically
                                                       track, record,
                                                       and generate
                                                       reports on the
                                                       number of alerts
                                                       responded to by a
                                                       user.
                                                   Final Rule Text: Sec.
                                                      170.306(c).
                                                      (1) Implement
                                                       rules. Implement
                                                       automated,
                                                       electronic
                                                       clinical decision
                                                       support rules (in
                                                       addition to drug-
                                                       drug and drug-
                                                       allergy
                                                       contraindication
                                                       checking) based
                                                       on the data
                                                       elements included
                                                       in: problem list;
                                                       medication list;
                                                       demographics; and
                                                       laboratory test
                                                       results.
                                                      (2) Notifications.
                                                       Automatically and
                                                       electronically
                                                       generate and
                                                       indicate in real-
                                                       time,
                                                       notifications and
                                                       care suggestions
                                                       based upon
                                                       clinical decision
                                                       support rules.
------------------------------------------------------------------------


[[Page 44637]]

    This certification criterion is now exactly the same as the 
certification criterion applicable to Complete EHRs and EHR Modules 
designed for an ambulatory setting. As a result, our responses and 
subsequent changes to the certification criterion above are also 
applicable to this certification criterion. While this certification 
criterion is now the same as the certification criterion for Complete 
EHRs and EHR Modules designed for an ambulatory setting, we have not 
combined and moved the clinical decision support certification criteria 
to the general certification criteria section because the focus of the 
meaningful use objective is different and specific to eligible 
hospitals. We also believe that it is useful to keep these 
certification criteria separate because we anticipate that these 
certification criteria could in the future include different 
requirements, specific to the settings for which Complete EHRs and EHR 
Modules are developed.
    Comments. Some commenters requested that we clarify the meaning of 
high priority hospital condition.
    Response. We have removed this term, consistent with the other 
revisions we made to this certification criterion.
Section 170.306(d)--Electronic Copy of Health Information

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Provide patients with an        More than 50% of   Interim Final Rule
 electronic copy of their        all patients of    Text:
 health information (including   the EP or the     Enable a user to
 diagnostic test results,        inpatient or       create an electronic
 problem list, medication        emergency          copy of a patient's
 lists, medication allergies,    departments of     clinical
 discharge summary,              the eligible       information,
 procedures), upon request.      hospital or CAH    including, at a
                                 (POS 21 or 23)     minimum, diagnostic
                                 who request an     test results,
                                 electronic copy    problem list,
                                 of their health    medication list,
                                 information are    medication allergy
                                 provided it        list, immunizations,
                                 within 3           procedures, and
                                 business days.     discharge summary
                                                    in:
                                                   (1) Human readable
                                                    format; and
                                                   (2) On electronic
                                                    media or through
                                                    some other
                                                    electronic means in
                                                    accordance with:
                                                   (i) One of the
                                                    standards specified
                                                    in Sec.
                                                    170.205(a)(1);
                                                   (ii) The standard
                                                    specified in Sec.
                                                    170.205(a)(2)(i)(A),
                                                    or, at a minimum,
                                                    the version of the
                                                    standard specified
                                                    in Sec.
                                                    170.205(a)(2)(i)(B);
                                                   (iii) One of the
                                                    standards specified
                                                    in Sec.
                                                    170.205(a)(2)(ii);
                                                   (iv) At a minimum,
                                                    the version of the
                                                    standard specified
                                                    in Sec.
                                                    170.205(a)(2)(iii);
                                                    and
                                                   (v) The standard
                                                    specified in Sec.
                                                    170.205(a)(2)(iv).
                                                   Final Rule Text: Sec.
                                                      170.306(d).
                                                   (1) Enable a user to
                                                    create an electronic
                                                    copy of a patient's
                                                    clinical
                                                    information,
                                                    including, at a
                                                    minimum, diagnostic
                                                    test results,
                                                    problem list,
                                                    medication list,
                                                    medication allergy
                                                    list, and
                                                    procedures:
                                                   (i) In human readable
                                                    format; and
                                                   (ii) On electronic
                                                    media or through
                                                    some other
                                                    electronic means in
                                                    accordance with:
                                                   (A) The standard (and
                                                    applicable
                                                    implementation
                                                    specifications)
                                                    specified in Sec.
                                                    170.205(a)(1) or
                                                    Sec.
                                                    170.205(a)(2); and
                                                   (B) For the following
                                                    data elements the
                                                    applicable standard
                                                    must be used:
                                                   (1) Problems. The
                                                    standard specified
                                                    in Sec.
                                                    170.207(a)(1) or, at
                                                    a minimum, the
                                                    version of the
                                                    standard specified
                                                    in Sec.
                                                    170.207(a)(2);
                                                   (2) Procedures. The
                                                    standard specified
                                                    in Sec.
                                                    170.207(b)(1) or
                                                    Sec.
                                                    170.207(b)(2);
                                                   (3) Laboratory test
                                                    results. At a
                                                    minimum, the version
                                                    of the standard
                                                    specified in Sec.
                                                    170.207(c); and
                                                   (4) Medications. The
                                                    standard specified
                                                    in Sec.
                                                    170.207(d).
                                                   (2) Enable a user to
                                                    create an electronic
                                                    copy of a patient's
                                                    discharge summary in
                                                    human readable
                                                    format and on
                                                    electronic media or
                                                    through some other
                                                    electronic means.
------------------------------------------------------------------------

    Comment. A commenter expressed concern that requiring organizations 
to provide anything on electronic media was dangerous and 
counterproductive to the HITECH Act's HIPAA Privacy and Security Rule 
changes. This commenter also stated that thumb drives and CD/DVD 
burners are not available to staff. The commenter recommended that we 
remove this certification criterion and adopt a patient portal 
requirement in the next round of rulemaking.
    Response. While we understand that in certain locations (e.g., 
areas that are readily accessible to patients) health care 
professionals do not normally have access to use certain ancillary 
features at their workstations, we disagree that requiring 
organizations to provide patients with an electronic copy presents 
problems related to HITECH modifications to the HIPAA privacy and 
security requirements. We do not specify that electronic media such as 
thumb drives or CDs must be used. An eligible hospital will be able to 
determine, consistent with its security posture, if certain electronic 
media is permissible and if so, what types. It will also be able to 
determine the means and location through which an electronic copy may 
be provided, e.g., at the records management department or office. As 
the commenter suggested, a patient portal would be an acceptable 
mechanism to provide an electronic copy.
    Comment. A commenter stated the certification criterion for 
eligible hospitals should be limited to information or tests performed 
during the course of a patient visit or hospital stay and include only 
summary information of diagnostic test results or of information that 
is clinically significant and discovered during the encounter or 
admission. Other commenters requested that we clarify

[[Page 44638]]

the reference to procedures. The commenters asked that the regulations 
specify whether the EHR technology must enable the user to create an 
electronic copy of procedures associated with the most recent 
hospitalization, or any historical procedures, or the procedures that 
the patient should follow-up to do after discharge.
    Response. At a minimum, Certified EHR Technology must be capable of 
generating an electronic copy of health information that includes the 
elements specified by the certification criterion in an electronic 
copy. We do not specify the time period for which the electronic copy 
must cover as a condition of certification.
    Comment. A commenter requested that we consider eliminating the 
reference to standards in this certification criterion for Stage 1 and 
focusing on human readable formats.
    Response. We disagree, as doing so would run counter to our long 
term goals and would not help build the foundation necessary for more 
comprehensive capabilities to be added in the future.
    Comments. A few commenters noted that neither the CCD nor CCR 
contain an applicable section for discharge summary. One commenter 
recommended that because the provision of an electronic copy of 
discharge instructions was required by another certification criterion, 
that discharge instructions should be removed as an element in this 
electronic copy.
    Response. We reviewed commenters' concerns and agree that there is 
no applicable section for a discharge summary. Therefore, we have 
revised this certification criterion to reflect that while the other 
data elements can be conveyed using the patient summary record 
standards (CCR or CCD), we are not requiring the use of any standards 
for the discharge summary section. In order to support the meaningful 
use objective and measure, however, we note that we do expect Certified 
EHR Technology to be capable of providing a electronic copy of a 
discharge summary like a patient summary record, in human readable 
format and on electronic media or through some other electronic means. 
Other electronic means could include, for example, the discharge 
summary represented as a CCD plus the ``Hospital Course'' CDA section 
or provided as a PDF. We have revised the certification criterion 
accordingly.
    We note that our responses to the following comments also apply to 
other certification criteria that reference procedures.
    Comments. A commenter requested clarification as to what we meant 
by ``procedures'' for hospitals, because coding for medical procedures 
typically occurs after the patient has been discharged. Another 
commenter requested that we further clarify the subset of relevant 
procedures that should be included. The commenter explained that it 
believed including CPT-4 or ICD-9 codes seemed inappropriate for 
clinical summaries since these codes are used for ``procedures as 
billed,'' and the commenter further asked whether we intended to 
include only major procedures.
    Response. We clarify that the adopted standard pertains to the 
vocabulary that would be used to express procedures, regardless of how 
they are selected, or included.
    Comments. A commenter stated that with an X12 837 standard 
transaction, ICD-9-CM is accompanied by a flag that indicates whether 
this code is being used to bill for services meant to eliminate a 
diagnosis. The commenter stated that neither the CCR nor the CCD 
support such a flag, and concluded that there was no way to know 
whether ICD-9-CM codes used in either CCD or CCR could accurately 
convey a patient's problems. The commenter also recommended SNOMED-
CT[supreg] should be used with a CCD, because ICD-9 codes have too 
little clinical detail. Another commenter favored the use of SNOMED-
CT[supreg] as well and stated that SNOMED-CT[supreg] would be more 
clinically accurate and better suited for our purposes. Another 
commenter encouraged us to adopt the Current Dental Terminology.
    Response. The diagnoses included within the patient summary record 
are meant to convey clinically relevant conditions as recorded in 
Certified EHR Technology's problem list, rather than billing diagnoses. 
While we agree that SNOMED-CT[supreg] provides additional clinical 
detail, this is often not available in current practice. Furthermore, 
while its use is not precluded, we do not believe that it is necessary 
to adopt the Current Dental Terminology as a condition of certification 
for all Complete EHRs and EHR Modules.
    Comments. A commenter recommended against the adoption of the 
alternative standard (CPT-4), unless we subsidized the cost of 
licensing CPT-4 as has been done for certain other code sets. Some 
commenters expressed concerns about the license requirements and one 
commenter stated that the license cost will likely be passed down from 
the EHR developer to the eligible professional or eligible hospital. 
Some commenters believed that if we intended to keep this alternative 
standard, we should make it freely available.
    Response. We understand that most current EHR technology already 
includes the CPT-4 code sets, and we believe that this indicates that 
the licensing costs are not prohibitive. Regardless, we have adopted an 
alternative standard to CPT-4, SNOMED-CT[supreg], which is freely 
available.
    Comment. A commenter noted that the certification criterion 
references immunizations but the Medicare and Medicaid EHR Incentive 
Programs proposed rule did not include immunizations in the objective. 
The commenter suggested that we modify our certification criterion to 
match the proposed rule.
    Response. We have removed this term, consistent with the previous 
revisions we have made to other certification criteria above.
Section 170.306(e)--Electronic Copy of Discharge Information

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Provide patients with an        More than 50% of   Interim Final Rule
 electronic copy of their        all patients who   Text:
 discharge instructions at       are discharged    Enable a user to
 time of discharge, upon         from an eligible   create an electronic
 request.                        hospital or        copy of the
                                 CAH's inpatient    discharge
                                 department or      instructions and
                                 emergency          procedures for a
                                 department (POS    patient, in human
                                 21 or 23) and      readable format, at
                                 who request an     the time of
                                 electronic copy    discharge on
                                 of their           electronic media or
                                 discharge          through some other
                                 instructions are   electronic means.
                                 provided it.      Final Rule Text: Sec.
                                                      170.306(e).
                                                   Electronic copy of
                                                    discharge
                                                    instructions. Enable
                                                    a user to create an
                                                    electronic copy of
                                                    the discharge
                                                    instructions for a
                                                    patient, in human
                                                    readable format, at
                                                    the time of
                                                    discharge on
                                                    electronic media or
                                                    through some other
                                                    electronic means.
------------------------------------------------------------------------


[[Page 44639]]

    Comment. A few commenters expressed support for this certification 
criterion. Some commenters requested that we clarify the meaning of 
``procedures'' in the context of this certification criterion.
    Response. We have revised this certification criterion to be 
consistent with the changes to the meaningful use objective and measure 
in the Medicare and Medicaid EHR Incentive Programs final rule, which 
removes the word ``procedures'' from the meaningful use objective.
    Comment. A commenter requested that we clarify the meaning of the 
phrase ``at time of discharge'' and specifically, whether it means 
literally at the time when a patient is discharged or more broadly, 
soon after the discharge occurs, in which case the instructions could 
be made available to the patient, for example, through a web portal.
    Response. This phrase is derived from the Medicare and Medicaid EHR 
Incentive Programs final rule, and CMS has provided clarifying remarks 
related to this comment.
    Comment. One commenter recommended that the certification criterion 
include consideration of the patient's preferred language.
    Response. Like our prior responses, we do not believe that 
requiring this information is appropriate or necessary to include as a 
condition of certification. However, we do not preclude Complete EHRs 
and EHR Modules from being designed to reference a patient's preferred 
language.
Section 170.306(f)--Exchange Clinical Information and Summary Record

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
          objectives             Stage 1 measures        criterion
------------------------------------------------------------------------
Capability to exchange key      Performed at       Interim Final Rule
 clinical information (for       least one test     Text:
 example, discharge summary,     of certified EHR  (1) Electronically
 procedures, problem list,       technology's       receive and display.
 medication list, medication     capacity to        Electronically
 allergies, diagnostic test      electronically     receive a patient's
 results), among providers of    exchange key       summary record from
 care and patient authorized     clinical           other providers and
 entities electronically.        information.       organizations
                                                    including, at a
                                                    minimum, diagnostic
                                                    test results,
                                                    problem list,
                                                    medication list,
                                                    medication allergy
                                                    list, immunizations,
                                                    procedures, and
                                                    discharge summary in
                                                    accordance with Sec.
                                                      170.205(a) and
                                                    upon receipt of a
                                                    patient summary
                                                    record formatted in
                                                    an alternate
                                                    standard specified
                                                    in Sec.
                                                    170.205(a)(1),
                                                    display it in human
                                                    readable format.
                                                   (2) Electronically
                                                    transmit. Enable a
                                                    user to
                                                    electronically
                                                    transmit a patient's
                                                    summary record to
                                                    other providers and
                                                    organizations
                                                    including, at a
                                                    minimum, diagnostic
                                                    results, problem
                                                    list, medication
                                                    list, medication
                                                    allergy list,
                                                    immunizations,
                                                    procedures, and
                                                    discharge summary in
                                                    accordance with:
                                                      (i) One of the
                                                       standards
                                                       specified in Sec.
                                                         170.205(a)(1);
The EP, eligible hospital or    The EP, eligible      (ii) The standard
 CAH who transitions their       hospital or CAH       specified in Sec.
 patient to another setting of   who transitions
 care or provider of care or     or refers their       170.205(a)(2)(i)(
 refers their patient to         patient to            A), or, at a
 another provider of care        another setting       minimum, the
 should provide summary of       of care or            version of the
 care record for each            provider of care      standard
 transition of care or           provides a            specified in Sec.
 referral.                       summary of care
                                 record for more       170.205(a)(2)(i)(
                                 than 50% of           B);
                                 transitions of
                                 care and
                                 referrals.
                                                      (iii) One of the
                                                       standards
                                                       specified in Sec.

                                                       170.205(a)(2)(ii)
                                                       ;
                                                      (iv) At a minimum,
                                                       the version of
                                                       the standard
                                                       specified in Sec.

                                                       170.205(a)(2)(iii
                                                       ); and
                                                      (v) The standard
                                                       specified in Sec.

                                                       170.205(a)(2)(iv)
                                                       .
                                                   Final Rule Text: Sec.
                                                      170.306(f).
                                                   (1) Electronically
                                                    receive and display.
                                                    Electronically
                                                    receive and display
                                                    a patient's summary
                                                    record from other
                                                    providers and
                                                    organizations
                                                    including, at a
                                                    minimum, diagnostic
                                                    test results,
                                                    problem list,
                                                    medication list,
                                                    medication allergy
                                                    list, and procedures
                                                    in accordance with
                                                    the standard (and
                                                    applicable
                                                    implementation
                                                    specifications)
                                                    specified in Sec.
                                                    170.205(a)(1) or
                                                    Sec.
                                                    170.205(a)(2). Upon
                                                    receipt of a patient
                                                    summary record
                                                    formatted according
                                                    to the alternative
                                                    standard, display it
                                                    in human readable
                                                    format.
                                                   (2) Electronically
                                                    transmit. Enable a
                                                    user to
                                                    electronically
                                                    transmit a patient's
                                                    summary record to
                                                    other providers and
                                                    organizations
                                                    including, at a
                                                    minimum, diagnostic
                                                    results, problem
                                                    list, medication
                                                    list, medication
                                                    allergy list, and
                                                    procedures in
                                                    accordance with:
                                                      (i) The standard
                                                       (and applicable
                                                       implementation
                                                       specifications)
                                                       specified in Sec.
                                                         170.205(a)(1)
                                                       or Sec.
                                                       170.205(a)(2);
                                                       and
                                                      (ii) For the
                                                       following data
                                                       elements the
                                                       applicable
                                                       standard must be
                                                       used:
                                                      (A) Problems. The
                                                       standard
                                                       specified in Sec.
                                                         170.207(a)(1)
                                                       or, at a minimum,
                                                       the version of
                                                       the standard
                                                       specified in Sec.
                                                         170.207(a)(2);
                                                      (B) Procedures.
                                                       The standard
                                                       specified in Sec.
                                                         170.207(b)(1)
                                                       or Sec.
                                                       170.207(b)(2);
                                                      (C) Laboratory
                                                       test results. At
                                                       a minimum, the
                                                       version of the
                                                       standard
                                                       specified in Sec.
                                                         170.207(c); and
                                                      (D) Medications.
                                                       The standard
                                                       specified in Sec.
                                                         170.207(d).
------------------------------------------------------------------------


[[Page 44640]]

    Overall this certification criterion is very similar to the 
certification criterion applicable to Complete EHRs and EHR Modules 
designed for an ambulatory setting. As a result, our responses and 
subsequent changes to the certification criterion above are also 
applicable to this certification criterion. Below are the comments that 
are unique to this certification criterion.
    Comment. A few commenters requested clarification on what is meant 
by the term ``discharge summary.'' The commenter stated that neither 
the CCD nor the CCR has a document section or module for a ``discharge 
summary.'' One commenter suggested that we either define the term or 
remove it. At least one commenter suggested that discharge summary be 
initially permitted to be an unstructured CDA instead of requiring the 
use of a CCD. As an alternative, it was suggested that the CCD combined 
with the ``Hospital Course'' CDA section be allowed to qualify as the 
discharge summary.
    Response. As noted in one of our responses above, we recognize that 
neither CCD nor CCR specifically supports the inclusion of discharge 
summary. In the Medicare and Medicaid EHR Incentive Program final rule, 
CMS references discharge summary in the meaningful use objective as an 
example of ``key clinical information'' but further clarifies within 
the preamble of that rule that it is up to an eligible professional or 
eligible hospital to determine what constitutes key clinical 
information. In that regard, CMS notes that we specify the minimum set 
of information that Certified EHR Technology must be capable of 
electronically transmitting. Given our prior statements regarding the 
ability of CCD and CCR to support the inclusion of the discharge 
summary and the principle expressed by CMS that we specify a minimum 
set of information in the adopted certification criterion, we believe 
that in this instance it is appropriate to exclude discharge summary 
from the certification criterion.
Section 170.306(g)--Reportable Lab Results

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Capability to submit            Performed at       Interim Final Rule
 electronic data on reportable   least one test     Text:
 (as required by state or        of certified EHR  Electronically
 local law) lab results to       technology's       record, retrieve,
 public health agencies and      capacity to        and transmit
 actual submission in            provide            reportable clinical
 accordance with applicable      electronic         lab results to
 law and practice.               submission of      public health
                                 reportable lab     agencies in
                                 results to         accordance with the
                                 public health      standard specified
                                 agencies and       in Sec.
                                 follow-up          170.205(f)(1) and,
                                 submission if      at a minimum, the
                                 the test is        version of the
                                 successful         standard specified
                                 (unless none of    in Sec.
                                 the public         170.205(f)(2).
                                 health agencies   Final Rule Text: Sec.
                                 to which             170.306(g).
                                 eligible          Reportable lab
                                 hospital or CAH    results.
                                 submits such       Electronically
                                 information have   record, modify,
                                 the capacity to    retrieve, and submit
                                 receive the        reportable clinical
                                 information        lab results in
                                 electronically).   accordance with the
                                                    standard (and
                                                    applicable
                                                    implementation
                                                    specifications)
                                                    specified in Sec.
                                                    170.205(c) and, at a
                                                    minimum, the version
                                                    of the standard
                                                    specified in Sec.
                                                    170.207(c).
------------------------------------------------------------------------

    Comment. One commenter requested that we clarify the meaning of 
``LOINC when LOINC codes have been received from a laboratory.'' The 
commenter questioned whether the information exchange for which this 
criterion would apply is solely exchange within an organization or only 
between organizations.
    Response. For a more detailed response to this request for 
clarification, we refer to the relevant comments and responses relating 
to the ``incorporate laboratory test results'' certification criterion, 
where we discuss this issue at length.
    Comment. One commenter stated that it believed the standards we 
have adopted are too general or at too high a level for vendors to be 
able to implement them uniformly. This commenter suggested that we 
clarify when lab results should be transmitted, for instance upon the 
occurrence of particular trigger events, or in response to specific 
messages, and in accordance with a reporting time table. The commenter 
queries, for example, if EHR systems should use discharge as a trigger 
for the transmission of a reportable condition using encounter level 
demographic segments, or whether EHR systems should provide a periodic 
batch reporting of reportable conditions (e.g. daily or weekly).
    Response. We clarify that the certification criterion does not 
specify, and is not intended to specify, the requirements for how the 
reports are to be triggered nor the periodicity of the reporting 
requirements. As a certification criterion, it only specifies 
capabilities necessary for certification.
    Comment. A commenter recommended that we clarify the meaning of 
``reportable'' in the certification criterion.
    Response. Each public health jurisdiction maintains its list of 
diseases or conditions that require notification of public health 
authorities by law. The CDC and the Council of State and Territorial 
Epidemiologists also maintain a list of nationally notifiable 
conditions (http://www.cdc.gov/ncphi/disss/nndss/phs/infdis.htm). We 
reiterate, the adoption of this certification criterion is not intended 
to affect applicable Federal or state law concerning public health 
authority notification requirements.
    Comments. Many commenters requested further specification of the 
data format for transmitting information to public health agencies. 
Most of these comments recommended HL7 2.5.1 version, although at least 
one commenter noted that HL7 2.3.1 was still being used by some public 
health agencies. Another commenter suggested that either standard be 
allowed to accommodate for the variation in public health departments' 
ability to receive these reports. Many commenters raised the concern 
that the criterion appears to place the burden of compliance on the 
sender. This problem could be compounded if states and localities adopt 
multiple standards, which would make both compliance and certification 
testing difficult and burdensome. Several commenters raised the concern 
that some public health agencies are not capable of receiving 
electronic data. One commenter suggested removing the language ``or 
applicable state-designated standard format'' and directly specifying 
the format in the final rule. One commenter suggested having the states 
agree upon a standard format. At least one commenter requested 
additional clarity, suggesting that the HL7 message profile types be 
specified: ORU message for public health reporting, ADT for syndromic 
surveillance, and VXU for immunizations. One commenter also requested 
that we clarify whether HL7 V3 constructs would be allowable.
    Response. We agree with the majority of commenters, who requested 
greater specificity for this certification criterion.

[[Page 44641]]

Many of these commenters suggested adopting implementation 
specifications for the adopted standard (HL7 2.5.1). In response to 
those comments, and to more fully support this meaningful use objective 
and measure which specify the submission of laboratory results to 
public health, we have decided to adopt the HL7 Version 2.5.1 
Implementation Guide: Electronic Laboratory Reporting to Public Health, 
Release 1 (US Realm) to further constrain how HL7 2.5.1 is formatted 
for the purposes of submitting laboratory test results to public 
health. With respect to the comment regarding HL7 V3, we do not believe 
that the industry and public health departments are currently able to 
support the HL7 V3 constructs on a widespread basis and are therefore 
not adopting them.
    Comment. One commenter suggested adding the term ``modify'' to the 
certification criterion, while one commenter requested clarification on 
the term ``retrieve.''
    Response. Consistent with the changes we have made to the other 
certification criterion, we have included the word ``modify.''
    Comments. A few commenters suggested the use of SNOMED-CT[supreg] 
and UCUM for reporting.
    Response. We do not believe that the industry and public health 
departments are currently able to support the use of SNOMED-CT[supreg] 
and UCUM for reporting on a widespread basis.
d. Adoption and Realignment of Certification Criteria To Support the 
Final Requirements for Meaningful Use Stage 1.
    In the Interim Final Rule, we noted that the Secretary was adopting 
an initial set of standards, implementation specifications, and 
certification criteria to ``establish the capabilities and related 
standards that certified electronic health record (EHR) technology will 
need to include in order to, at a minimum, support the achievement of 
the proposed meaningful use Stage 1.'' We also noted that the reason we 
routinely referred to eligible professionals and eligible hospitals in 
the Interim Final Rule was ``because we have closely aligned the 
initial set of standards, implementation specifications, and 
certification criteria adopted by this rule to focus on the 
capabilities that Certified EHR Technology must be able to provide in 
order to support the achievement of the proposed criteria for 
meaningful use Stage 1 by eligible professionals and eligible hospitals 
under the Medicare and Medicaid EHR Incentive Programs.'' In this 
regard, and as many commenters acknowledged and expressed in their 
comments, this final rule and the Medicare and Medicaid EHR Incentive 
Program final rule are closely and inextricably linked. Recognizing the 
unique connection between these two rules, some commenters went so far 
as to issue CMS and ONC a single set of comments recommending changes 
to both rules in context. Many other commenters treated both rules as 
almost being one in the same, acknowledging that a change in Medicare 
and Medicaid EHR Incentive Programs final rule would need to be 
reflected in this final rule. Other commenters submitted comments to 
ONC on the Medicare and Medicaid EHR Incentive Programs proposed rule, 
and to CMS on the Interim Final Rule. As we discussed previously, CMS 
and ONC shared these comments between the offices and we included 
within our review all comments that could be reasonably identified as 
comments on the Interim Final Rule.
    The following three certification criteria have been adopted as 
part of the initial set of certification criteria, implementation 
specifications, and standards in order to realign the adopted 
certification criteria with the final meaningful use Stage 1 
requirements and to ensure that Certified EHR Technology will provide 
such capabilities.
Record Advance Directives
    In the Medicare and Medicaid EHR Incentive Programs proposed rule, 
the Department explained that the HIT Policy Committee had recommended 
that eligible hospitals ``record advance directives.'' Due in part to 
the ambiguity of the recommendation, the Department discussed but did 
not include the objective ``Record Advance Directives'' for the reasons 
explained by CMS. In its final rule, however, the Department stated 
that based on comments received as well as resolution of some of the 
ambiguity associated with the measure, CMS was including this objective 
among its meaningful use Stage 1 objectives. The Department noted that 
some commenters reported that having this information available would 
allow eligible hospitals to make decisions that were better aligned 
with the patient's express wishes. The ``record advance directives'' 
certification criterion would ensure that Certified EHR Technology 
enables users to electronically record whether a patient has an advance 
directive, which in turn will help ensure that a patient's wishes are 
known and can be followed.

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Record advance directives for   More than 50% of   Final Rule Text: Sec.
 patients 65 years old or        all unique           170.306(h).
 older.                          patients 65       Advance directives.
                                 years old or       Enable a user to
                                 older admitted     electronically
                                 to the eligible    record whether a
                                 hospital's or      patient has an
                                 CAH's inpatient    advance directive.
                                 department (POS
                                 21) have an
                                 indication of an
                                 advance
                                 directive status
                                 recorded.
------------------------------------------------------------------------

    Comments. The Department received several comments that we should 
include the capability to record advance directives as part of 
meaningful use of Certified EHR Technology and, specifically, that it 
should be a requirement that pertains to eligible hospitals. Other 
commenters reported that having this information available for the 
patient would allow eligible hospitals to make decisions that were 
better aligned with the patient's express wishes. The HIT Policy 
Committee clarified that the purpose of the meaningful use Stage 1 
measure would be to indicate whether a patient has an advanced 
directive. Furthermore, the committee recommended limiting this measure 
to patients 65 and older.
    Response. We agree that the capability for a Complete EHR or EHR 
Module designed for an inpatient setting should be included as a 
condition of certification. Including this certification criterion in 
this final rule will enable eligible hospitals to meet a meaningful use 
objective they would otherwise not have been able to meet. We do not 
believe that the capability we have required will be a significant 
burden for Complete EHR and EHR Module developers and assume that some 
already have this or a similar type of capability already built in.

[[Page 44642]]

Patient-Specific Education Resources
    The Medicare and Medicaid EHR Incentive Programs proposed rule 
discussed but did not include the objective of providing ``access to 
patient specific education resources upon request,'' primarily because 
of the belief that there was a paucity of knowledge resources 
integrated within EHRs that are also widely available. CMS also noted 
that the ability to provide patient education resources in multiple 
languages might be limited. In response to comments, the Medicare and 
Medicaid EHR Incentive Programs final rule included this objective and 
a related measure, finding that the availability of education resources 
linked to EHRs is in fact more widely available than the Department had 
previously indicated in the proposed rule. The Medicare and Medicaid 
EHR Incentive Programs final rule expressly requires that more than 10 
percent of all unique patients seen by the EP or admitted to the 
eligible hospital's or CAH's inpatient or emergency department (POS 21 
or 23) during the EHR reporting period must be provided patient-
specific education resources in order to meet the related meaningful 
use stage 1 objective. To support the achievement of this objective and 
measure, we are therefore adopting as a certification criterion the 
capability of enabling a user to electronically identify and provide 
patient-specific education resources that include particular types of 
data elements.

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
Use certified EHR technology    More than 10% of   Final Rule Text: Sec.
 to identify patient-specific    all unique           170.302(m).
 education resources and         patients seen by  Patient-specific
 provide those resources to      the EP or          education resources.
 the patient if appropriate.     admitted to the    Enable a user to
                                 eligible           electronically
                                 hospital's or      identify and provide
                                 CAH's inpatient    patient-specific
                                 or emergency       education resources
                                 department (POS    according to, at a
                                 21 or 23) are      minimum, the data
                                 provided patient-  elements included in
                                 specific           the patient's:
                                 education          problem list;
                                 resources.         medication list; and
                                                    laboratory test
                                                    results; as well as
                                                    provide such
                                                    resources to the
                                                    patient.
------------------------------------------------------------------------

    Comments. The Department received many comments, including comments 
from both the HIT Policy Committee and MedPAC, that this capability 
should be included among the certification criteria for Certified EHR 
Technology, to enable eligible professionals and eligible hospitals to 
achieve meaningful use. Commenters indicated that the availability of 
education resources that could be linked to EHR technology is widely 
available.
    Response. We agree that this capability should be included as a 
certification criterion for a Complete EHR or EHR Module designed for 
an ambulatory or inpatient setting. Accordingly, we have included this 
certification criterion in the general certification section. We 
clarify that we do not specify how Certified EHR Technology must be 
used to provide such resources to a patient. That is, such resources 
could be printed out, faxed, or e-mailed.
Automated Calculation of Percentage-Based Meaningful Use Measures
    While the Interim Final Rule only expressly provided for the 
calculation of BMI and the calculation and electronic display of 
certain quality measures, the Department's operating assumption in the 
Interim Final Rule was that Certified EHR Technology would provide for 
the automated calculation of meaningful use Stage 1 measures. The 
Medicare and Medicaid EHR Incentive Programs proposed rule for instance 
stated that CMS and ONC had worked together to define certain terms, 
such as numerator and denominator, for the calculation of percentages 
to demonstrate the successful attainment of the meaningful use 
objectives. The Medicare and Medicaid EHR Incentive Programs final rule 
confirmed that ``the ability to calculate the measure is included in 
certified EHR technology.'' To make explicit the Department's operating 
assumption, to confirm some commenters' original understanding, and to 
respond to other commenters' points, we are adopting the following 
certification criterion regarding the automated calculation of 
percentage-based meaningful use measures.

------------------------------------------------------------------------
    Meaningful use Stage 1        Meaningful use       Certification
           objective             Stage 1 measure         criterion
------------------------------------------------------------------------
N/A...........................  N/A..............  Final Rule Text: Sec.
                                                      170.302(n).
                                                      Automated measure
                                                       calculation. For
                                                       each meaningful
                                                       use objective
                                                       with a percentage-
                                                       based measure,
                                                       electronically
                                                       record the
                                                       numerator and
                                                       denominator and
                                                       generate a report
                                                       including the
                                                       numerator,
                                                       denominator, and
                                                       resulting
                                                       percentage
                                                       associated with
                                                       each applicable
                                                       meaningful use
                                                       measure.
------------------------------------------------------------------------

    Comments. The Department received several comments noting that 
Certified EHR Technology should be expressly required, as a condition 
of certification, to automatically calculate the meaningful use 
measures for which eligible professionals and eligible hospitals would 
need to report percentages to CMS or States at the end of an EHR 
reporting period. Some commenters explicitly noted that ONC should 
require the automated calculation of certain measures as a condition of 
certification. Commenters pointed out that this was already a 
certification requirement for clinical quality measures and it would be 
inconsistent not to require automated calculation for the functionality 
measures as part of certification. Many commenters expressed concerns 
about the difficulties of capturing the denominators for the meaningful 
use measures that required percentage calculations. They pointed out 
that the formulas CMS identified for many objectives would require 
providers to conduct labor-intensive counts of paper documents such as 
prescriptions or laboratory results in order to compute the 
denominators of the percentage based measures. Commenters also 
indicated that if Certified EHR Technology did not include this 
capability that it would dramatically increase the burden on potential 
meaningful users to demonstrate meaningful use and could potentially 
serve as a factor in their decision to participate in the Medicare and 
Medicaid EHR incentive programs.

[[Page 44643]]

    Response. We agree with commenters that unless we expressly adopt a 
certification criterion to specify that Certified EHR Technology must 
be capable of performing percentage-based calculations for meaningful 
use measures that it would present a significant burden to eligible 
professionals and eligible hospitals and could deter them from 
participating in the Medicare and Medicaid EHR incentives programs. 
Accordingly, we believe that it is critical to adopt the certification 
criterion specified above. We clarify that Certified EHR Technology 
must be capable of calculating all denominators for those meaningful 
use measures which are percentage-based and for which CMS requires an 
eligible professional or eligible hospital to submit the results at the 
end of an EHR reporting period. (CMS provides a detailed discussion in 
the Medicare and Medicaid EHR Incentive Programs final rule on 
denominators.) We note that as discussed in the Medicare and Medicaid 
EHR Incentive Programs final rule under the heading ``Discussion of the 
Burden Created by the Measures associated with the Stage 1 Meaningful 
Use Objectives,'' an eligible professional or eligible hospital is 
responsible for verifying that the denominator produced by Certified 
EHR Technology is complete. The eligible professional or eligible 
hospital would be expected to know whether data had been incorrectly 
entered into Certified EHR Technology or whether all patient records 
were included in Certified EHR Technology. For Stage 1 meaningful use 
criteria, CMS identifies these measures in the table in its final rule 
with the headings: ``Measures with a Denominator of Unique Patients 
Regardless of Whether the Patient's Records Are Maintained Using 
Certified EHR Technology'' and ``Measures with a Denominator of Based 
on Counting Actions for Patients whose Records are Maintained Using 
Certified EHR Technology.'' We do not require, as a condition of 
certification, that a Complete EHR or EHR Module provide results for 
the meaningful use measures that only require a ``yes/no'' attestation 
since these results should be readily apparent. These measures are also 
identified by CMS in the table in its final rule with the heading 
``Measures Requiring Only a Yes/No Attestation.'' We do not believe 
that adoption of this certification criterion poses a significant 
technical challenge. Rather, we believe that this capability will 
provide Complete EHR and EHR Modules developers with a platform from 
which to innovate and compete regarding, for example, the EHR products' 
ease of use.

E. Additional Comments

    Comments. In response to our request for public comment, several 
commenters recommended that we adopt certification criteria requiring 
technical capabilities to provide greater access for people with 
disabilities. These commenters also pointed to a few standards 
currently being used to assure accessibility, including the Web Content 
Accessibility Guidelines (WCAG 2.0) and the Electronic and Information 
Technology Accessibility Standards. The commenters requested that we 
coordinate more with the disability communities on accessibility and 
usability and how HIT will impact members of this community. The 
commenters requested that we clarify the applicability of accessibility 
standards and that we add technological non-discrimination as a goal to 
guide future standards work.
    Response. We appreciate the thorough and thoughtful comments 
provided related to accessibility. We believe that HIT has the 
potential to provide all persons with more efficient access to their 
health information. In that regard, we solicited public comment on the 
issue of accessibility and certification to garner more information 
about available standards and to begin a path forward that included 
these standards as part of the overall standards adoption process. We 
reiterate what we discussed in the interim final rule when we provided 
the context for our solicitation of public comment on accessibility.

    Nothing required by this interim final rule should be construed 
as affecting existing legal requirements under other Federal laws. 
While the capabilities provided by Certified EHR Technology may 
assist in the compliance with certain legal requirements, they do 
not in any way remove or alter those requirements * * *. As another 
example, in providing patients with access to their online health 
information, it is important to note that the accessibility 
requirements of the Americans with Disabilities Act of 1990 and 
Section 504 of the Rehabilitation Act of 1973 still apply to 
entities covered by these Federal civil rights laws. Additionally, 
Title VI of the Civil Rights Act of 1964 and its implementing 
regulations protect persons from unlawful discrimination on the 
basis of race, color and national origin. Under Title VI and its 
implementing regulations, recipients of Federal financial assistance 
must take reasonable steps to ensure meaningful access to their 
programs, services, and activities by eligible limited English 
proficient persons.

    While we have not yet adopted specific accessibility standards as a 
condition of certification, we believe that the adoption of such 
standards in a future rulemaking would prove beneficial, to enable all 
persons (including health care providers with disabilities) to have 
equitable access to EHR technology and the electronic information it 
generates. In the interim, we encourage Complete EHR and EHR Module 
developers to design their EHR technology with the needs of users of 
assistive technology in mind, and remind eligible professionals and 
eligible hospitals who seek to adopt Certified EHR Technology to review 
and comply with applicable legal obligations regarding accessibility. 
Among the ways of designing certain capabilities with accessibility in 
mind, we would encourage Complete EHR and EHR Module developers to 
consider implementing, for example, the WCAG 2.0 \8\ when providing 
web-oriented content so that it is more accessible to persons with 
disabilities. We expect the HIT Standards Committee to identify 
accessibility-oriented standards \9\ when it issues recommendations 
regarding the standards that the Secretary should adopt in future 
years.
---------------------------------------------------------------------------

    \8\ http://www.w3.org/TR/WCAG20/.
    \9\ As previously mentioned, there are several accessibility 
standards for electronic and information technology currently in 
use. For example, Section 508 of the Rehabilitation Act requires 
Federal agencies to ensure that electronic and information 
technology that they develop, procure, maintain, or use is 
accessible to persons with disabilities and authorizes the 
Architectural and Transportation Barriers Compliance Board (Access 
Board) to promulgate standards setting forth the technical and 
functional performance criteria necessary to implement the 
requirements of Section 508. Information regarding the Electronic 
and Information Technology Standards can be found on the Access 
Board's Web site at http://www.access-board.gov/508.htm.
---------------------------------------------------------------------------

    Comments. Several commenters made recommendations related to 
standards that we could adopt to support future stages of meaningful 
use. Other commenters expressed concerns related to the ``candidate 
Stage 2 standards'' that we referenced in the Interim Final Rule. 
Finally, commenters requested that Certified EHR Technology include 
specific capabilities that had no relationship to meaningful use.
    Response. We have reviewed these comments and appreciate the 
forethought provided by commenters. Given that these suggestions were 
not germane to the policies associated with the Interim Final Rule we 
have not considered them for the purposes of promulgating this final 
rule.

F. Comments Beyond the Scope of This Final Rule

    In response to the Interim Final Rule, some commenters chose to 
raise issues that are beyond the scope of our

[[Page 44644]]

proposals. We do not summarize or respond to those comments in this 
final rule.

IV. Collection of Information Requirements

    This final rule contains no new information collection requirements 
subject to review by the OMB under the Paperwork Reduction Act (PRA).

V. Regulatory Impact Analysis

A. Introduction

    We have examined the impacts of this final rule as required by 
Executive Order 12866 on Regulatory Planning and Review (September 30, 
1993, as further amended), the Regulatory Flexibility Act (RFA) (5 
U.S.C. 601 et seq.), section 202 of the Unfunded Mandates Reform Act of 
1995 (2 U.S.C. 1532) (UMRA), Executive Order 13132 on Federalism 
(August 4, 1999), and the Congressional Review Act (5 U.S.C. 804(2)).
    Executive Order 12866 directs 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 one year). We have 
determined that this final rule is not an economically significant rule 
because we estimate that the costs to prepare Complete EHRs and EHR 
Modules to be tested and certified will be less than $100 million per 
year. Nevertheless, because of the public interest in this final rule, 
we have prepared an RIA that to the best of our ability presents the 
costs and benefits of the final rule.
    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. For more information on Small Business 
Administration's (SBA's) size standards, see the SBA's Web site.\10\ We 
examine the burden of the final regulation in Section V.D below.
---------------------------------------------------------------------------

    \10\  http://sba.gov/idc/groups/public/documents/sba_homepage/
serv_sstd_tablepdf.pdf.
---------------------------------------------------------------------------

    Section 202 of the UMRA also requires that agencies assess 
anticipated costs and benefits before issuing any rule whose mandates 
require spending in any one year of $100 million in 1995 dollars, 
updated annually for inflation. In 2010, that threshold is 
approximately $135 million. This rule will not impose an unfunded 
mandate on States, tribal government or the private sector of more than 
$135 million annually.
    Executive Order 13132 establishes certain requirements that an 
agency must meet when it promulgates a proposed rule (and subsequent 
final rule) that imposes substantial direct costs of compliance on 
State and local governments, preempts State law, or otherwise has 
Federalism implications. We do not believe that the final rule imposes 
substantial direct compliance costs on State and local governments, 
preempts State law, or otherwise has Federalism implications.

B. Why is this rule needed?

    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 Secretary published in 
the Federal Register an interim final rule to adopt the initial set of 
standards, implementation specifications, and certification criteria. 
This final rule has been published to amend previously adopted 
standards, implementation specifications, and certification criteria in 
order to realign such standards, implementation specifications, and 
certification criteria with final meaningful use Stage 1 objectives and 
measures, and to respond to public comments received. Certification 
criteria and associated standards and implementation specifications 
will be used to test and certify Complete EHRs and EHR Modules in order 
to make it possible for eligible professionals and eligible hospitals 
to adopt and implement Certified EHR Technology. The use of Certified 
EHR Technology is one of the requirements an eligible professional or 
eligible hospital needs to meet in order to qualify for an incentive 
payment under the Medicare and Medicaid EHR Incentive Programs.

C. Executive Order 12866--Regulatory Planning and Review Analysis

1. Comment and Response
    Comments. A few commenters offered opinions related to the cost 
estimates included in the Interim Final Rule. One commenter disagreed 
with our approach. This commenter contended that our analysis followed 
a simplistic, linear model that did not account for the other potential 
costs that Complete EHR and EHR Module developers and health care 
providers would bear. The commenter suggested that we address other 
costs in our calculations including: whether a Complete EHR or EHR 
Module developer has adequate resources available to modify its HIT in 
order to prepare for certification; the loss of a Complete EHR or EHR 
Module developer's net worth and dislocation of jobs if it fails and 
goes out of business; and the resulting impacts that would occur if a 
Complete EHR and EHR Module developer went out of business and left 
behind customers (some or many of which could then be ineligible for 
Medicare and Medicaid EHR Incentive Programs) with unsupported HIT. 
Another commenter questioned the cost estimates in the Interim Final 
Rule, but acknowledged that it was not prepared to offer alternative 
cost estimates. The commenter did state that it believed our dollar 
values seemed low and that the gap of 25%, representing previously 
CCHIT-certified-EHRs that will need additional preparation to be tested 
and certified to the certification criteria adopted by the Secretary, 
also seemed low. The commenter suggested a 40-50% gap. The commenter 
also recommended that we revise our cost estimates based on the 
certification criteria in the final rule to: consider costs associated 
with workflow redesign within an eligible professional or eligible 
hospitals environment; factor in the costs for ``interoperability 
implementation'' (no further explanation was provided); account for the 
costs associated with implementing the clinical quality measures 
certification criterion; account for the costs for hardware capable of 
supporting the adopted security requirements; and factor in the costs 
for internal resources and customer resources. One commenter noted that 
the cost related to dentistry EHR technology may be higher due to what 
it perceived as a lack of commercially available EHR technology and 
that additional costs may be incurred by dentistry EHR developers that 
are not as familiar as EHR developers for other health providers with 
the certification criteria adopted by the Secretary. One commenter 
agreed with the $10,000 to $250,000 cost range we estimated for the 
per-certification-criterion preparation, while another commenter seemed 
to misinterpret this estimate as being the total cost to prepare a 
Complete EHR or EHR Module. This commenter offered that it could take 
over 2,500 hours to prepare a Complete EHR for certification. One 
commenter appeared to associate the costs related to the preparation of 
a Complete EHR to be tested and certified with the actual cost to be 
tested and certified, but nonetheless expressed concern that we had 
estimated that it would cost a Complete EHR developer whose EHR 
technology had not previously been certified no less than

[[Page 44645]]

$1.2 million to become compliant with the Interim Final Rule's 
requirements. The commenter requested that HHS provide assistance to 
EHR vendors with revenues of less than $1 million in order to help 
offset the costs of the certification process.
    Response. We appreciate commenters' recommendations and suggestions 
related to our cost analysis. While we understand why some commenters 
recommended additional factors for us to consider as part of our 
analysis, we do not believe many of those factors are relevant for two 
primary reasons: (1) We believe that it is improbable that this rule 
will result in the outcomes speculated and their associated costs; and 
(2) the factors contributing to or causing the increased costs are 
outside the scope of this rule (e.g., hypothetical business failure and 
job loss, workflow redesign) and could not be reasonably or accurately 
estimated. In this regard, we reiterate what we stated in the Interim 
Final Rule related to how costs would be estimated. ``This interim 
final rule estimates the costs commercial vendors, open source 
developers, and relevant Federal agencies will incur to prepare 
Complete EHRs and EHR Modules to be tested and certified to adopted 
standards, implementation specifications, and certification criteria. 
The Medicare and Medicaid EHR Incentive Programs proposed rule 
estimates the impacts related to the actions taken by eligible 
professionals or eligible hospitals to become meaningful users, 
including purchasing or self-developing Complete EHRs or EHR Modules. 
The HIT Certification Programs proposed rule estimates the testing and 
certification costs for Complete EHRs and EHR Modules.'' Accordingly, 
we disagree with the commenter who contended that our estimates were 
too simplistic and linear. We believe that in the absence of any 
additional data or an alternative model (which no commenter provided), 
our assumptions are sound and our analysis is reasonable for estimating 
the costs associated with complying with this final rule.
    We believe that it is important to note to commenters that 
compliance with this final rule is voluntary and as such, seeking to 
have a Complete EHR or EHR Module certified is voluntary. A Complete 
EHR or EHR Module developer is not required to comply with this final 
rule in order to operate its business. Rather, a Complete EHR or EHR 
Module developer will need to rely upon this final rule only if it 
ultimately seeks to have its EHR technology tested and certified as 
being compliant with the certification criteria adopted by the 
Secretary. Consequently, if a Complete EHR or EHR Module developer does 
not have the resources available to redesign its Complete EHR or EHR 
Module to incorporate the standards and implementation specifications 
or meet the certification criteria adopted in this rule, this rule does 
not create any new expenses for its business. Given this clarification, 
we believe that our estimates represent a higher than likely number of 
Complete EHR and EHR Module developers that will prepare their HIT to 
be tested and certified to the certification criteria adopted by the 
Secretary, and thus, the highest potential cost.
    We considered whether an hourly preparation cost should replace the 
assumptions we made in the Interim Final Rule, but found it difficult 
to determine what reasonable low and high hour ranges would be even if 
we were to assume 2500 hours to be the average. Further, for the 
purposes of testing this alternative approach, we assumed that it would 
be reasonable for the employees of a Complete EHR or EHR Module 
developer responsible for preparing a Complete EHR or EHR Module for 
testing and certification to be paid equivalent to a Federal employee 
with a Federal Salary Classification of GS-15 Step 1 ($59.30/hr plus 
21.35/hr for benefits) given the educational and professional 
experience we believe would be necessary to lead this type of activity. 
Multiplying the total hourly rate by the 2500 hours yields a total 
preparation cost of approximately $201,000. Thus, even if we were to 
assume that a high average for preparation of a Complete EHR or EHR 
Module would be double what the commenter stated, it would only 
represent close to $400,000 in preparation costs. Accordingly, we 
believe that our estimates are in fact comparatively high and the 
estimate range covers a wide range of possibilities.
    In the absence of additional data or any evidence to the contrary 
from public comment to guide revisions to our estimates, we are 
finalizing them according to the data and assumptions we identified in 
the Interim Final Rule. We believe that our estimates are sound, based 
on reasonable assumptions and data, and sufficiently accommodate 
varying costs for different types of Complete EHR and EHR Module 
developers. We believe that the additional clarity and specificity we 
have provided for some certification criteria and the removal of some 
required capabilities would further contribute to lowering the cost 
estimates for complying with this final rule. Consequently, we 
anticipate actual costs will fall somewhere between the low and mid-
point ranges of our estimates rather than between the mid-point and 
high ranges of our estimates.
    Finally, with respect to the commenter who expressed concern 
regarding the total costs associated with developing a Complete EHR 
which had never been certified, we note that our estimates should not 
be construed to imply that a Complete EHR developer would have to spend 
over $1 million in order to prepare a Complete EHR. To the contrary, 
had we calculated our low range for preparing a Complete EHR based on 
the absolute low we estimated for a per certification cost ($10,000), 
the total cost would have only been $240,000, or one-fifth the cost we 
estimated in the Interim Final Rule. The approach we took in the 
Interim Final Rule was designed to be inclusive of a middle range of 
possibilities, but was never meant to preclude the possibility that a 
Complete EHR developer could design a Complete EHR that was compliant 
with the certification criteria adopted by the Secretary for less than 
we estimated. Also in response to the commenter's request, we do not 
believe that it would be appropriate, nor are we authorized, to provide 
subsidies to Complete EHR or EHR Module developers for the costs of the 
preparing a Complete EHR or EHR module for testing and certification.
2. Executive Order 12866 Final Analysis
a. Costs
    This final rule adopts standards, implementation specifications, 
and certification criteria and consequently establishes the 
capabilities that Complete EHRs or EHR Modules will need to demonstrate 
in order to be certified. Our analysis focuses on the direct effects of 
the provisions of this final rule--the costs incurred by Complete EHR 
and EHR Module developers to 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 costs necessary to include the capabilities in a Complete 
EHR or EHR Module that will be compliant with the certification 
criteria adopted by the Secretary. Again, as noted above, the actual 
cost a Complete EHR or EHR Module developer will incur to be tested and 
certified is accounted for in our certification programs final rules.
    As we noted in the Interim Final Rule, we analyzed previously 
developed CCHIT ambulatory and inpatient

[[Page 44646]]

certification criteria and believe that many of those criteria, but not 
all, require the exact same capabilities as the certification criteria 
adopted by the Secretary at 45 CFR 170.302, 45 CFR 170.304, and 45 CFR 
170.306. Generally speaking, we believe this overlap includes most of 
the clinically oriented capabilities required by the certification 
criteria adopted by the Secretary. Accordingly, we believe that a 
significant number of previously CCHIT-certified-EHRs will only incur 
moderate costs to prepare for certification. For the purpose of 
estimating costs, we presume that previously CCHIT-certified-EHRs 
include the functionality to meet the definition of a Complete EHR. As 
a result, for our estimates in Table 1, we anticipate that these 
previously CCHIT-certified-EHRs will again be prepared for 
certification as Complete EHRs. We estimated in the Interim Final Rule 
that there were 74 CCHIT-certified-EHRs certified to its 2008 
ambulatory certification criteria and 17 CCHIT-certified-EHRs certified 
to its 2007 or 2008 inpatient certification criteria. 
11, 12, 13 Of these 74 and 17 previously CCHIT-certified-
EHRs, we expect that 90% will be prepared and submitted for 
certification according to the certification criteria adopted by the 
Secretary. We do not believe that it is realistic to assume that 100% 
of previously CCHIT-certified-EHRs will be prepared for certification 
for a number of reasons. These reasons include: (1) A recognition that 
mergers and acquisitions within the marketplace have reduced the number 
of previously CCHIT-certified-EHRs; (2) that the subsequent resources 
needed to market and promote Certified EHR Technology may not be 
available at the present time; and (3) that some previously CCHIT-
certified-EHRs will be tested and certified as EHR Modules rather than 
Complete EHRs. Given these assumptions, we have estimated the number of 
previously CCHIT-certified-EHRs that will be prepared to be tested and 
certified will be 65 and 15, ambulatory and inpatient, respectively. We 
also believe it is reasonable to assume that of these 65 and 15, some 
will require more preparation than others (i.e., we assume that some 
EHRs that were previously CCHIT-certified will include more 
capabilities than what they had when CCHIT originally tested and 
certified them, and they may consequently be able to more easily meet 
the certification criteria adopted by the Secretary). Based on this 
assumption, we have created low and high ranges for the costs to 
prepare previously CCHIT-certified ambulatory and inpatient EHRs.
---------------------------------------------------------------------------

    \11\ Some are marked with a conditional certification either 
``Pre-Market: These are conditionally certified EHRs which are new 
products that are fully certified once their operational use at a 
physician office site has been verified.'' or ``eRx Conditional: 
These are conditionally certified pending advanced ePrescribing EHRs 
that are in the process of verifying their ability to conduct 
medication history, formulary and eligibility checking through a 
national network for electronic-prescribing transactions.'' We do 
not believe that these caveats have any discernible effect on our 
estimates.
    \12\ http://www.cchit.org/products/Ambulatory_when 
certification years 2006 and 2007 are unchecked. While 78 EHRs are 
now listed, we do not believe that changing our estimate would have 
a measureable effect on the overall costs.
    \13\ http://www.cchit.org/products/Inpatient.
---------------------------------------------------------------------------

    In creating our low and high ranges for the tables below, we 
assumed based on our analysis of previously developed and required 
CCHIT certification criteria that certain capabilities (e.g., the 
capability to maintain a medication list) will have been widely 
implemented and deployed in HIT so that there will be little or no need 
to modify Complete EHRs or EHR Modules for certification. We also 
assumed that the certification criteria adopted by the Secretary range 
from relatively simple capabilities (e.g., recording a patient's 
smoking status) to more sophisticated capabilities (e.g., clinical 
decision support). As a result, we have made a general assumption that 
the costs to prepare Complete EHRs and EHR Modules to be tested and 
certified will vary depending on a number of factors including, but not 
limited to, whether the Complete EHR or EHR Module: (1) Already 
includes the capability; (2) includes some aspect of the capability 
which would need to be updated; (3) does not currently include the 
capability at all. We believe it is reasonable to estimate that it will 
cost somewhere between $10,000 and $250,000 per certification criterion 
to prepare a Complete EHR for testing and certification taking into 
account the factors identified directly above. We have used this per 
certification criterion range as the basis for our low and high cost 
range estimates. For the ease of our calculations, we have rounded to 
``40'' the number of certification criteria that the Secretary is 
adopting.
    For Table 1 we have made the following assumptions based on our 
understanding of the capabilities present in previously CCHIT-
certified-EHRs: (1) In general, Complete EHR developers who previously 
obtained a CCHIT certification for their EHR technology will possess a 
Complete EHR that will meet approximately 75% of the adopted 
certification criteria and, as a result, these Complete EHR developers 
may need to make more comprehensive adjustments to their Complete EHRs 
in order to prepare the Complete EHRs to be tested and certified to the 
remaining 25% of the certification criteria adopted by the Secretary; 
(2) the average low and high per certification criterion cost for 
ambulatory EHRs previously certified by CCHIT which need to be prepared 
for testing and certification will be $50,000 and $150,000, 
respectively; and (3) the average low and high per certification 
criterion cost for previously CCHIT-certified inpatient EHRs to be 
prepared for testing and certification will be $75,000 and $200,000, 
respectively.

  Table 1--Estimated One-Time Costs for Complete EHR Developers To Prepare Previously CCHIT-Certified-EHRs To Be Tested and Certified (3-Year Period)--
                                                                     Totals Rounded
--------------------------------------------------------------------------------------------------------------------------------------------------------
                                                                                    One time cost per EHR  ($M)     Total cost for all EHRs over 3-year
                                                                       Number     -------------------------------              period  ($M)
                               Type                                 prepared for                                 ---------------------------------------
                                                                    certification     Low      High    Mid-point      Low          High       Mid-point
--------------------------------------------------------------------------------------------------------------------------------------------------------
2008 Ambulatory CCHIT-Certified-EHR..............................              65     $0.50      $1.5      $1.0        $32.5         $97.5        $65.0
2007/2008 Inpatient CCHIT-Certified-EHR..........................              15      0.75       2.0       1.38        11.25         30.0         20.63
                                                                  --------------------------------------------------------------------------------------
    Total........................................................              80  ........  ........  .........        43.75        127.50        85.63
--------------------------------------------------------------------------------------------------------------------------------------------------------

    The second type of cost we estimate includes the costs that we 
expect for CCHIT-certified ambulatory EHRs certified prior to 2008 
(``out-of-date CCHIT-Certified-EHRs'') and never previously CCHIT-
certified-EHRs to be

[[Page 44647]]

prepared to be tested and certified as Complete EHRs rather than as EHR 
Modules.\14\ We assume the EHR technology that falls into this category 
may require more extensive changes than previously CCHIT-certified-EHRs 
identified in Table 1. Again, we have estimated low and high 
preparation cost ranges. We assume that there will be very little 
growth in the Complete EHR market due to the market share \15\ 
represented by the previously CCHIT-certified-EHRs included in Table 1 
and the upfront costs required to bring a Complete EHR to market. As a 
result, we expect there to be 8 and 5 Complete EHRs (for use by 
eligible professionals and eligible hospitals, respectively) prepared 
to be tested and certified to all of the applicable certification 
criteria adopted by the Secretary.\16\
---------------------------------------------------------------------------

    \14\ CCHIT began testing and certifying inpatient EHRs in 2007 
and we assume that all of those EHRs are included in Table 1 which 
is why they are not included in this discussion.
    \15\ http://www.cchit.org/about_``* * * EHR products certified 
by mid-2009, representing over 75% of the marketplace.''
    \16\ This estimate is premised in part on the fact that IHS's 
RPMS EHR was not included in Table 1 and that it will be preparing 
the RPMS EHR as a Complete EHR to meet the applicable certification 
criteria adopted by the Secretary for both ambulatory and inpatient 
settings.
---------------------------------------------------------------------------

    Again, using our general assumptions discussed above (40 
certification criteria and a low and high range of $10,000 to $250,000 
per certification criterion) we have made the following additional 
assumptions in our Table 2 calculations based on our understanding of 
the capabilities currently present in these EHR technologies: (1) In 
general, Complete EHR developers who have out-of-date CCHIT-Certified-
EHRs or who never previously had their Complete EHRs certified by CCHIT 
will possess Complete EHRs that will meet approximately 40% of the 
adopted certification criteria and, as a result, these Complete EHR 
developers may need to make more comprehensive adjustments to their 
Complete EHRs in order to prepare the Complete EHRs to be tested and 
certified to the remaining 60% of the certification criteria adopted by 
the Secretary; (2) the average low and high per certification criterion 
costs for Complete EHRs for eligible professionals to be prepared to be 
tested and certified will be $50,000 and $150,000, respectively; and 
(3) the average low and high per certification criterion costs for 
Complete EHRs for eligible hospitals to be prepared to be tested and 
certified will be $75,000 and $200,000, respectively.

  Table 2--Estimated One-Time Costs for Complete EHR Developers To Prepare Never CCHIT-Certified-EHRs and Out-of-Date CCHIT-Certified-EHRs To Be Tested
                                                      and Certified (3-Year Period)--Totals Rounded
--------------------------------------------------------------------------------------------------------------------------------------------------------
                                                                                   One time cost per EHR ($M)       Total cost for all EHRs over 3-year
                                                                   Number     ------------------------------------              period ($M)
                             Type                               prepared for                                      --------------------------------------
                                                                certification      Low        High      Mid-point      Low          High      Mid-point
--------------------------------------------------------------------------------------------------------------------------------------------------------
Complete EHRs for Eligible Professionals.....................               8        $1.2        $3.6        $2.4        $9.6        $28.8        $19.2
Complete EHRs for Eligible Hospitals.........................               5         1.8         4.8         3.3         9.0         24.0         16.5
                                                              ------------------------------------------------------------------------------------------
    Total....................................................              13  ..........  ..........  ..........        18.60        52.80        35.70
--------------------------------------------------------------------------------------------------------------------------------------------------------

    Finally, the third type of cost we estimate relates to the number 
of EHR Modules we expect to be prepared to be tested and certified and 
the costs associated with that preparation. We clarify as noted in the 
Temporary Certification Program final rule that these EHR Modules are 
not ``self-developed,'' and we assume that an EHR Module developer 
interested in commercially marketing its EHR Module to eligible 
professionals and eligible hospitals would develop them. We assumed in 
the Interim Final Rule that certain types of EHR Modules (e.g., 
computerized provider order entry; quality reporting; online patient 
portals) would be more likely than others to be prepared to be tested 
and certified, and we estimated based on our assumption that there 
would be 7 EHR Modules prepared to be tested and certified for each of 
the 7 types of EHR Modules we identified. This estimate (number of 
modules X types of modules) resulted in an approximate number of 50 EHR 
Modules that would be prepared to be tested and certified. Again, we 
have provided low and high preparation cost estimates in Table 3 below. 
We assume that some of EHR Modules prepared for certification will be 
capable of meeting applicable certification criteria with little 
modification while other EHR Modules will not. Given the potential 
differences in preparation costs and combinations of certification 
criteria to create EHR Modules, we believe it is reasonable to estimate 
a wide range of costs for preparing these types of EHR Modules for 
testing and certification. We estimated in the Interim Final Rule and 
reiterate below a low average one-time cost of $100,000 to prepare an 
EHR Module, based on the assumption that some of the less sophisticated 
EHR Modules would only be prepared to be tested and certified to 1 or 2 
certification criteria. We estimated in the Interim Final Rule and 
reiterate below, a high average cost one-time cost of $500,000 to 
prepare an EHR Module, based on the assumption that some of the more 
sophisticated EHR Modules would only be prepared to be tested and 
certified to 1 or 2 of the more complicated certification criteria or 
would be prepared to be tested and certified to multiple certification 
criteria.

      Table 3--Estimated One-Time Costs to EHR Module Developers To Prepare EHR Modules To Be Tested and Certified (3-Year Period)--Totals Rounded
--------------------------------------------------------------------------------------------------------------------------------------------------------
                                                                                One-time cost per EHR module ($M)    Total cost all EHR modules over 3-
                                                                   Number     ------------------------------------            year period ($M)
                             Type                                 prepared                                        --------------------------------------
                                                                                   Low        High      Mid-point      Low          High      Mid-point
--------------------------------------------------------------------------------------------------------------------------------------------------------
EHR Modules..................................................              50        $0.1        $0.5        $0.3        $5.0        $25.0        $15.0
                                                              ------------------------------------------------------------------------------------------

[[Page 44648]]


    Total....................................................              50  ..........  ..........  ..........         5.0         25.0         15.0
--------------------------------------------------------------------------------------------------------------------------------------------------------

    In total, if we were to distribute the costs to prepare Complete 
EHRs and EHR Modules between 2010 and 2012 evenly per year, we believe 
they would likely be in the range of $67.35 to $205.3 million or $22.45 
to $68.43 million per year with an annual cost mid-point of 
approximately $45.44 million. However, we do not believe that the costs 
will be spread evenly over these three years due to market pressures 
and the fact that higher upfront incentive payments are available under 
the Medicare and Medicaid EHR Incentive Programs. We assume this factor 
will motivate a greater ratio of commercial vendors and open source 
developers of Complete EHRs and EHR Modules to prepare such technology 
for testing and certification in 2010 and 2011 rather than 2012. As a 
result, we believe as represented in Table 4 that the costs 
attributable to this final rule will be distributed as follows: 45% for 
2010, 40% for 2011 and 15% for 2012.

 Table 6--Distributed Total Preparation Costs for Complete EHR and EHR Module Developers (3-Year Period)--Totals
                                                     Rounded
----------------------------------------------------------------------------------------------------------------
                                                                                                  Total average
                  Year                    Ratio (percent)   Total low cost    Total high cost     cost estimate
                                                             estimate ($M)     estimate  ($M)         ($M)
----------------------------------------------------------------------------------------------------------------
2010...................................                45            $30.31             $92.39            $61.35
2011...................................                40             26.94              82.12             54.53
2012...................................                15             10.10              30.80             20.45
3-Year Totals..........................  ................             67.35             205.30            136.33
----------------------------------------------------------------------------------------------------------------

    Note that these cost estimates do not include additional costs to 
prepare for testing and certification that will likely be incurred when 
we adopt additional standards, implementation specifications, and 
certification criteria to support meaningful use Stages 2 and 3. We 
will account for costs associated with these additional standards, 
implementation specifications, and certification criteria in future 
rulemaking.
b. Benefits
    We believe that there will be several benefits arising from this 
final rule. By adopting the revisions to this initial set, the 
Secretary will set in motion what we believe will be an iterative 
process to further enhance the interoperability, functionality, 
utility, and security of health information technology and to support 
the meaningful use of Certified EHR Technology. The capabilities 
specified in the adopted certification criteria will help ensure that 
health care providers have the necessary information technology tools 
to improve patient care, reduce medical errors and unnecessary tests. 
The standards adopted will aid in fostering greater interoperability. 
We also believe that this final rule will serve as a catalyst for a 
more competitive and innovative marketplace. Finally, adopted 
certification criteria can be used by Complete EHR and EHR Module 
developers as technical requirements to ensure that their HIT can be 
tested and certified and subsequently adopted and implemented as 
Certified EHR Technology. Adopting these certification criteria will 
also ultimately help enable eligible professionals and eligible 
hospitals to qualify for incentive payments under Medicare and Medicaid 
EHR Incentive Programs.

D. Regulatory Flexibility Act Analysis

1. Comment and Response
    Comment. Some commenters noted that we incorrectly referenced the 
proportion of businesses in the marketplace that would qualify as small 
businesses under the SBA's size standard. The commenters cited a 
presentation by CCHIT which indicated that potentially up to 75% of 
Complete EHR developers who design Complete EHRs for ambulatory 
settings would qualify as small businesses.
    Response. We appreciate commenters pointing out this additional 
information. We have revised the discussion accordingly in the final 
RFA analysis. However, we do not believe that this additional 
information substantially changes our analysis. We do not believe that 
any relief can be provided to small businesses under the SBA size 
standard that would not undercut our programmatic goals and objectives. 
A Complete EHR or EHR Module developer will need to design a Complete 
EHR or EHR Module that can be tested and successfully certified to all 
applicable certification criteria adopted by the Secretary in order for 
the Complete EHR or EHR Module to attain certification. Accordingly, we 
see no viable alternatives to reducing the requirements in the final 
rule or providing for alternatives to adopted certification criteria. 
Additionally, we believe that the regulation builds in a certain amount 
of flexibility already in that a small business without the resources 
available to develop a Complete EHR has the option to develop an EHR 
Module which will presumably require less of an investment (time and 
money) to develop.
2. Final RFA Analysis
    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.
    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

[[Page 44649]]

Programming Services'' specified at 13 CFR 121.201 where the SBA 
publishes ``Small Business Size Standards by NAICS Industry.'' The size 
standard associated with this NAICS code is set at $25 million in 
annual receipts \17\ which ``indicates the maximum allowed for a 
concern and its affiliates to be considered small entities.''
---------------------------------------------------------------------------

    \17\ The SBA references that annual receipts means ``total 
income'' (or in the case of a sole proprietorship, ``gross income'') 
plus ``cost of goods sold'' as these terms are defined and reported 
on Internal Revenue Service tax return forms. http://www.sba.gov/
idc/groups/public/documents/sba_homepage/guide_to_size_
standards.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.
    We estimate that this final rule could 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 and that no 
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 an eligible 
professional or eligible hospital will be required to use under the 
Medicare and Medicaid EHR Incentive Programs final rule, it will need 
to comply with the applicable 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 the 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.

E. Executive Order 13132--Federalism

    Executive Order 13132 establishes certain requirements that an 
agency must meet when it promulgates a proposed rule (and subsequent 
final rule) that imposes substantial direct requirement costs on State 
and local governments, preempts State law, or otherwise has federalism 
implications.
    Nothing in this final rule imposes substantial direct compliance 
costs on State and local governments, preempts State law or otherwise 
has federalism implications. We are not aware of any State laws or 
regulations that are contradicted or impeded by any of the standards, 
implementation specifications, or certification criteria that have been 
adopted.
    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.

0
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. Amend Sec.  170.102 by revising the definitions of ``Complete EHR,'' 
``Certified EHR Technology,'' and ``Disclosure'' and adding the 
definition of ``Human readable format'' to read as follows:


Sec.  170.102  Definitions.

* * * * *
    Certified EHR Technology means:
    (1) A Complete EHR that meets the requirements included in the 
definition of a Qualified EHR and has been tested and certified in 
accordance with the certification program established by the National 
Coordinator as having met all applicable certification criteria adopted 
by the Secretary; or
    (2) A combination of EHR Modules in which each constituent EHR 
Module of the combination has been tested and certified in accordance 
with the certification program established by the National Coordinator 
as having met all applicable certification criteria adopted by the 
Secretary, and the resultant combination also meets the requirements 
included in the definition of a Qualified EHR.
    Complete EHR means EHR technology that has been developed to meet, 
at a minimum, all applicable certification criteria adopted by the 
Secretary.
    Disclosure is defined as it is in 45 CFR 160.103.
* * * * *
    Human readable format means a format that enables a human to read 
and easily comprehend the information presented to him or her 
regardless of the method of presentation.
* * * * *

0
3. Revise subpart B to read as follows:

Subpart B--Standards and Implementation Specifications for Health 
Information Technology

Sec.
170.200 Applicability.
170.202 [Reserved]
170.205 Content exchange standards and implementation specifications 
for exchanging electronic health information.
170.207 Vocabulary standards for representing electronic health 
information.
170.210 Standards for health information technology to protect 
electronic health information created, maintained, and exchanged.
170.299 Incorporation by reference.


Sec.  170.200  Applicability.

    The standards and implementation specifications adopted in this 
part apply with respect to Complete EHRs and EHR Modules.


Sec.  170.202  [Reserved]


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) Patient summary record--(1) Standard. Health Level Seven 
Clinical Document Architecture (CDA) Release 2, Continuity of Care 
Document (CCD) (incorporated by reference in Sec.  170.299). 
Implementation specifications. The Healthcare Information Technology 
Standards Panel (HITSP) Summary

[[Page 44650]]

Documents Using HL7 CCD Component HITSP/C32 (incorporated by reference 
in Sec.  170.299).
    (2) Standard. ASTM E2369 Standard Specification for Continuity of 
Care Record and Adjunct to ASTM E2369 (incorporated by reference in 
Sec.  170.299).
    (b) Electronic prescribing. (1) Standard. The National Council for 
the Prescription Drug Programs (NCPDP) Prescriber/Pharmacist Interface 
SCRIPT standard, Implementation Guide, Version 8, Release 1 (Version 
8.1) October 2005 (incorporated by reference in Sec.  170.299)
    (2) Standard. NCPDP SCRIPT Standard, Implementation Guide, Version 
10.6 (incorporated by reference in Sec.  170.299).
    (c) Electronic submission 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).
    (d) Electronic submission to public health agencies for 
surveillance or reporting. (1) Standard. HL7 2.3.1 (incorporated by 
reference in Sec.  170.299).
    (2) Standard. HL7 2.5.1 (incorporated by reference in Sec.  
170.299). Implementation specifications. Public Health Information 
Network HL7 Version 2.5 Message Structure Specification for National 
Condition Reporting Final Version 1.0 and Errata and Clarifications 
National Notification Message Structural Specification (incorporated by 
reference in Sec.  170.299).
    (e) Electronic submission to immunization registries. (1) Standard. 
HL7 2.3.1 (incorporated by reference in Sec.  170.299). Implementation 
specifications. Implementation Guide for Immunization Data Transactions 
using Version 2.3.1 of the Health Level Seven (HL7) Standard Protocol 
Implementation Guide Version 2.2 (incorporated by reference in Sec.  
170.299).
    (2) 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.0 (incorporated by reference in 
Sec.  170.299).
    (f) Quality reporting. Standard. The CMS Physician Quality 
Reporting Initiative (PQRI) 2009 Registry XML Specification 
(incorporated by reference in Sec.  170.299). Implementation 
specifications. Physician Quality Reporting Initiative Measure 
Specifications Manual for Claims and Registry (incorporated by 
reference in Sec.  170.299).


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) Problems--(1) Standard. The code set specified at 45 CFR 
162.1002(a)(1) for the indicated conditions.
    (2) Standard. International Health Terminology Standards 
Development Organization (IHTSDO) Systematized Nomenclature of Medicine 
Clinical Terms (SNOMED CT[supreg]) July 2009 version (incorporated by 
reference in Sec.  170.299).
    (b) Procedures--(1) Standard. The code set specified at 45 CFR 
162.1002(a)(2).
    (2) Standard. The code set specified at 45 CFR 162.1002(a)(5).
    (c) Laboratory test results. 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).
    (d) Medications. Standard. Any source vocabulary that is included 
in RxNorm, a standardized nomenclature for clinical drugs produced by 
the United States National Library of Medicine.
    (e) Immunizations. Standard. HL7 Standard Code Set CVX--Vaccines 
Administered, July 30, 2009 version (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 and Ethnicity, Statistical Policy Directive No. 15, 
October 30, 1997 (available at http://www.whitehouse.gov/omb/rewrite/
fedreg/ombdir15.html).


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:
    (a) Encryption and decryption of electronic health information--(1) 
General. Any encryption algorithm identified by the National Institute 
of Standards and Technology (NIST) as an approved security function in 
Annex A of the Federal Information Processing Standards (FIPS) 
Publication 140-2 (incorporated by reference in Sec.  170.299).
    (2) Exchange. Any encrypted and integrity protected link.
    (b) Record actions related to electronic health information. The 
date, time, patient identification, and user identification must be 
recorded when electronic health information is created, modified, 
accessed, or deleted; and an indication of which action(s) occurred and 
by whom must also be recorded.
    (c) Verification that electronic health information has not been 
altered in transit. Standard. A hashing algorithm with a security 
strength equal to or greater than SHA-1 (Secure Hash Algorithm (SHA-1) 
as specified by the National Institute of Standards and Technology 
(NIST) in FIPS PUB 180-3 (October, 2008)) must be used to verify that 
electronic health information has not been altered.
    (d) Record treatment, payment, and health care operations 
disclosures. The date, time, patient identification, user 
identification, and a description of the disclosure must be recorded 
for disclosures for treatment, payment, and health care operations, as 
these terms are defined at 45 CFR 164.501.


Sec.  170.299  Incorporation by reference.

    (a) Certain material is incorporated by reference into this subpart 
with the approval of the Director of the Federal Register under 5 
U.S.C. 552(a) and 1 CFR part 51. To enforce any edition other than that 
specified in this section, the Department of Health and Human Services 
must publish notice of change in the Federal Register and the material 
must be available to the public. All approved material is available for 
inspection at the National Archives and Records Administration (NARA). 
For information on the availability of this material at NARA, call 202-
741-6030 or go to http://www.archives.gov/federal_register/code_of_
federal_regulations/ibr_locations.html. Also, it is available for 
inspection at U.S. Department of Health and Human Services, Office of 
the National Coordinator for Health Information Technology, Hubert H. 
Humphrey Building, Suite 729D, 200 Independence Ave., SW., Washington, 
DC 20201, call ahead to arrange for inspection at 202-690-7151, and is 
available from the sources listed below.
    (b) Health Level Seven, 3300 Washtenaw Avenue, Suite 227, Ann 
Arbor, MI 48104; Telephone (734) 677-7777 or http://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,

[[Page 44651]]

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>
http://
www.astm.org/.
    (1) 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.
    (2) 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) 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 http://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.
    (3) [Reserved]
    (e) 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-5558 or http://
loinc.org/.
    (1) Logical Observation Identifiers Names and Codes 
(LOINC[supreg]) version 2.27, June 15, 2009, IBR approved 
for Sec.  170.207.
    (2) [Reserved]
    (f) U.S. National Library of Medicine, 8600 Rockville Pike, 
Bethesda, MD 20894; Telephone (301) 594-5983 or http://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) [Reserved]
    (g) Centers for Disease Control and Prevention, National Centers 
for Immunization and Respiratory Diseases Immunization Information 
System Support Branch--Informatics 1600 Clifton Road Mailstop: E-62 
Atlanta, GA 30333
    (1) HL7 Standard Code Set CVX--Vaccines Administered, July 30, 
2009, IBR approved for Sec.  170.207.
    (2) 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.
    (3) HL7 2.5.1 Implementation Guide for Immunization Messaging 
Release 1.0, May 1, 2010, IBR approved for Sec.  170.205.
    (4) Public Health Information Network HL7 Version 2.5 Message 
Structure Specification for National Condition Reporting Final Version 
1.0, including Errata and Clarifications, National Notification Message 
Structural Specification, 8/18/2007, August 18, 2007, IBR approved for 
Sec.  170.205.
    (5) [Reserved]
    (h) 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.
    (i) National Institute of Standards and Technology, Information 
Technology Laboratory, National Institute of Standards and Technology, 
100 Bureau Drive, Gaithersburg, MD 20899-8930, http://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) [Reserved]
    (j) American National Standards Institute, Health Information 
Technology Standards Panel (HITSP) Secretariat, 25 West 43rd Street--
Fourth Floor, New York, NY 10036, http://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.

0
4. Revise subpart C to read as follows:

Subpart C--Certification Criteria for Health Information Technology

Sec.
170.300 Applicability.
170.302 General certification criteria for Complete EHRs or EHR 
Modules.
170.304 Specific certification criteria for Complete EHRs or EHR 
Modules designed for an ambulatory setting.
170.306 Specific certification criteria for Complete EHRs or EHR 
Modules designed for an inpatient setting.


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, 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 that are designated as optional.


Sec.  170.302  General certification criteria for Complete EHRs or EHR 
Modules.

    The Secretary adopts the following general 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) Drug-drug, drug-allergy interaction checks--(1) Notifications. 
Automatically and electronically generate and indicate in real-time, 
notifications at the point of care for drug-drug and drug-allergy 
contraindications based on medication list, medication allergy list, 
and computerized provider order entry (CPOE).
    (2) Adjustments. Provide certain users with the ability to adjust 
notifications provided for drug-drug and drug-allergy interaction 
checks.
    (b) Drug-formulary checks. Enable a user to electronically check if 
drugs are in a formulary or preferred drug list.
    (c) Maintain up-to-date problem list. Enable a user to 
electronically record, modify, and retrieve a patient's problem list 
for longitudinal care in accordance with:
    (1) The standard specified in Sec.  170.207(a)(1); or
    (2) At a minimum, the version of the standard specified in Sec.  
170.207(a)(2).
    (d) Maintain active medication list. Enable a user to 
electronically record, modify, and retrieve a patient's active 
medication list as well as medication history for longitudinal care.

[[Page 44652]]

    (e) Maintain active medication allergy list. Enable a user to 
electronically record, modify, and retrieve a patient's active 
medication allergy list as well as medication allergy history for 
longitudinal care.
    (f) Record and chart vital signs--(1) Vital signs. Enable a user to 
electronically record, modify, and retrieve a patient's vital signs 
including, at a minimum, height, weight, and blood pressure.
    (2) Calculate body mass index. Automatically calculate and display 
body mass index (BMI) based on a patient's height and weight.
    (3) Plot and display growth charts. Plot and electronically 
display, upon request, growth charts for patients 2-20 years old.
    (g) Smoking status. Enable a user to electronically record, modify, 
and retrieve the smoking status of a patient. Smoking status types must 
include: current every day smoker; current some day smoker; former 
smoker; never smoker; smoker, current status unknown; and unknown if 
ever smoked.
    (h) Incorporate laboratory test results--(1) Receive results. 
Electronically receive clinical laboratory test results in a structured 
format and display such results in human readable format.
    (2) Display test report information. Electronically display all the 
information for a test report specified at 42 CFR 493.1291(c)(1) 
through (7).
    (3) Incorporate results. Electronically attribute, associate, or 
link a laboratory test result to a laboratory order or patient record.
    (i) Generate patient lists. Enable a user to electronically select, 
sort, retrieve, and generate lists of patients according to, at a 
minimum, the data elements included in:
    (1) Problem list;
    (2) Medication list;
    (3) Demographics; and
    (4) Laboratory test results.
    (j) Medication reconciliation. Enable a user to electronically 
compare two or more medication lists.
    (k) Submission to immunization registries. Electronically record, 
modify, retrieve, and submit immunization information in accordance 
with:
    (1) The standard (and applicable implementation specifications) 
specified in Sec.  170.205(e)(1) or Sec.  170.205(e)(2); and
    (2) At a minimum, the version of the standard specified in Sec.  
170.207(e).
    (l) Public health surveillance. Electronically record, modify, 
retrieve, and submit syndrome-based public health surveillance 
information in accordance with the standard (and applicable 
implementation specifications) specified in Sec.  170.205(d)(1) or 
Sec.  170.205(d)(2).
    (m) Patient-specific education resources. Enable a user to 
electronically identify and provide patient-specific education 
resources according to, at a minimum, the data elements included in the 
patient's: problem list; medication list; and laboratory test results; 
as well as provide such resources to the patient.
    (n) Automated measure calculation. For each meaningful use 
objective with a percentage-based measure, electronically record the 
numerator and denominator and generate a report including the 
numerator, denominator, and resulting percentage associated with each 
applicable meaningful use measure.
    (o) Access control. Assign a unique name and/or number for 
identifying and tracking user identity and establish controls that 
permit only authorized users to access electronic health information.
    (p) Emergency access. Permit authorized users (who are authorized 
for emergency situations) to access electronic health information 
during an emergency.
    (q) Automatic log-off. Terminate an electronic session after a 
predetermined time of inactivity.
    (r) Audit log. (1)--Record actions. Record actions related to 
electronic health information in accordance with the standard specified 
in Sec.  170.210(b).
    (2) Generate audit log. Enable a user to generate an audit log for 
a specific time period and to sort entries in the audit log according 
to any of the elements specified in the standard at Sec.  170.210(b).
    (s) Integrity. (1) Create a message digest in accordance with the 
standard specified in Sec.  170.210(c).
    (2) 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.
    (3) Detection. Detect the alteration of audit logs.
    (t) Authentication. Verify that a person or entity seeking access 
to electronic health information is the one claimed and is authorized 
to access such information.
    (u) General encryption. Encrypt and decrypt electronic health 
information in accordance with the standard specified in Sec.  
170.210(a)(1), unless the Secretary determines that the use of such 
algorithm would pose a significant security risk for Certified EHR 
Technology.
    (v) Encryption when exchanging electronic health information. 
Encrypt and decrypt electronic health information when exchanged in 
accordance with the standard specified in Sec.  170.210(a)(2).
    (w) 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).


Sec.  170.304  Specific certification criteria for Complete EHRs or EHR 
Modules designed for an ambulatory setting.

    The Secretary adopts the following certification criteria for 
Complete EHRs or EHR Modules designed to be used in an ambulatory 
setting. Complete EHRs or EHR Modules must include the capability to 
perform the following functions electronically and in accordance with 
all applicable standards and implementation specifications adopted in 
this part:
    (a) Computerized provider order entry. Enable a user to 
electronically record, store, retrieve, and modify, at a minimum, the 
following order types:
    (1) Medications;
    (2) Laboratory; and
    (3) Radiology/imaging.
    (b) Electronic prescribing. Enable a user to electronically 
generate and transmit prescriptions and prescription-related 
information in accordance with:
    (1) The standard specified in Sec.  170.205(b)(1) or Sec.  
170.205(b)(2); and
    (2) The standard specified in Sec.  170.207(d).
    (c) Record demographics. Enable a user to electronically record, 
modify, and retrieve patient demographic data including preferred 
language, gender, race, ethnicity, and date of birth. Enable race and 
ethnicity to be recorded in accordance with the standard specified at 
Sec.  170.207(f).
    (d) Patient reminders. Enable a user to electronically generate a 
patient reminder list for preventive or follow-up care according to 
patient preferences based on, at a minimum, the data elements included 
in:
    (1) Problem list;
    (2) Medication list;
    (3) Medication allergy list;
    (4) Demographics; and
    (5) Laboratory test results.
    (e) Clinical decision support--(1) Implement rules. Implement 
automated, electronic clinical decision support rules (in addition to 
drug-drug and drug-allergy contraindication checking) based on the data 
elements included in: problem list; medication list; demographics; and 
laboratory test results.
    (2) Notifications. Automatically and electronically generate and 
indicate in

[[Page 44653]]

real-time, notifications and care suggestions based upon clinical 
decision support rules.
    (f) Electronic copy of health information. Enable a user to create 
an electronic copy of a patient's clinical information, including, at a 
minimum, diagnostic test results, problem list, medication list, and 
medication allergy list in:
    (1) Human readable format; and
    (2) On electronic media or through some other electronic means in 
accordance with:
    (i) The standard (and applicable implementation specifications) 
specified in Sec.  170.205(a)(1) or Sec.  170.205(a)(2); and
    (ii) For the following data elements the applicable standard must 
be used:
    (A) Problems. The standard specified in Sec.  170.207(a)(1) or, at 
a minimum, the version of the standard specified in Sec.  
170.207(a)(2);
    (B) Laboratory test results. At a minimum, the version of the 
standard specified in Sec.  170.207(c); and
    (C) Medications. The standard specified in Sec.  170.207(d).
    (g) Timely access. Enable a user to provide patients with online 
access to their clinical information, including, at a minimum, lab test 
results, problem list, medication list, and medication allergy list.
    (h) Clinical summaries. Enable a user to provide clinical summaries 
to patients for each office visit that include, at a minimum, 
diagnostic test results, problem list, medication list, and medication 
allergy list. If the clinical summary is provided electronically it 
must be:
    (1) Provided in human readable format; and
    (2) Provided on electronic media or through some other electronic 
means in accordance with:
    (i) The standard (and applicable implementation specifications) 
specified in Sec.  170.205(a)(1) or Sec.  170.205(a)(2); and
    (ii) For the following data elements the applicable standard must 
be used:
    (A) Problems. The standard specified in Sec.  170.207(a)(1) or, at 
a minimum, the version of the standard specified in Sec.  
170.207(a)(2);
    (B) Laboratory test results. At a minimum, the version of the 
standard specified in Sec.  170.207(c); and
    (C) Medications. The standard specified in Sec.  170.207(d).
    (i) Exchange clinical information and patient summary record--(1) 
Electronically receive and display. Electronically receive and display 
a patient's summary record, from other providers and organizations 
including, at a minimum, diagnostic tests results, problem list, 
medication list, and medication allergy list in accordance with the 
standard (and applicable implementation specifications) specified in 
Sec.  170.205(a)(1) or Sec.  170.205(a)(2). Upon receipt of a patient 
summary record formatted according to the alternative standard, display 
it in human readable format.
    (2) Electronically transmit. Enable a user to electronically 
transmit a patient summary record to other providers and organizations 
including, at a minimum, diagnostic test results, problem list, 
medication list, and medication allergy list in accordance with:
    (i) The standard (and applicable implementation specifications) 
specified in Sec.  170.205(a)(1) or Sec.  170.205(a)(2); and
    (ii) For the following data elements the applicable standard must 
be used:
    (A) Problems. The standard specified in Sec.  170.207(a)(1) or, at 
a minimum, the version of the standard specified in Sec.  
170.207(a)(2);
    (B) Laboratory test results. At a minimum, the version of the 
standard specified in Sec.  170.207(c); and
    (C) Medications. The standard specified in Sec.  170.207(d).
    (j) Calculate and submit clinical quality measures--(1) Calculate 
(i) Electronically calculate all of the core clinical measures 
specified by CMS for eligible professionals.
    (ii) Electronically calculate, at a minimum, three clinical quality 
measures specified by CMS for eligible professionals, in addition to 
those clinical quality measures specified in paragraph (1)(i).
    (2) Submission. Enable a user to electronically submit calculated 
clinical quality measures in accordance with the standard and 
implementation specifications specified in Sec.  170.205(f).


Sec.  170.306  Specific certification criteria for Complete EHRs or EHR 
Modules designed for an inpatient setting.

    The Secretary adopts the following certification criteria for 
Complete EHRs or EHR Modules designed to be used in an inpatient 
setting. Complete EHRs or EHR Modules must include the capability to 
perform the following functions electronically and in accordance with 
all applicable standards and implementation specifications adopted in 
this part:
    (a) Computerized provider order entry. Enable a user to 
electronically record, store, retrieve, and modify, at a minimum, the 
following order types:
    (1) Medications;
    (2) Laboratory; and
    (3) Radiology/imaging.
    (b) Record demographics. Enable a user to electronically record, 
modify, and retrieve patient demographic data including preferred 
language, gender, race, ethnicity, date of birth, and date and 
preliminary cause of death in the event of mortality. Enable race and 
ethnicity to be recorded in accordance with the standard specified at 
Sec.  170.207(f).
    (c) Clinical decision support--(1) Implement rules. Implement 
automated, electronic clinical decision support rules (in addition to 
drug-drug and drug-allergy contraindication checking) based on the data 
elements included in: problem list; medication list; demographics; and 
laboratory test results.
    (2) Notifications. Automatically and electronically generate and 
indicate in real-time, notifications and care suggestions based upon 
clinical decision support rules.
    (d) Electronic copy of health information. (1) Enable a user to 
create an electronic copy of a patient's clinical information, 
including, at a minimum, diagnostic test results, problem list, 
medication list, medication allergy list, and procedures:
    (i) In human readable format; and
    (ii) On electronic media or through some other electronic means in 
accordance with:
    (A) The standard (and applicable implementation specifications) 
specified in Sec.  170.205(a)(1) or Sec.  170.205(a)(2); and
    (B) For the following data elements the applicable standard must be 
used:
    (1) Problems. The standard specified in Sec.  170.207(a)(1) or, at 
a minimum, the version of the standard specified in Sec.  
170.207(a)(2);
    (2) Procedures. The standard specified in Sec.  170.207(b)(1) or 
Sec.  170.207(b)(2);
    (3) Laboratory test results. At a minimum, the version of the 
standard specified in Sec.  170.207(c); and
    (4) Medications. The standard specified in Sec.  170.207(d).
    (2) Enable a user to create an electronic copy of a patient's 
discharge summary in human readable format and on electronic media or 
through some other electronic means.
    (e) Electronic copy of discharge instructions. Enable a user to 
create an electronic copy of the discharge instructions for a patient, 
in human readable format, at the time of discharge on electronic media 
or through some other electronic means.
    (f) Exchange clinical information and patient summary record--(1) 
Electronically receive and display. Electronically receive and display 
a patient's summary record from other

[[Page 44654]]

providers and organizations including, at a minimum, diagnostic test 
results, problem list, medication list, medication allergy list, and 
procedures in accordance with the standard (and applicable 
implementation specifications) specified in Sec.  170.205(a)(1) or 
Sec.  170.205(a)(2). Upon receipt of a patient summary record formatted 
according to the alternative standard, display it in human readable 
format.
    (2) Electronically transmit. Enable a user to electronically 
transmit a patient's summary record to other providers and 
organizations including, at a minimum, diagnostic results, problem 
list, medication list, medication allergy list, and procedures in 
accordance with:
    (i) The standard (and applicable implementation specifications) 
specified in Sec.  170.205(a)(1) or Sec.  170.205(a)(2); and
    (ii) For the following data elements the applicable standard must 
be used:
    (A) Problems. The standard specified in Sec.  170.207(a)(1) or, at 
a minimum, the version of the standard specified in Sec.  
170.207(a)(2);
    (B) Procedures. The standard specified in Sec.  170.207(b)(1) or 
Sec.  170.207(b)(2);
    (C) Laboratory test results. At a minimum, the version of the 
standard specified in Sec.  170.207(c); and
    (D) Medications. The standard specified in Sec.  170.207(d).
    (g) Reportable lab results. Electronically record, modify, 
retrieve, and submit reportable clinical lab results in accordance with 
the standard (and applicable implementation specifications) specified 
in Sec.  170.205(c) and, at a minimum, the version of the standard 
specified in Sec.  170.207(c).
    (h) Advance directives. Enable a user to electronically record 
whether a patient has an advance directive.
    (i) Calculate and submit clinical quality measures--(1) Calculate. 
Electronically calculate all of the clinical quality measures specified 
by CMS for eligible hospitals and critical access hospitals.
    (2) Submission. Enable a user to electronically submit calculated 
clinical quality measures in accordance with the standard and 
implementation specifications specified in Sec.  170.205(f).


    Dated: July 9, 2010.
Kathleen Sebelius,
Secretary.
[FR Doc. 2010-17210 Filed 7-12-10; 8:45 am]
BILLING CODE 4150-45-P